When determining consensus in the blockchain community, right and wrong isn’t always “Black” and “White”.
On September 7, Bitcoin Core developer Wladimir van der Laan tweeted that he may be “done with coins” all together. He later confirmed to Cointelegraph that he was indeed taking a break from his duties as a Core developer and one of the custodians of the project’s Github repository. One of the factors that led him to this decision was a Twitter storm that lasted for days and was caused by the renaming of a variable that specifies a list of characters that cannot appear in filenames due to operating system restrictions.
Source: Bitcoin Github repository.
How could something this seemingly innocuous lead to a Twitter storm, which in turn, led to a temporary departure of a developer who has been working on Bitcoin since 2014?
The variable in question is a parameter which was originally named ‘FILE_CHAR_BLACKLIST’. On June 9, Github user TrentZ proposed that this should be changed it to a name which was, in his opinion, more appropriate — FILE_CHAR_BLOCKLIST. The noted motivation was that some developers could be offended by the use of “black” in the original filename as a way to denote a negative result, while the alternative use of “white” would reference a positive conclusion. There was no consensus at the time about this change, but after a while, the discussion petered out.
The conversation around the use of “Black” and “White” in-reference to “Bad” and “Good” variables respectively is not unique to the blockchain community. In April 2020, the U.K. National Cyber Security Centre announced that they would begin using “Allow” and “Deny” in place of what some see as divisive language rooted in colorism. Likewise, IT giant Cisco Systems too announced that their security division would use the new naming scheme in their code.
Two days ago, another Bitcoin contributor named Verretor proposed another change to this variable’s name, this time changing ‘FILE_CHAR_BLOCKLIST’ to ‘FILE_CHARS_DISALLOWED’. It appears that his proposal was not motivated by positive or negative connotations, instead, he believed that the current name was ambiguous:
“Blocklist is ambiguous. It could mean a list of blocks. Example: “blocknotify” in the same file refers to Bitcoin blocks.”
That is when all hell broke loose as the debate that started on Github migrated over to Twitter. One side of the debate was stressing the need for the Bitcoin community to be more inclusive starting with the code, while the other side believed that this was a case of politicizing issues that are not political in nature. Another Bitcoin Core developer Luke Dashjr explained why all previous proposals were ambiguous, and submitted his own:
“This isn’t about blocking anything, so blocklist is technically wrong. “Blacklist” has actual ambiguity issues too. What this list is doing, is listing characters to exclude from filenames, because the OS (or our libraries) are known to not support them in filenames. ”I think FILE_CHAR_EXCLUDE is fine.”
Blockstream CEO Adam Back told Cointelegraph that he finds the situation ironic, considering that the battle arose over a variable that appears in test code:
“There’s a triple irony that it was badly named it’s not even a blacklist it is a list of letters that can’t appear in OS filenames. And it’s in some test code so it’s not even in the Bitcoin binary.”
It now seems as though a reasonable compromise has been reached. Dashjr’s proposal was never formalized, leaving us with FILE_CHARS_DISALLOWED at time of publication.
