A row that broke out online this month has raised an important question about bitcoin: should people be allowed to code their own rules, and even opinions, into their own versions of the software that runs the network?
The debate kicked off among users of Gentoo – a variant of the Linux operating system that prides itself on being highly configurable to suit different user requirements – when a user reported an issue on the Gentoo bug forum on 5th October.
The version of bitcoind (the official reference client for interacting with the bitcoin network) distributed with Gentoo was blocking particular bitcoin addresses, said the report, meaning that transactions with them wouldn’t work.
The posting showed Gentoo output blocking a transaction with a SatoshiDice address, which had been blacklisted.
“PEBCAK,” replied Luke_Jr (meaning ‘Problem Exists Between Chair And Keyboard’). “No sign anything is actually broken here. Looks like just a troll. Status: INVALID or WORKSFORME?”
And so the firestorm began.
‘Spamming’ the block chain
Luke_Jr is Luke Dashjr, a developer who runs his own mining pool and has stood for election to the Bitcoin Foundation board. He also maintains software packages for Gentoo and contributes to the bitcoin core development team.
Dashjr had written a patch for Gentoo’s version of bitcoind that specifically blacklisted bitcoin addresses used by several sites, the majority of which were gambling sites: SatoshiDice, BitcoinDice, Satoshibones, and Luckybit. It also blocked addresses operated by Mastercoin, and Counterparty. And the address discussed here as a spam attack on the network was also in the blacklist.
A code listing for the patch can be found here.
Dashjr argued that he hardcoded the blacklist into his patch because sites like SatoshiDice use bitcoin’s block chain in a damaging way. SatoshiDice and some other gambling sites use the block chain to return a bet’s result. That creates large numbers of small transactions on the network, which can put it under strain.
In the subsquent discussion on the bug forum, Dashjr called this model a “DDoS attack on the bitcoin network“. Sites that operate this way make it more expensive to run a bitcoin node by creating transactions as inefficiently as possible, he told CoinDesk. So he included the blacklist in a patch designed to nobble block chain ‘spam’.
Dashjr explained:
“While we do not have a proper fix for this issue yet, most of these can be identified by reusing specific addresses, and so I threw together a quick hack to filter them on that criteria. Obviously this hack is inappropriate for reference code, but it is a simple way to improve the spam filter in production until a better fix is implemented (which may then be proposed as a merge request and later released with the reference code).”
Disclosing changes
Dashjr’s change was a third-party implementation of the bitcoin core code. This contrasts with an ‘upstream’ change to the official reference version of the code, which can only be approved by a few members of the bitcoin core development community. Nevertheless, it provoked a mixed response.
Part of the problem, as suggested by bitcoin core developer Mike Hearn on a bitcoin developer IRC chat, was inadequate disclosure. The patch was turned on by default in the latest update to the software.
Hearn said:
“If they want to distribute a bitcoind with patches like Luke’s (which change behaviour in quite some fundamental ways), then they should do a proper upstream fork with a new name, so you are always sure what you’re getting.”
Dashjr conceded he could have provided better documentation of what the patch did. When users updated their Gentoo software, they would have seen a message indicating that a patch to bitcoind was being installed, he said, adding:
“Unfortunately, it appears not all users noticed this, and some even felt deceived. Additionally, I neglected to properly document the option, so other users were unaware that it extended the spam filtering with address matching (in fact, when I was adding the patch to the Gentoo package, I had actually myself forgotten it did).
In the future, I will try to improve documentation and awareness of users to get what they are expecting.”
Dashjr posted a public apology and turned off the patch by default, in addition to separating the spam management part of it out as a separate patch. For some outraged users, all is once again well in Gentoo land.
Deeper questions
However, the discussion raised some interesting questions. Some on the Gentoo bug discussion forum mused that coding a blacklist of addresses into an implementation of bitcoin constitutes censorship, and asked where that would stop, and who would decide what was blacklisted or not.
Is it right to try and code your own rules about how something will work into a version of the bitcoin software?
That depends, said Gregory Maxwell, a member of the bitcoin core development team, explaining:
“Some parts of bitcoin must agree exactly, bit by bit, in all nodes of the network or the system doesn’t work. We call these ‘consensus rules’, and they cover things like ‘is this block valid or not? It’s technically dangerous to the system to have any disagreement or diversity in the consensus rules.”
Other things are simply better if they’re well known and mostly uniform, he added, but they don’t strictly have to agree. This includes things like what transactions a node will relay.
Maxwell refers to these things as ‘policy’. Some diversity is helpful at this level, he said, because it can protect the network from large scale attack. If too much diversification occurs, it can detract from bitcoin users’ experience. “But diversity here can’t break the system,” he emphasised.
Even though Maxwell personally didn’t agree with Dashjr’s patch, he pointed out that’s just his opinion. People should be able to run what they like on their bitcoin nodes. After all, bitcoind is distributed under an MIT free-software license that gives developers that capability.
Looking forwards
In future, Dashjr would like to see a variable encoded into Gentoo that allowed different patches with different policies to be installed on the operating system.
He said:
“Such policies would remain patches and not be encoded directly into the reference code (which would itself become a ‘vanilla’ policy option).”
Dashjr is also working on an extension to bitcoin core that would move all policy decisions to a new ‘class’. In the accompanying online discussion for this fork, he argues for having bitcoin nodes with multiple policies.
Mike Hearn takes a harder line on running custom code that validates bitcoin transctions in its own way, arguing that just because a license allows you to do something doesn’t mean that you should:
“Luke pushes this idea of ‘policy’, but there can be no policy in bitcoin transaction management. If miners or merchants diverge, then the result is payment fraud. That is not an acceptable outcome, seeing as the entire purpose of bitcoin is to block double spending.”
Dashjr argues that it can be dangerous if people modify or reimplement the Bitcoin consensus code, and gives libbitcoin and btcd as examples. He doesn’t think that experiments with consensus code should be stopped, as long as people are aware of the dangers.
He doesn’t view experiments with policy changes as dangerous, arguing instead that they’re beneficial.
“Policy changes in particular are expected of nodes, especially miners, and the reference code for policy is intentionally kept fairly conservative and not intended for use as-is at all really,” he said.
When recycling is bad
Perhaps they’ll have to agree to disagree, but there’s another issue at stake: reused bitcoin addresses.
Many sites that add material into the block chain, like SatoshiDice, reuse bitcoin addresses, and many developers, Dashjr and Maxwell included, consider this to be a bad thing. After all, reused addresses were what allowed Dashjr to block certain sites.
If an organisation or individual continually reuses a bitcoin address, then it makes them more easily identifiable on the network, and also makes it easier to identify people transacting with them.
That can lead to all kinds of problems, Maxwell warns, including censorship. After all, that’s how Dashjr identified the sites to blacklist in the first place.
If address reuse proliferates among bitcoiners, then censorship by patches like Dashjr’s will be the least of their worries, warns Maxwell.
He explained:
“If people use bitcoin in a lazy, easily censorable way where they are reusing addresses – which were always intended to be one-time in the design of the system – then this creates a serious systemic risk in that someone might try to order nodes, developers, and/or miners to censor the system.”
Educating people and creating better tools is one way to mitigate the issue, Maxwell suggested. But what about Dashjr’s patch blacklist?
“I can sympathize some with the logic of getting people to fix their vulnerable usage by attacking them,” he concluded. “Maybe it will be effective, but attacking people isn’t something I can support.”
Blacklist image via Shutterstock