Somsen suggests saving a list of 7 MB of initial transactions for data review.
It proposes to adjust 2010 block rules so that Bitcoin Valid transactions in a simpler way.
While the Bitcoin (BTC) collaborators community debates changes in the Bitcoin Core client and the elimination of the limit in OP_return transactions, developer Ruben Somsen has indicated a potential failure in the protocol.
The problem detected, and linked to the proposal for improvement of Bitcoin 30 (BIP-30) On its rule of duplicate transactions, it could generate risks in an unlikely scenario of reorganization of the network.
An alleged failure, according to Somsen
Ruben Somsen, known for his contributions to proposals such as Silent Payments, published an analysis on the mail list on April 27, 2025 Bitcoindevwhere identified a failure in BIP-30a proposal created by Pieter Wuille and implemented in 2012 to prevent duplicate transactions in Bitcoin.
The possible failure, although of low probability, could cause a bifurcation in the network If there was a block reorganization of the year 2010, a scenario that the current control points (Checkpoints) mitigate. This bifurcation would imply a change in the rules that require that all nodes update their software, also known as “Hard fork”
A reorganization, meanwhile, occurs when Bitcoin nodes replace a block chain with a longer one, something that requires immense computational effort for 2010 blocks.
The BIP-30, active from the Genesis block until March 2013 (Block 227,931, when the BIP-34), seeks to prevent Two transactions with the same identifier (txid) coexist In the file if your outputs have not been spent. In Bitcoin, each transaction generates non -spent exits (UTXO), which are the funds available to spend on future transactions. The BIP-30 verifies that a new transaction does not believe an existing exit In the UTXO set, which could cause “confusion” in the nodes and allow double expenses.
Somsen explains that the problem lies in two historical exceptions of coinbase transactions (which generate new bitcoins in each block) in 2010, located in blocks 9172/91880 and 91812/91842.
In block 91880, the Coinbase transaction overcame that of block 91722, eliminating it from the UTXO set. If a reorganization between these blocks occurs, the nodes that process reorganization would eliminate the overall output, while the nodes that do not witness it would keep it. If this exit will be spent later, The nodes would have inconsistent utxo sets, which would cause a bifurcation.
«The problem occurs when we reorganize the blockchain to a point between blocks 91880 and 91722. The overall output disappears completely from the UTXO set. A node that did not witness the reorganization, however, will still have that utxo as a whole. If that utxo is spent, it would result in a bifurcation, ”says Somsen.
How real is the risk?
The risk indicated by Somsen is theoretical, since it requires a reorganization of the bitcoin network until 2010, something practically impossible Due to the enormous amount of work accumulated in the chain and the control points that, until 2013, prevent that reorganization. However, the community is considering eliminating these Checkpointswhat the “theoretically exploitable” failure would do, although not practical, according to the developer.
Somsen does not advocate immediate action, since “the status quo seems quite sustainable.” However, he proposes two solutions to mitigate the problem. The first is to prohibit partial reorganizations between blocks 91722 and 91880, forcing the nodes to reorganize the 160 complete blocks or none. “Considering that they are only 160 blocks with the low mining difficulty of 2010, this would not be a great restriction,” he explains.
The second solution, suggested after discussions with developer Sjors Provoost, takes advantage of the possible elimination of Checkpointsconsidered a Hard fork (change incompatible with previous versions). This would allow modifying the pre-2013 consensus rules To prevent coinbase transactions from blocks 91880 and 91842 to be eliminated during reorganization, which would correct the failure.
BIP-30 inefficiency: Somsen’s analysis
Beyond the consensus failure, Somsen highlights the inefficiency of the BIP-30, which requires Verify the entire UTXO set for each transactionan expensive process in computational terms. This verification would complicate alternative validation methods exposed by Somsen, such as Utreeexo, which would reduce the size of the UTXO set, Swifttsync, which accelerates the synchronization of nodes, and Zerosync, based on zero knowledge tests (Zero Knowledge).
The developer proposes to replace this verification with a cache of Coinbase (TXIDS) transactions, which would occupy about 7 MB to block 227931, ensuring that There are no duplicates. In addition, it suggests verifying that Coinbase transactions do not conflict with the BIP-34 rules, which guarantees the uniqueness of these transactions, even in case of reorganization. “We can replace the inefficient verification of the BIP-30 UTXO set with a coinbase uniqueness verification,” says Somsen.
Luke Dashjr’s answer
Developer Luke Dashjr, CTO and co -founder of the Mining Pool of Bitcoin Ocean, responded to Somsen’s proposal with two additional solutions.
The first suggests treating the overwrite of a transaction as an expense, restoring the original UTXO. The second proposes not to create the UTXO that will be overwritten when detected for the first time.
However, Dashjr questions Somse’s proposal to use a txid cache, arguing that verifying 7 MB of data by transaction It is less efficient than to compare 64 bytes. “It sounds strictly worse than how we handle it today,” he said.
In Bitcoin, the current method to identify a transaction is based on comparing the TXID, which is the transaction hash. That hash is generated using SHA-256 and its size is 32 bytes.
Dashjr could be thinking of a context where two 32 -bytes hashes are compared (for example, one txid and another identifier), which would add 64 bytes. However, in the BIP-30 verification, only a 32-bytes TXID is used per transaction.
A debate for the future of Bitcoin
Somsen’s analysis, backed by discussions with experts such as Antoine Poinsot, Pieter Wuille and Sjors Provoost, puts on the table a failure that, although remote, underlines the importance of reviewing the Bitcoin consensus rules.
The BIP-30 failure does not represent an immediate threat to Bitcoin users, but its identification reflects the developers’ commitment to the safety of the network created by Satoshi Nakamoto.
