Developers Battle Over Bitcoin Block Chain

It's surprising what worm-filled cans a new version of the bitcoin protocol will open. The core developers released a much-anticipated update to the core software - version 0.9.0 - last week. Now, a third-party developer group is already lobbying for change.

Counterparty

, a financial trading platform built on the bitcoin block chain, issued an open letter to the Bitcoin protocol's core developers last week, urging them to reconsider a key component of the protocol's latest release. That component is called OP_RETURN, and it is a new feature designed to allow people to store extra data in the block chain.

OP_RETURN was originally meant to store 80 bytes of extra data in a bitcoin transaction, but the core developers slashed it to 40 bytes. This upset Counterparty, because as a financial trading platform that allows people to create new asset classes and financial derivatives to be traded on the bitcoin block chain, it says that it needed those 80 bytes to store its data.

"A 40 byte limit (in place of the 80 bytes originally planned) makes OP_RETURN unusable for Counterparty’s purposes," said the letter.

The other option is to use another feature of the Bitcoin protocol, called multi-signature outputs. These involve more than one signature for a particular bitcoin transaction, and are designed for features such as escrow payments. But that second signature can be used to store data instead.

"If the data cap is left at 40 bytes, we will be forced to use such awkward constructions to accomplish our goals," the Counterparty letter said. Instead, the organization wants the core devs to play ball, and restore the original 80-byte cap.

In a discussion on the Bitcoin Talk forum, core developer Jeff Garzik makes an argument for why they shouldn't. He warns that when a transaction is processed on the bitcoin network, everyone processes it, which means that the data you're storing has to be stored by everyone.

"It is called a free ride. Given that the overwhelming majority -- >90% -- application for the bitcoin blockchain is currency use, using full nodes as dumb data storage terminals is simply abusing an all-volunteer network resource," he argues.

He accuses Counterparty and Mastercoin - another service that also uses the block chain for its own purposes - of having "simply flipped an 'on' switch and started using bitcoin P2P nodes as unwanted data stores." And they didn't engage the community before doing it either, he complains.

Get off of my block

Is it really the core developers' job to make it possible for others to build extra services on top of the block chain? It had better, if it wants to stay relevant, says 'PhantomPhreak', a core developer for Counterparty.

PhantomPhreak argues that both parties get something from this kind of relationship. By piggybacking on the bitcoin block chain, Counterparty and other new services get pre-baked services including trusted timestamping, proof of publication, peer discovery and anti-DOS measures.

Bitcoin, in turn, gets to stay relevant, (s)he argues: "Bitcoin can be very conservative with the kinds of functionality that it directly supports, while still rapidly acquiring the new features that it needs to stay relevant and useful."

So now, Counterparty (which hasn't contributed to the bitcoin core's open source effort), and the bitcoin core (which has stated that it needs people using the protocol to pitch in) are stuck with each other, and neither is happy. Phantomphreak says that "a few of the Bitcoin developers are trying to prevent us from using the protocol as it stands, with all of the flexibility that it naturally provides."

Core developer Mike Hearn has an idea to cut through the whole tangled mess. In fact, he had it in 2012, before Counterparty or Mastercoin even existed. Instead of trying to store lots of data in a special field in the block chain, why not simply store a pointer to a third party, P2P data storage pool, he asks? This could be achieved using something called a distributed hash table (DHT).

"That way it doesn't matter how much data you want to store, the impact to the block chain is always the same," Hearn says. "Nobody is against that - it's why OP_RETURN is sized to allow for hashes. DHTs come in conveniently reusable libraries so it's hardly a big engineering challenge. Instead they turned it into some kind of stupid political fight."

Talking of fights, more tensions emerged among the core devs last week, and they're indirectly related to this question of who gets to use the block chain for what, and why.

0.9.0 reduced the transaction fees - the money paid to get a message processed by the network - tenfold. This is a good way to encourage microtransactions on the network by keeping the costs of a single transaction low, so that you could, say, pay pennies for downloading a single story.

Peter Todd, a contributor to the bitcoin code, told CoinDesk that he was worried that this would open the network up to spam and denial of service attacks, because people could use the cheap transaction fees to flood the network.

[post-quote]

Gavin Andresen, the Bitcoin Foundation's chief scientist and lead developer of Bitcoin Core, says that there are plenty of ways to slow down bitcoin transactions with DoS attacks - but he argues that they generally don't happen, primarily because the attackers would have little to gain. "I have never said that bitcoin is directly suitable for transactions less than a dollar; I think the jury is still out on how low we can go," he says.

Vitalik Buterin, developer of the soon-to-be-launched Ethereum project, argues that the concepts of transaction fees and storing messages on the block chain are connected. Transactions are badly thought out in the bitcoin protocol, he says. Some core developers have admitted this to CoinDesk, which is why they're working to change it using 'smart' fees.

If transactions were better managed, then people could just pay for what they wanted to store, Buterin says. Then, there would be no 'free rides'.

"It's the protocol's fault the OPRETURN battle is such an issue. In an ideal world, the concept of 'abuse' would not even exist; fees would be mandatory, and carefully structured to closely match the actual cost that a given transaction imposes on the network," he says. "If you can pay the fees for what you're doing then you should be able to do it, no questions asked."

It doesn't seem as though the core developers are about to change the OP_RETURN parameters to allow more data to be stored in the network. If they don't, then Counterparty has some options.

It can hack together an inelegant use of the multi-signature protocol to store its data. It can explore Hearn's idea of using pointers and distributed hash tables. Or it can simply jump ship and either build its own block chain, or use someone else's service. Perhaps Ethereum's for example.

But, PhantomPhreak isn't ready for that. "Ethereum is not really an alternative to Bitcoin for our purposes," PhantomPhreak told CoinDesk. It isn't tried and tested yet, the anonymous developer contends.

For now then, at least, some forward-thinking initaitives that want to expand beyond bitcoin's core services still feel as though they need the bitcoin protocol to do it. And it looks as though that's going to generate tensions, workarounds and in-fighting for some time to come.

Chain link image via Shutterstock