This week’s newsletter summarizes discussions about half aggregation of schnorr signatures, a workaround for protocols that can’t reliably use x-only pubkeys, and allowing deliberately slow LN payment forwarding. Also included are our regular sections with the summary of a Bitcoin Core PR Review Club, announcements of releases and relase candidates, and descriptions of notable changes to popular Bitcoin infrastructure projects.

News

  • ● Half aggregation of BIP340 signatures: Jonas Nick posted to the Bitcoin-Dev mailing list a draft BIP and blog post about half aggregation of Bitcoin’s schnorr signatures. As mentioned in the blog post, the proposal “allows aggregating multiple schnorr signatures into a single signature that is about half as long as the sum of the individual signatures. Importantly, this scheme is non-interactive, which means that a set of signatures can be half-aggregated by a third party without any involvement from the signers.”

    A separate document provides examples of how half aggregation could benefit the operators of Bitcoin and LN nodes, plus several concerns that would need to be considered in the design of a soft fork adding half aggregation to the consensus protocol.

  • ● X-only workaround: Bitcoin public keys are points on a two-dimensional graph which are referenced by the intersection of an x coordinate and a y coordinate. For any given x coordinate, there are only two valid y coordinates and these can be calculated from the x value. This allowed an optimization in the design of taproot to require all public keys used with BIP340-style schnorr signatures to only use a certain one of these y coordinates, allowing any public keys included in transactions to omit including the y point entirely, saving one vbyte per signature over the original taproot design.

    At the time, this technique (called x-only public keys) was thought to be an optimization with no significant tradeoffs, but later design work on OP_TAPLEAF_UPDATE_VERIFY (TLUV) revealed that x-only pubkeys required either computationally limiting the proposal or storing extra data in the block chain or UTXO set. The problem may affect other advanced uses of pubkeys as well.

    This week, Tim Ruffing posted to the Bitcoin-Dev mailing list a potential workaround that only requires a slight bit of additional computation by signers—an amount that even a resource-constrained hardware signing device can probably perform without making its user wait too long.

  • ● Allowing deliberately slow LN payment forwarding: in a reply to a thread about recursive/nested MuSig2 (see Newsletter #204) and the latency that nodes using it would add when routing payments, developer Peter Todd asked on the Lightning-Dev mailing list whether it would “be worthwhile to allow people to opt-in to their payments happening more slowly for privacy?” For example, if Alice and Bob each sent forward-slowly payments around the same time through Carol’s forwarding node to Dan’s forwarding node, Carol would be able to forward both payments together, reducing the amount of privacy-leaking information about the participants that third parties could discover through balance probing, network activity surveillance, or other techniques. Developer Matt Corallo agreed it was an interesting idea.

Bitcoin Core PR Review Club

In this monthly section, we summarize a recent Bitcoin Core PR Review Club meeting, highlighting some of the important questions and answers. Click on a question below to see a summary of the answer from the meeting.

Manual block-relay-only connections with addnode is a PR by Martin Zumsande to allow users to manually create connections with nodes on which only blocks (not transactions or peer addresses) are relayed. This option is intended to help prevent eclipse attacks, particularly for nodes running on privacy networks such as Tor.

  • Why could peers that are only active on privacy networks such as Tor be more susceptible to eclipse attacks compared to clearnet-only peers?

    Nodes on clearnet can use information such as network groups of IP addresses to try to select ‘diverse’ peers. On the other hand, it’s difficult to tell whether a set of onion addresses all belong to a single attacker, so it’s harder to do so on Tor. Also, while the set of Bitcoin nodes running on Tor is quite large, a node using -onlynet on a privacy network with few Bitcoin nodes could be easily eclipsed, since there aren’t many options for peers. ➚

  • What is the difference between the onetry and add modes in the addnode RPC?

    As the name suggests, onetry only tries to call CConnman::OpenNetworkConnection() once. If it fails, the peer is not added. On the other hand, addnode mode causes the node to repeatedly try to connect to the node until it succeeds. ➚

  • The PR introduces a new connection type MANUAL_BLOCK_RELAY that combines the properties of MANUAL and BLOCK_RELAY peers. What are the advantages and disadvantages of having an extra connection type, as opposed to combining the logic of the existing ones?

    As there are many attributes of p2p connections but few types, participants agreed that using flat, enumerated connection types is simpler. They also noted that describing connections using combinations of capabilities and permissions could lead to a combinatorial blowup of connection types and convoluted logic, including some which might not make sense. ➚

  • What types of attacks that this PR tries to mitigate are fixed by BIP324? Which ones aren’t?

    BIP324 enhances privacy by adding opportunistic encryption to prevent eavesdropping and network-wide surveillance, but isn’t intended to prevent eclipse attacks. Even with some mechanism of authentication, it does not help identify whether the peer is honest or a distinct entity from other peers. ➚

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.

  • ● BTCPay Server 1.6.1 is a release of the 1.6 branch of this popular self-hosted payment processor solution which includes multiple new features and bug fixes.

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 #25353 introduces the mempoolfullrbf configuration option previously described in Newsletter #205. This option enables node operators to switch their node’s transaction replacement behavior from the default opt-in RBF (BIP125) to full RBF—permitting transaction replacement in the node’s mempool without enforcing the signaling requirement, but following the same economic rules as opt-in RBF.

  • ● Bitcoin Core #25454 avoids multiple getheaders messages in flight to the same peer, which reduces bandwidth useage by waiting up to two minutes for a response to a prior getheaders message before issuing a new one.

  • ● Core Lightning #5239 improves the gossip handling code by updating CLN’s internal map of the payment relay network using all received announcements but continuing to only relay the announcements that satisfy CLN’s gossip rate limits. Previously, CLN dropped incoming messages according to its rate limits. The change can give CLN nodes a better view of the network when their peers have looser (or no) rate limits without affecting how much data CLN sends to its peers.

  • ● Core Lightning #5275 adds support for zero-conf channel opens and the related Short Channel IDentifier (SCID) aliases (see Newsletter #203). This includes updates to the listpeers, fundchannel, and multifundchannel RPCs.

  • ● LND #5955, like the merge listed above, also adds support for zero-conf channel opens and the related SCID aliases.

  • ● LDK #1567 adds support for a basic payment probing API that can be used by an application to test which payment routes will be more likely to succeed if a payment is sent through them in the near future. It includes support for constructing the HTLCs in a way that allows the sending node to separate them from actual payment HTLCs when they come back without storing any extra state.

  • ● LDK #1589 adds a security policy that can be used for safely reporting security vulnerabilities to the LDK maintainers.

  • ● BTCPay Server #3922 adds the basic UI for custodian accounts—accounts tied into a BTCPay instance where the funds are managed by a custodian, such as a Bitcoin exchange (rather than by the local user controlling their own private keys). BTCPay instances may have both local wallets and custodian accounts, which can make it easy to manage funds between them, e.g. allowing a merchant to receive funds privately and securely to their wallet but also quickly transfer amounts to an exchange to be sold.

  • ● BDK #634 adds a get_block_hash method that returns a header hash for a block on the best block chain at a particular height.

  • ● BDK #614 avoids creating transactions that spend from immature coinbase outputs—outputs to a miner’s coinbase transaction which have less than 100 confirmations (blocks built on top of that block).