Bitcoin Core data and protocol evolution

Bitcoin Core 30 increases the OP_RETURN data limit from 80 bytes to nearly 4MB. This change addresses data storage and UTXO issues, though critics say it encourages non-financial data on the blockchain. Dashjr notes that Ordinals bypass the -datacarriersize limit by obfuscating data as program code. A ledger finishes by carrying ML-DSA alongside secp256k1 for as long as it exists. The removal of an old verifier makes re-executing old blocks impossible. This differs from ordinary software where deprecation scales with the usage percentages of the features. In a system that validates its own history, the cost of removing a historical call matches the cost of removing a billion. A blockchain has no final step where you remove an old algorithm. One escape hatch involves stopping the validation of history and trusting a checkpoint instead. This swaps a cryptographic property for a social one. OpenSSL 3.0 classified RIPEMD-160 as legacy, but the management committee voted an exception to put it back into the default provider because Bitcoin depends on it. Ethereum still ships the RIPEMD-160 precompile at address 0x03, with ethPandaOps measuring 233 calls across 60 days of mainnet.

Mempool and transaction relay

Antoine Riard proposed two BIPs for nodes to signal they will no longer accept unsolicited transactions. These unsolicited transactions, which consist of tx messages in the P2P protocol that a node has not previously requested using an inv message, allow spy nodes to map network topology or disrupt nodes by filling transaction queues. While software like bitcoinj uses these messages to save bandwidth, they create privacy risks. The submitpackage RPC in Bitcoin Core remains experimental and lacks package relay support. This lack of support means users cannot rely on the tool to propagate child transactions with high fees to bump parents. A spy node using unsolicited transactions can measure how a transaction propagates and identify which node originated it. Attacker-controlled transactions can fill a victim’s queue to prevent that node from receiving transactions from peers. The standard Bitcoin Core flow relies on sending an inv message with a hash, receiving a getdata message, and then receiving a block or transaction message.

Validator priorities and privacy

Silent Payments (BIP-352) lets recipients generate unique Taproot addresses from one public key using a mathematical formula. Users must scan the blockchain to detect these funds. Antoine Poinsot argues that narrowing the project scope makes it harder for individuals to validate transactions with personal nodes. He points out that many modern wallets rely on third-party software because Bitcoin Core lacks useful interfaces. The project has removed several interfaces that once served millions of wallet users. Poinsot believes that the security of bitcoins depends on enough motivated individuals connecting their wallets to personal full nodes to ensure consensus rules remain reliable. He mentions that the rejection of an SPK index or RPC-SSL access prevents users from validating transactions privately. He also notes that many wallets, such as Sparrow or Liana, use a watch-only Bitcoin Core wallet in the background. These wallets rely on the approach pioneered by Electrum Personal Server. The ability to spend autonomously depends on enough highly motivated individuals connecting their wallets to their own personal full nodes. If everyone with a wallet connects to Bitcoin Core through a third party, those third parties can arbitrarily change Bitcoin consensus rules. The multiprocess interface will give users access to an enhanced interface to get information and signals from the node. Does the project prioritize the needs of developers or the security of individual users?