Watch the full episode:
From BDK to Bitcoin Core: a leap into the unknown
Daniela Brozzoni joined Bitcoin Core after a period of friction within the BDK (Bitcoin Development Kit) team, where she had worked for years and eventually became a maintainer. The move to the heart of protocol development was not painless: for roughly three months she worked without a salary, drawing on savings, before receiving two grants from Open Sats and the Human Rights Foundation. Her entry was built on the reputation she had accumulated over previous years in the Bitcoin open-source ecosystem.
Day-to-day work on Bitcoin Core is far from the romantic image of the solitary genius rewriting the rules of money. It consists mainly of reviewing other contributors’ code – the so-called pull requests – and analysing issues reported by users. In her first weeks, Brozzoni recalls, she would read other people’s changes without being able to spot errors, even when errors were there. Over time, the eye sharpens.
The maintainer is not the boss: how governance actually works
One of the most clarified points in the interview concerns the distinction between developer and maintainer, a distinction often confused in public debate. In traditional open-source projects the maintainer holds a command role. In Bitcoin Core it works differently.
The fact that the maintainer has the power to click yes or no does not mean the maintainer is deciding. The maintainer is simply a reflection of what the entire Bitcoin Core project – or a portion of its developers – wants.
The maintainer in Bitcoin Core performs an almost operational-support role: managing the routine tasks that keep the team’s work flowing, mediating conflicts, and applying decisions already reached within the developer community. The real choices – especially those concerning consensus rules, the core of the protocol – are made collectively. And when a soft fork or hard fork is at stake, the decision-making perimeter widens further to encompass the entire community of node operators.
OP_RETURN and Peter Todd’s proposal: what the debate is about
The debate that has divided the community in recent years centres on a Peter Todd pull request on GitHub: the removal of the 80-byte limit on the OP_RETURN field in Bitcoin Core’s mempool policy. OP_RETURN is a field created specifically to embed non-financial data in Bitcoin transactions – an official waste bin, of sorts, for anyone who wants to write data on the blockchain without creating spendable outputs.
The key distinction to keep in mind is between consensus rules and mempool policy rules. The former define the absolute validity of a transaction for the entire network. The latter are more restrictive rules that each node applies to its own mempool – the limbo where transactions wait to be mined – and can vary from node to node. If a transaction fails a mempool filter, it is not propagated across the network, but it can still be delivered directly to a miner.
The rationale behind Todd’s proposal, also supported by Gregory Maxwell, was to solve a concrete problem: those who want to inscribe data on-chain circumvent the limit by using so-called fake public keys – Bitcoin addresses that correspond to no real key. This approach bloats the UTXO set – the registry of all unspent outputs that every node must keep in memory – with entries that can never be removed, because those bitcoin will never be spent. Expanding OP_RETURN would channel this practice toward a field that does not pollute the UTXO set.
The sticking point: filters, miners and decentralisation
The opposing faction, represented largely by Bitcoin Knots users, argues that any relaxation of filters amounts to incentivising non-monetary use of the blockchain, regardless of the technical mechanism involved. The debate has also intensified because the two factions speak different languages: one technical, the other philosophical and social.
Brozzoni highlights a technical argument frequently overlooked in public debate: desynchronisation of mempool filters across nodes harms the functioning of compact block relay, the protocol that allows blocks to propagate rapidly across the network. When part of the network is unaware of transactions included in a block because it has filtered them out, broadcast slows. And that slowdown advantages the larger mining pools.
I do not want a Bitcoin that is completely legal, absolutely not. Bitcoin is already wonderful as it is because it is useful as it is – for me and for many people who share my ideas about how money should work.
Added to this is the question of out-of-band payments: transactions delivered directly to miners, bypassing the network, generate an extra revenue stream accessible only to pools with sufficient hashrate to make the service attractive to users. Only those mining a significant share of blocks can offer reasonable confirmation guarantees. The pressure toward mining centralisation, in this scenario, grows.
Node governance as the last line of defence
Beyond the technical merits, the interview with Brozzoni illuminates a structural tension in Bitcoin’s governance: the difficulty of finding shared discussion space between developers and users. GitHub is perceived as developers’ territory; user comments are hidden or removed when they are not technical. Mailing lists are hostile to non-experts. Twitter is ill-suited to technical argument.
The ultimate answer, Brozzoni notes, lies in the nodes. It is node operators – not developers, not maintainers – who choose which software to run and therefore which rules to apply. Running a node gives a direct and concrete voice in the protocol’s direction, far more so than any discussion on GitHub.
Watch the full episode on YouTube
Share on X
