Bitcoin Core devs take the stage at MIT to discuss Taproot, protocol consensus and promising new projects

During a panel appearance at the MIT Bitcoin Expo this weekend, a group of developers who closely work on bitcoin's open-source software discussed why protocol changes – and the host of complexities they bring – are often slow in the making.

On Saturday, four Bitcoin Core developers – Pieter Wuille, Amiti Uttarwar, John Newbery, and Cory Fields – discussed their philosophies for conducting Bitcoin Core development work, progress on the proposed Taproot/Schnoor soft fork as well as other projects that excite them most.

Bitcoin's consensus layers have not seen any soft fork or hard fork for over two years. The last upgrade was Segregated Witness (SegWit), which was activated in Aug. 2017 and currently sees a 60% adoption rate, according to available data.

According to the panelists, the next possible upgrade would be Wuille's Taproot/Schnorr soft fork. Although Wuille remains optimistic about the project's prospects, contending that developers are "pretty much done with the proposal," he also conceded that the steps forward are not yet certain and are "very much up to the community."

Addressing the perception that Bitcoin is simply not changing fast enough, Newbery, who currently works as a protocol engineer at Chaincode Labs, stated that the Bitcoin Core team has a more security-focused mindset compared to other software projects.

"Bitcoin Core, unlike many other projects, is very focused on security," he said during the Bitcoin Core panel. "If we get something wrong, people lose money, or if we get something else wrong, we destroy an entire economy."

In fact, he said, much of the daily work as Bitcoin Core developers consists of unglamorous grunt work that is, however, crucial for keeping the whole network secure and operational.

"There's a lot of stuff going on that users are not aware of but is very important," he said. "Things like improving the internal interfaces between different modules, refactors, cleaning up, improving and testing.

In terms of testing, for example, there's been much progress in the past two years to enable fast testing and improve unit testing. "All of that unglamorous stuff is very important," he added.

Bitcoin politics: reaching consensus

Indeed, deploying new changes on Bitcoin involves a prolonged process of getting everyone in the ecosystem on board. Andrew Poelstra, director of research at Blockstream, chimed in on the topic during a separate presentation on Taproot/Schnorr.

According to him, a contributor would have to have a detailed description of the proposal, get the code written, and have a fair amount of buy-in from the developer community just to get assigned a Bitcoin Improvement Proposal (BIP) number, which in itself "means almost nothing," he said.

Then, the contributor would have to go through what is usually a years-long process of review to get input from various stakeholders – miners, protocol developers, wallet developers, HSM developers, retail users, institutional users, exchanges, custodians, etc. – who all have economic stakes in the system and, at times, opposing goals and objectives.

"Participants are generally afraid of changes and complexities," Poelstra said. "If any change makes their life meaningfully worse without giving them significant benefits, they are going to complain and you will not get your proposal anywhere except for endless fights on the development mailing list."

Many software projects are deploying new, experimental changes, he pointed out, but Bitcoin is different because the stake of getting something wrong is too high. This is especially true considering the outside world's perception of Bitcoin. While developers might feel frustrated at the slow pace of changes on Bitcoin, he argued, outsiders already see the technology as fast-moving and somewhat reckless.

"Bitcoin currently has a cap of $170 billion," he said. "When we deploy changes to Bitcoin in the worldwide consensus system, these changes can't be undone...If people lose their money, it's game over, probably for the whole cryptocurrency space, because that would be such a tremendous loss of faith in this technology."

Moreover, despite the fast pace of research being done on exciting new functionalities that Bitcoin could potentially enable, right now Bitcoin developers are tightly focused on improving validation speed and making the protocol more scalable.

"Bitcoin is by far the most scalable cryptocurrency that's deployed anywhere and it's probably not scalable enough for serious worldwide use," Poelstra said. "So we are very hesitant to do anything that's going to slow down validation, or even do anything that doesn't speed up validation. That's the most pressing concern."

Taproot to enable new functionalities

The proposed Taproot/Schnorr soft fork was at the center of discussion during the MIT Bitcoin Expo. As previously explained, it offers a much-needed privacy feature by making all transactions – be they simple payments between two people, sophisticated smart contracts, or the opening and closing of Lightning channels – appear the same to observers of blockchain data.

The soft fork proposal underwent a series of structured reviews late last year and was formally proposed as BIPs 340-342 by Wuille in Jan. 2020, a year later than when the idea was first unveiled by Bitcoin Core developer Greg Maxwell in Jan. 2018.

"We've been working with a small group of people, including Anthony Towns, Jonas Nick, Tim Ruffing and a number of contributors," Wuille said during the panel. "There's also been lots of feedback from the Optech-organized structured review sessions that brought in initially over 100 people."

"We are still making a few small changes," he continued, referring to the couple semantical changes he made last month around even public keys and nonce generation. "But apart from them, I think we're pretty much done with the proposal."

Besides granting the protocol a higher degree of privacy, the soft fork would also make it easier to introduce new opcodes, as Wuille pointed out.

The traditional way of introducing opcodes is through an OP_NOP, he explained, which is an opcode that does not do anything and can be redefined into another opcode that either does nothing or abort. Such an approach has brought in opcodes like OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY.

"We're really restricted about what we can do in trying to harness this new functionality in these verify style opcodes," Wuille said. "With the script improvement we proposed within taproot, called tapscript, these opcodes are redefined from having no effect to automatically succeeding. You can redefine it into anything in a soft fork compatible way."

Newbery also discussed the wide range of functionalities that Taproot/Schnorr would enable, from threshold signatures to paying for signatures over the Lightning Network.

"There's a huge space to explore before we even talking about the next thing," he said.

Other exciting projects on Bitcoin

Bitcoin development work has many components, and all four panelists discussed current projects that excite them.

On peer-to-peer implementation, Wuille highlighted Uttarwar's work on rebroadcasting logic, Suhas Daftuar's work on package relay, and Erlay, a proposal to improve the bandwidth usage of Bitcoin nodes.

On the wallet side, Wuille pointed to Andrew Chow's working project on descriptor wallets, which would give automatic support for hardware wallet multi-signature with the integration of mini-scripts and other complex scripts.

"It's a big effort to revamp the idea of what a wallet is," Wuille said. "Just seeing the functionality of Bitcoins scripts that have been there all along actually become usable – at least within bitcoin core, but hopefully affecting other projects too – that's also something I'm really excited about."

Uttarwar is looking forward to projects that rethink how the Bitcoin network should be treated as a whole. Suhas has recently introduced the idea of block-relay-only connections. Historically, Uttawar explained, the same network is used to propagate transactions, blocks, and address messages, which she argued doesn't make sense in a longer-term vision of Bitcoin.

"Breaking out these block-only connections is a move toward creating networks that deliver different kinds of messages," she said.

For Fields, who currently works at the MIT Digital Currency Initiative, Michael Ford's research on reducing Bitcoin Core binary size is particularly exciting, since it would allow the system to get rid of unnecessary codes and libraries.

Newbery believes Carl Dong's work on Bitcoin build system security is especially important. Dong is working on deterministic and reproducible build, which adds a lot of confidence to the Bitcoin Core team as it distributes this project.

"This is the stuff that doesn't get talked about too much, but it's really important," Newbery said.

© 2026 The Block. All Rights Reserved. This article is provided for informational purposes only. It is not offered or intended to be used as legal, tax, investment, financial, or other advice.