This week’s newsletter shares an analysis about syncing full nodes without old witnesses. Also included are our regular sections with descriptions of discussions about changing consensus, announcements of new releases and release candidates, and summaries of notable changes to popular Bitcoin infrastructure software.

News

  • ● Syncing full nodes without witnesses: Jose SK posted to Delving Bitcoin a summary of an analysis he performed about the security tradeoffs of allowing newly started full nodes with a particular configuration to avoid downloading some historic blockchain data. By default, Bitcoin Core nodes use the assumevalid configuration setting that skips validation of scripts in blocks created more than a month or two before the release of the version of Bitcoin Core being run. Although disabled by default, many users of Bitcoin Core also set a prune configuration setting that deletes blocks some time after validating them (how long blocks are kept depends on the size of the blocks and the specific setting selected by the user).

    SK argues that witness data, which is only used for validating scripts, should not be downloaded by pruned nodes for assumevalid blocks because they won’t use it for validating scripts and will eventually delete it. Skipping witness download “can cut bandwidth usage by over 40%,” he writes.

    Ruben Somsen argues that this changes the security model to some degree. Although scripts aren’t validated, the downloaded data is validated against the commitment from the block header merkle root to the coinbase transaction to the witness data. This ensures the data was available and uncorrupted at the time the node was initially synced. If nobody routinely validates the existence of the data, it could conceivably be lost, as has happened to at least one altcoin.

    The discussion was ongoing at the time of writing.

Changing consensus

A monthly section summarizing proposals and discussion about changing Bitcoin’s consensus rules.

  • ● Quantum computing report: Clara Shikhelman posted to Delving Bitcoin the summary of a report she co-authored with Anthony Milton about the risks to Bitcoin users of fast quantum computers, an overview of several pathways to quantum resistance, and an analysis of tradeoffs involved in upgrading the Bitcoin protocol. The authors find 4 to 10 million BTC are potentially vulnerable to quantum theft, some mitigation now is possible, Bitcoin mining is unlikely to be threatened by quantum computing in the short or medium term, and upgrading requires widespread agreement.

  • ● Transaction weight limit with exception to prevent confiscation: Vojtěch Strnad posted to Delving Bitcoin to propose the idea for a consensus change to limit the maximum weight of most transactions in a block. The simple rule would only allow a transaction larger than 400,000 weight units (100,000 vbytes) in a block if it was the only transaction in that block besides the coinbase transaction. Strnad and others described the motivation for limiting the maximum transaction weight:

    • Easier block template optimization: it’s easier to find a near-optimal solution to the knapsack problem the smaller the items are compared to the overall limit. This is partly due to minimizing the amount of space left over at the end, with smaller items leaving less unused space.

    • Easier relay policy: the policy for relaying unconfirmed transactions between nodes predicts what transactions will be mined in order to avoid wasting bandwidth. Giant transactions make accurate predictions harder as even a small change in the top feerate can cause them to be delayed or evicted.

    • Avoiding mining centralization: ensuring relaying full nodes are able to handle almost all transactions prevents users of special transactions from needing to pay out-of-band fees, which can lead to mining centralization.

    Gregory Sanders noted it might be reasonable to simply soft fork a maximum weight limit without any exceptions based on Bitcoin Core’s 12 years of consistent relay policy. Gregory Maxwell added that transactions spending only UTXOs created before the soft fork could be allowed an exception to prevent confiscation, and that a transitory soft fork would allow the restriction to expire if the community decided not to renew it.

    Additional discussion examined the needs of parties wanting large transactions, mainly BitVM users in the near term, and whether alternative approaches were available to them.

  • ● Removing outputs from the UTXO set based on value and time: Robin Linus posted to Delving Bitcoin to propose a soft fork for removing low-value outputs from the UTXO set after some time. Several variations on the idea were discussed, with the two main alternatives being:

    • Destroy old uneconomic funds: small value outputs that had not been spent for a long time would become unspendable.

    • Require old uneconomic funds to be spent with a proof of existence: utreexo or a similar system could be used to allow a transaction to prove that the outputs it spends are part of the UTXO set. Old and uneconomical outputs would need to include this proof, but newer and higher-value outputs would still be stored in the UTXO set.

    Either solution would effectively limit the maximum size of the UTXO set (assuming a minimum value and the 21 million bitcoin limit). Several interesting technical aspects of a design were discussed, including alternatives to utreexo proofs for this application that could be more practical.

Releases and release candidates

New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates.

Notable code and documentation changes

Notable recent changes in Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, Lightning BLIPs, Bitcoin Inquisition, and BINANAs.

  • ● Bitcoin Core #32582 adds new logging to measure the performance of compact block reconstruction by tracking the total size of transactions that a node requests from its peers (getblocktxn), the number and total size of transactions that a node sends to its peers (blocktxn), and adding a timestamp at the start of PartiallyDownloadedBlock::InitData() to track how long the mempool lookup step alone takes (in both high and low-bandwidth modes). See Newsletter #315 for a previous statistics report on compact block reconstruction.

  • ● Bitcoin Core #31375 adds a new bitcoin -m CLI tool that wraps and executes the multiprocess binaries bitcoin node (bitcoind), bitcoin gui (bitcoinqt), bitcoin rpc (bitcoin-cli -named). Currently, these function in the same way as the monolithic binaries, except they support the -ipcbind option (see Newsletter #320), but future improvements will enable a node runner to start and stop components independently on different machines and environments. See Newsletter #353 for a Bitcoin Core PR Review Club covering this PR.

  • ● BIPs #1483 merges BIP77 which proposes payjoin v2, an asynchronous serverless variant in which the sender and receiver hand their encrypted PSBTs to a payjoin directory server that only stores and forwards messages. As the directory cannot read or alter the payloads, neither wallet needs to host a public server or be online at the same time. See Newsletter #264 for additional context on payjoin v2.

Want more?

For more discussion about the topics mentioned in this newsletter, join us for the weekly Bitcoin Optech Recap on Riverside.fm at 16:30 UTC on June 10. The discussion is also recorded and will be available from our podcasts page.