The Politics of Bitcoin Development

In a recent conversation with Christian Decker from Blockstream, Bitcoin Magazine’s Shinobi delved into the intricate politics of Bitcoin development. Decker, a lead Lightning developer, provided a candid look at the current competitive atmosphere where developers often find themselves entangled in political maneuvering rather than engineering matters. 

Decker did not mince words when describing the challenges developers face. “We have been trying way too long to be clever in as much that we try to sidestep the discussion of whether we want covenants, what kind of covenants we want, or introspection, as we like to call it,” he said. The community’s cleverness has led to fragmented efforts, with narrowly focused proposals struggling to gain traction amidst limited review cycles and intense competition.

Towards a new approach 

A major problem, Decker explained, is the combative environment where developers often have to “badmouth other proposals in order for your proposal to grab the attention that is needed to get your proposal through.” This creates unnecessary tension and frustration. Rusty Russell’s recent proposal, however, offers a refreshing change. It aims to restore Bitcoin’s original scripting functionality, providing a more unified and collaborative approach.

Decker emphasized the importance of involving the broader Bitcoin community in these discussions. “If it’s just seriously discussed, I think that can be an incredibly healthy thing for the larger and wider ecosystem’s involvement,” he said. Moving towards a cooperative direction where all stakeholders openly discuss the potential benefits and drawbacks of proposed changes can foster a healthier ecosystem. This makes it harder for people to dismiss ideas based on superficial associations and encourages a more honest and transparent dialogue.

The proposal to bring back Bitcoin’s original script functionality is about “giving everybody the tools to build whatever they want” without being restrictive. Decker believes this approach will lead to more meaningful and efficient optimizations over time. “It might be inefficient the way that you can do arbitrary things, but you can at least show your work and you can show it works,” he explained. Once these solutions are demonstrated, the community will naturally come together to optimize and improve performance.

Both Shinobi and Decker agreed on the need to rely on subject matter experts in these technical discussions. However, they also emphasized the importance of these experts presenting a balanced view of their proposals’ pros and cons. Decker pointed out that the current environment often incentivizes experts to present a one-sided picture, which can mislead the community. “In Bitcoin, until now, you always had to be very loud, you had to be very salesy, and you always had to present this, this is the upside of mine, but there’s the downsides of everybody else,” he said. This competitive atmosphere has hindered honest and transparent discussions.

Engineering first

Rusty’s proposal represents a significant shift in the way Bitcoin’s development community approaches script enhancements. By re-enabling the script’s original functionality, the community can move away from politicking and towards a more collaborative and innovative future. As Decker puts it, “Let’s approach this as engineers, which is what most of us are, and not as propagandists or salespeople trying to sort of just get your stuff done.”

This conversation sheds light on the ongoing efforts to improve Bitcoin’s scripting capabilities and underscores the importance of cooperation and honest dialogue in achieving these goals. As the Bitcoin community continues to evolve, proposals like Rusty’s offer a promising path forward for enabling more flexible and programmable money on the Bitcoin network.