Bitcoin Core developers Gavin Andresen, Cory Fields and Wladimir van der Laan expanded on their larger vision for development of the open-source bitcoin project at an event held yesterday by their new employer, MIT Media Lab.
In the hour-and-a-half session, moderated by MIT Media Lab director Joi Ito, Andresen voiced his belief that bitcoin needs to evolve away from having one dominant software implementation, stating that he believes the project to be in the midst of this transition.
The remark comes amid a larger debate focused on updating bitcoinâs software to allow for a greater number of transactions to be included in blocks, and found the developers seeking to add nuance to the debate. For example, Cory Fields, positioned the current situation as analogous to when the Internet primarily relied on one browser.
âInternet Explorer 6 at one point defined the internet,â Fields said. âWeâre in the process of trying to get away from that one true implementation that we have now.â
Overall, the talk found the developers seeking to make known their vision for an open-source project that, despite being the subject of more than $900m in venture capital investment, remains mired in governance considerations and philosophical debates.
The process found Andresen, bitcoinâs long-time maintainer, offering his interpretations of how the project should be defined:
âThere are three things I think of when I hear bitcoin, the digital currency, the digital cash of the Internet, thatâs lowercase âbâ bitcoin, thereâs bitcoin the code that runs the network and then thereâs bitcoin the protocol.â
Fields said that, to date, development discussions have so far grouped together management of the code with the protocol itself.
âA lot of other protocols start with high-level description. We started with the code Satoshi [Nakamoto] wrote, and have to get rid of all the nasty corner cases weâre finding ⦠[But] we are getting to a place where one could write a protocol specification document and have it be 100% correct,â he continued.
Elsewhere, Andresen proposed that having multiple versions of the bitcoin software â such as Bitcoin Core and his proposal Bitcoin XT (though it was not named directly) â would guard against scenarios where issues with one implementation could take down the entire network.
âThere are efforts to break Core up into more manageable chunks ⦠Thereâs this huge industry resting on your shoulders, you have a huge responsibility not to screw it up,â Andresen said, adding:
âOne way to screw it up is to not do anything. It does have to evolve.â
The developers also sought to make clear their view of where development challenges currently reside, noting how bitcoin remains a unique open-source project due to its design.
âAny software project has interesting challenges,â Fields said. â[But bitcoin operates on] consensus. Where most coders are used to the idea of if you implement it this way, and if you get this answer, itâs wrong. In bitcoin, the generally accepted answer is the correct answer, even if itâs wrong.â
Andresen went on to note how this need to achieve consensus across a diverse array of network participants means that development of the software is naturally slow and that easy solutions for other types of software donât translate well to this environment.
âAuto update gets brought up often,â Fields said. â[But in bitcoin], upgrading is a vote, whether itâs the node or wallet youâre running. So itâs not really possible for us to implore you to jump to the new [software version].â
Andresen indicated that he believes Bitcoin Core needs to do more to incentivize miners who process transactions to upgrade software by packaging releases with this group in mind.
âItâs always a challenge to get miners to upgrade, part of that is giving them something they want, making it faster, more efficient, using less CPU, less network bandwidth,â he continued. âThere has to be some reason for them to upgrade.â
Ito directed a number of questions toward encouraging the developers to articulate how they might respond to more unusual challenges, such as if government regulators attempted to put pressure on the project.
Here, Andresen suggested that he believes itâs âhard to imagineâ how regulation could be crafted for the protocol given that such rulemakings usually affect the businesses using a technology.
â[People talk about] what if the current maintainers get swayed by regulators, but itâs not even clear, if some government could hold a gun to our heads, itâs unclear what we could do,â he remarked.
Fields suggested pressure could come if Bitcoin Core developers sought to enable software users to make transactions âentirely anonymousâ through their work on the protocol.
Ito then voiced his opinion of how concepts like money laundering are often a matter of definition calling it a âmeta crimeâ. He went on to note that while the US might âexpect transparencyâ in transactions made by its citizens and entities, a greater level of privacy from such oversight may be desired in countries with more authoritative regimes.
Andresen responded by stating his view that anonymity should be a feature of bitcoin wallets that allow transactions on the network, but that his team could provide the tools for these designs.
âThe low-level protocol privacy features could be controversial. [But] if they are cryptographic primitives, it would have some other use,â he added.
As for how they see the question of bitcoinâs software capabilities, like the size of transaction blocks on the network, moving forward, the developers were less clear, remarking that they donât âpretend to understandâ what they view as a new and novel argument.
âThere are so many different perspectives and variables and things that need to be analyzed and discussed. I think the reason that itâs such a sexy and divisive issue is because itâs really easy to take one and say this thing matters, this is important to me, so Iâm going to jump on this and it can appear easy,â Fields said.
To this, Ito drew on his experience at ICANN, the nonprofit group that oversees top-level domains on the Internet protocol, advising that an open and tiresome dialogue can be the most beneficial way to solve issues between diverse stakeholders.
âThe thing is by making ICANN completely open and not eliminating people from showing up, you eliminate the argument that they werenât able to participate or werenât able to be in the conversation,â Ito advised.
The developers suggested that such a scenario is likely to play out at the upcoming Scaling Bitcoin conference in Hong Kong.
As for any additional specifics about the follow-up to Septemberâs well-received inaugural Scaling Bitcoin conference in Montreal, the developers were less clear.
Andresen, for example, distanced himself from the idea that the developers should be the decision-makers at the event, to be held from 6th to 7th December, arguing that the community will need to have the final say.
âItâs not the developers deciding what bitcoin should be. Itâs everybody in the ecosystem needs to decide how bitcoin should evolve and whatâs it going to be,â he said.
Andresen implied he may ultimately encourage a governance structure for the conversations that draws on Itoâs approach, indicating that there will be follow-on meetings.
âUltimately I decided everybody would be in a room and do whatever [they] feel like, just because itâs so hard to commit to something and say we really can knock this out. I think thatâs overambitious,â he said.
As for firm details about Scaling Bitcoinâs agenda, the website is also vague at this time, noting only that its call for proposals has now closed and that block size proposals will be included in the conferenceâs itinerary.
Images by Pete Rizzo for CoinDesk