Gavin Andresen urges Bitcoin developers to “know your customer.” And no, he is not talking about regulation. Mr. Andresen admits he did not always make the ...
Gavin Andresen urges Bitcoin developers to “know your customer.” And no, he is not talking about regulation.
Mr. Andresen admits he did not always make the right choice during the two years he spent as Bitcoin’s first, and only, developer.
He remembers once asking himself whether or not Bitcoin should be used as a store of value or a means of exchange. “In hindsight, I should have spent more time working on the secure store of value problem; maybe Core would have great support for creating paper wallets and sweeping funds from them if I’d chosen differently.” He has called Bitcoin in the past “cash for the internet.”
The Bitcoin ecosystem is incredibly rich and robust these days, Andresen, who first programmed 3D images, celebrates. “I can’t keep track of all the development that is being done, and I’m excited to see multiple implementations of the Bitcoin protocol slowly starting to gain acceptance,” he wrote on his blog. “It will be a long process, but moving away from One True Implementation will be very good for Bitcoin in the long run.”
Andresen, who was appointed by Satoshi as Bitcoin Core lead developer, even lends advice for those making implementations of Bitcoin: “keep it simple as possible and know your customer.” Mr. Andresen went further on Twitter and defined “user” as “non-paying customer.”
Andresen, a Princeton graduate in the class of 1988, says one particular implementation should not do it all. “[F]igure out who your customer is and then build exactly what they need that they can’t already get from somewhere else.”
Andresen, who conceived the Bitcoin Foundation, says that if one’s customer is big mining pools and miners, they should talk to them to learn what it is they desire.
“Find out what they’re running and figure out what they need,” Mr. Andresen writes. “If your software will be running on Internet-facing machines then it shouldn’t be storing private keys at all – it is really bad security practice to keep private keys on the same machine that is talking to the rest of the world. If your customer is techno-weenies who love to tinker with stuff, then distribute a Docker image with some geek-friendly (non-GUI) interface.”
Mr. Andresen, who believes there should exist a “hair on fire” emoji according to tweets, wonders what it would be like if he were a lead developer for Bitcoin Core. “I don’t know what I’d do. I don’t think there would be consensus for ‘who is the Bitcoin Core customer’.”
He adds: “[A]nd any proposal for major changes like ‘get rid of the wallet code, it is a terrible idea to keep private keys protecting potentially millions of dollars on a machine that is accepting connections from the Internet’ or ‘drop support for Windows and OSX, all the active developers are Linux geeks’ would be painfully controversial.”
Mr. Andresen doesn’t regularly post to his blog, but when he does, the Bitcoin developer community pays attention. Satoshi’s entrusted developer, who caused controversy early in Bitcoin’s existence by visiting the CIA to discuss the digital currency, had his commit access to the Bitcoin code repository stripped by Wladimir Van der Lann amid the Craig Wright-as-Satoshi controversy, when Mr. Andresen shocked the Bitcoin world by confirming Mr. Wright’s identity. Mr. Wright never cryptographically proved that, indeed, he is Satoshi Nakamoto. (but, perhaps, he lost his password) Mr. Andresen later retracted his statement.
Since his removal from the Bitcoin Core repository, Mr. Andresen has remained active and never vengeful. He advocates for open-source developers to pay attention to the governance aspects of their prospect – a design aspect Bitcoin has seemingly lacked.
On social media, Mr. Andresen has called attempts to paint hard forks as too risky “paternalistic”, and has even suggested Bitcoin Core developers use a more neutral language in discussion about Bitcoin implementations and proposals.
“I think a neutral statement from Core like ‘IF there is a hard fork over the block size, Core software is able to follow either branch’ along with a trivial patch/option that, again, simply skips the validation checks for max base block size / max block sigops / max segwit block size if the option is set – would be a really good way of extricating the Core project from the insanity of the debate.”
Featured image from Flickr.