This week’s newsletter summarizes several related discussions about providing a sustainable long term block reward for Bitcoin. Also included are our regular sections with descriptions of new features for clients and services, announcements of new releases and release candidates, and summaries of notable changes to popular Bitcoin infrastructure software.

News

  • ● Long-term block reward ongoing discussion: continuing the discussion about reliably paying for Proof of Work (PoW) as Bitcoin’s subsidy declines, two new threads were started on the Bitcoin-Dev mailing list:

    • ● Tail emission is not inflationary starts with an argument by Peter Todd that perpetually paying miners with newly created bitcoins will not lead to the number of bitcoins in circulation increasing forever. Instead, he believes some bitcoins will be lost every year and, eventually, the rate at which bitcoins are lost will converge on the rate at which new bitcoins are produced, resulting in a roughly stable number of coins in circulation. He also notes that adding a perpetual block subsidy to Bitcoin would be a hard fork. Quite a few people replied to his post and on a thread about it on BitcoinTalk; we will only attempt to summarize a few replies we found most notable.

      • ● Hard fork not required: Vjudeu suggests that a soft fork can create new bitcoins by imbuing transaction outputs paying zero satoshis with special meaning. For example, when a node opting into the fork sees a zero-sat output, it looks at another part of the transaction for the actual value transferred. This creates two classes of bitcoins, but presumably the soft fork would provide a mechanism to convert legacy-bitcoins to modified-bitcoins. Vjudeu notes the same mechanism could also be used for privacy-enhancing bitcoin amount blinding (e.g. using confidential transactions).

      • ● No reason to believe perpetual issuance is sufficient: Anthony Towns posts to the mailing list and Gregory Maxwell posts to BitcoinTalk that there’s no reason to believe that paying miners an amount of coins equal to the average rate of lost coins will provide sufficient PoW security, and that there are cases where it could overpay for PoW security. If a perpetual issuance can’t guarantee security and if it has a significant likelihood of producing additional problems, it seems preferable to stick with a finite subsidy that—while it also can’t guarantee security—at least it doesn’t produce additional problems and is already accepted by all Bitcoiners (implicitly or explicitly).

        Maxwell further notes that Bitcoin miners on average collect significantly more value through just transaction fees than many altcoins pay their miners through the combination of subsidies, fees, and other incentives. Those altcoins are not suffering fundamental PoW attacks, implying that it might be the case that enough value is being paid through transaction fees alone to keep Bitcoin secure. In short, Bitcoin may already be past the point where it needs its subsidy to obtain sufficient PoW security. (Though the subsidy also provides other benefits at present, as discussed in the summary below for Bram Cohen’s thread.)

        Towns points out that Peter Todd’s results depend on a constant average rate of bitcoins being lost each year, but this conflicts with what Towns thinks should be a system-wide goal to minimize lost bitcoins. Relatedly, Maxwell describes how coin loss could be almost entirely eliminated by allowing anyone to automatically opt-in to using a script that would donate any of their coins which hadn’t moved for, say, 120 years—well past the expected lifetime of the original owner and their heirs.

      • ● Censorship resistance: developer ZmnSCPxj expanded an argument by Eric Voskuil that transaction fees enhance Bitcoin’s censorship resistance. For example, if 90% of the block reward comes from subsidy and 10% from transaction fees, then the most revenue a censoring miner can lose directly is 10%. But if 90% comes from fees and 10% from subsidy, the miner could directly lose up to 90%—a much stronger incentive to avoid censorship.

        Peter Todd countered with the opinion that a perpetual issuance would raise more money for PoW security than “piddling transaction fees”, and that a higher block reward would increase the cost an attacker would have to pay miners to censor transactions.

    • ● Fee sniping: Bram Cohen posted about the problem of fee sniping and suggests keeping transaction fees at about 10% of total block rewards (the remainder being subsidy) as a possible solution. He briefly mentions some other possible solutions, but others provided additional suggestions in more detail.

      • ● Paying fees forward: Russell O’Connor put forward an old idea that miners could calculate the maximum amount of fees they could collect from the top transactions in their mempool without incentivizing fee sniping. They could then offer any additional fees they collected as a bribe to the next miner for building the next block cooperatively rather than competitively. Discussion participants went through several iterations of this idea but Peter Todd noted that a fundamental concern with this technique is that smaller miners would need to pay higher bribes than larger miners, creating economies of scale that could further centralize Bitcoin mining.

      • ● Improving market design: Anthony Towns suggests that improvements in Bitcoin software and user processes could significantly even out fees, making fee sniping less likely. But he further notes that it doesn’t seem like a major priority today just for “refuting some FUD”.

Changes to services and client software

In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.

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.

  • ● BDK 0.20.0 is the newest release of this library for building Bitcoin wallets. It includes “bug fixes for the ElectrumBlockchain and descriptor templates, a new transaction building feature to discourage fee sniping, and new transaction signing options.”

Notable code and documentation changes

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

  • ● Bitcoin Core #24148 adds watch-only support for output script descriptors written in miniscript. For example, a user can import wsh(and_v(v:pk(key_A),pk(key_B))) to begin watching for any bitcoins received to the P2WSH output corresponding to that script. A future PR is expected to add support for signing for miniscript-based descriptors.

  • ● Bitcoin Core GUI #471 updates the GUI with the ability to restore from a wallet backup. Restoring was previously only possible either using the CLI or by copying files into particular directories.

  • ● LND #6722 adds support for signing arbitrary messages with BIP340-compatible schnorr signatures. Messages with schnorr signatures may also now be verified.

  • ● Rust Bitcoin #1084 adds a method which can be used for sorting a list of public keys in the order specified by BIP383.