This week’s newsletter summarizes discussions about long-term block reward funding, alternatives to BIP47 reusable payment codes, options for announcing LN channel splices, LN routing fee collection strategies, and onion message rate limiting. Also included are our regular sections with announcements of new software releases and release candidates, plus summaries of notable changes to popular Bitcoin infrastructure software.

News

  • ● Long-term block reward funding: in a thread on the Bitcoin-Dev mailing list ostensibly about covenants, it was noted that Bitcoin’s long term security currently depends on demand for block space. That demand must generate transaction fees to pay for Proof of Work (PoW) in excess of what an attacker would be willing to purchase to disrupt Bitcoin users. Developer Peter Todd pointed out that this dependency could be removed if the Bitcoin protocol were modified to include a perpetual subsidy. Several respondents indicated that they thought the system is better off without a perpetual subsidy, while others looked for alternatives or apparent equivalencies such as demurrage.

    As of this writing, the thread appears to consist of casual conversation rather than advocacy for any particular proposal to change Bitcoin in the near future.

  • ● Updated alternative to BIP47 reusable payment codes: developer Alfred Hodler posted to the Bitcoin-Dev mailing list a proposal for an alternative to BIP47 that attempts to address some of the issues found during its use in production. BIP47 allows Alice to publish a payment code that anyone can use in combination with their own keys to create an unlimited number of private addresses for Alice that only they and Alice will know belong to her, avoiding the worst problems of address reuse.

    However, one of the problems with BIP47 is that the first transaction from spender Bob to receiver Alice is a notification transaction that uses a special address associated with the payment code. This definitely leaks to third parties who know Alice’s payment code that someone is planning to start paying her. If Bob’s wallet isn’t carefully designed to segregate funds used for notification transactions, the transaction may also leak that Bob is planning to pay Alice—reducing or possibly even eliminating the benefits of BIP47.

    Hodler’s scheme would be less likely to leak this information but it would increase the amount of data a client implementing the protocol would need to learn from the block chain, making it less suitable for light clients. Ruben Somsen indicated several alternatives that could also be investigated, including Somsen’s silent payments idea (see Newsletter #194), Robin Linus’s 2022 stealth addresses idea, and previous discussion posted to the mailing list about improving upon BIP47.

  • ● Announcing splices: in a PR and a discussion on the Lightning-Dev mailing list, developers discussed the best way to communicate that a channel that was seemingly being closed onchain was in fact a splice where funds were being added to the channel or removed from it.

    One proposal was for nodes to simply not consider a channel closed until some amount of time after its onchain closing transaction was seen. This would give time for the announcement of the new (post-splice) channel to propagate. In the interim, nodes would still attempt to route payments through the seemingly-closed channel, as a spliced channel would still be able to forward payments with full LN security even before its new channel open transaction received a suitable number of confirmations.

    Another proposal was to include a signal onchain as part of the closing transaction that a splice was in progress, telling nodes that they could continue trying to forward payments through it.

    The discussion had not come to a clear conclusion at the time this summary was being written.

  • ● Fundamental fee-collection strategies for LN forwarding nodes: developer ZmnSCPxj summarized three strategies LN forwarding nodes can use in collecting fees for routing payments (including the strategy of not collecting fees). ZmnSCPxj then analyzes possible outcomes of the different strategies. This seems related to his proposal for nodes to use routing fees to improve payment success rates, see Newsletter #204, which also received significant additional commentary in the past week from Anthony Towns.

  • ● Onion message rate limiting: Bastien Teinturier posted a summary of an idea he attributes to Rusty Russell for rate limiting onion messages. The proposal has each node store just an extra 32 bytes of information for each of their peers that allows them to Probabilistically punish peers who send too much traffic. The suggested penalty is to just halve the rate limit for a peer relaying too much traffic for about 30 seconds. It’s acceptable if this lightweight penalty is occasionally enforced against the wrong peer, as may happen with this idea. The proposal also allows the originator of a message to learn which downstream nodes are rate limiting their messages (again probabilistically), giving them a chance to resend the message by a different route.

    Olaoluwa Osuntokun suggested reconsideration of his previous proposal for preventing abuse of onion messages by charging for data relay, see Newsletter #190. Replies from other developers as of this writing seemed to indicate they first try the lightweight rate limiting to see if it works before adding the complexity of payments for onion messages.

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.

  • ● LDK 0.0.109 is a new release of this LN node library, which includes both of the new features described for LDK in the notable changes section below.

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 #24836 adds a regtest-only RPC, submitpackage, to help L2 protocol and application developers who intend to use package relay in the future test their transactions against the Bitcoin Core default package policy. The current policy is outlined here. This RPC can also be used to test future additions and changes, such as the proposed package RBF rules.

  • ● Bitcoin Core #22558 adds support for BIP371’s additional PSBT fields (see Newsletter #155) for taproot.

  • ● Core Lightning #5281 adds support for specifying the log-file configuration option multiple times to write to multiple log files.

  • ● LDK #1555 updates its pathfinding code to slightly prefer routing through channels which advertise that they won’t accept payments larger than half the amount of money committed to the channel. This is believed to provide a slight privacy improvement by limiting the amount of balance information a third party can discover by probing a channel (sending a payment (HTLC) they don’t intend to settle). If a set of payments up to the total amount of a channel can be sent, then a prober can learn nearly the exact balance of the channel by just trying different sets of payments until all parts are accepted. However, if the set of payments which can be sent is limited to half the channel balance, it’s harder for the prober to determine whether payments are being rejected because of a lack of funds on one side of the channel or because of the self-imposed limit (the max_htlc_in_flight_msat limit). The BOLT2 max_htlc_in_flight_msat limit isn’t gossiped, so LDK instead uses each channel’s gossiped BOLT7 htlc_maximum_msat value as a proxy value.

  • ● LDK #1550 provides the ability for users to add a list of nodes to a local banlist which will prevent pathfinding from routing payments through those nodes.

  • ● LND #6592 adds a new requiredreserve RPC to the wallet subserver that prints the number of satoshis the wallet is reserving in UTXOs it unilaterally controls to fee bump anchor outputs if necessary. An additional --additionalChannels RPC parameter, which takes an integer argument, reports the number of satoshis the wallet will reserve if that number of additional channels are opened.

  • ● Rust Bitcoin #1024 adds additional code for helping developers work around the SIGHASH_SINGLE “bug” where the Bitcoin protocol expects a value of 1 to be signed when the input containing the SIGHASH_SINGLE signature has an index number higher than the index number of any output in the transaction.

  • ● BTCPay Server #3709 adds support for pull payments to be received via a LNURL withdraw.

  • ● BDK #611 begins setting the nLockTime of new transactions to the height of the most recent block by default, enabling anti fee sniping.