This week’s newsletter describes a protocol for transferring non-bitcoin tokens in Bitcoin transactions and LN payments and links to a proposed BIP for the MuSig2 multisignature protocol. Also included are our regular sections with the summary of a Bitcoin Core PR Review Club meeting, announcements of new software releases and release candidates, and descriptions of notable changes to popular Bitcoin infrastructure software.

News

  • ● Transferable token scheme: Olaoluwa Osuntokun posted to the Bitcoin-Dev and Lightning-Dev mailing lists a set of proposed BIPs for the Taro protocol that will allow users to record the creation and transfer of non-bitcoin tokens on Bitcoin’s block chain. For example, Alice can issue 100 tokens, transfer 50 to Bob, and Bob can further exchange 25 of the tokens for 10 BTC with Carol. The idea is similar to previous ideas implemented for Bitcoin but differs in its details, such as by reusing several design elements from taproot to reduce the amount of new code that needs to be written and by using merkle trees to reduce the amount of data that needs to be transferred to prove certain operations occurred.

    Taro is intended to be used with LN for routable offchain transfers. Similar to previous proposals for cross-asset transfers on LN, intermediate nodes that just route payments won’t need to be aware of the Taro protocol or the details of the assets being transferred—they’ll just transfer BTC using the same protocol as any other LN payment.

    The idea received a moderate amount of discussion on the mailing lists this week.

  • ● MuSig2 proposed BIP: Jonas Nick, Tim Ruffing, and Elliott Jin posted a proposed BIP to the Bitcoin-Dev mailing list for MuSig2, a multisignature protocol for creating public keys and signatures. Multiple private keys controlled by separate parties or software can use MuSig2 to derive an aggregate public key without any of the separate parties needing to share any private information with each other. Later, an aggregate signature may also be created, again without requiring the sharing of any private information. The aggregate public key and aggregate signature look to third parties like any other public key and schnorr signature, so it isn’t revealed how many parties or private keys were involved in creating the aggregated keys or signatures, improving privacy over onchain multisig where the number of separate keys and signatures is revealed.

    MuSig2 is superior in almost all imagined applications over the original MuSig proposal (now called MuSig1). MuSig2 is easier to implement than the alternative MuSig-DN (deterministic nonce), although there are tradeoffs between MuSig2 and MuSig-DN that some application developers may wish to consider when choosing which protocol to use.

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.

Prevent block index fingerprinting by sending additional getheaders messages is a PR by Niklas Gögge to prevent a node from being fingerprinted based on its block index.

  • What is the block index and what is it used for?

    The block index is an in-memory index for looking up block headers and the locations of block data on disk. It may keep multiple branches (i.e. including stale block headers) of the block ‘tree’ to accommodate reorgs. ➚

  • Should we keep stale blocks in the block index? Why or why not?

    When multiple branches exist, keeping them indexed allows the node to quickly switch branches if the most-work chain changes. Some participants noted that it may not be very useful to keep very old stale blocks, since the likelihood of a reorg is extremely low. However, these headers use very little storage space and, since nodes check the Proof of Work before storing them, sending valid-PoW stale headers in the hopes of exhausting nodes’ resources would be disproportionately expensive. ➚

  • Describe the attack using a node’s block index for fingerprinting.

    During IBD, a node only requests and downloads blocks belonging to the most-work chain it learned about during the initial headers sync. As such, the stale blocks in its block index were usually mined after IBD, but this may vary naturally or be manipulated by an attacker with a large collection of past stale headers. An attacker with a stale branch of headers H and H+1 can send H+1 to a node. If the node doesn’t have H+1’s predecessor, H, in its block index, it will request H using a getdata message. If it already has H, it won’t request it. ➚

  • Why is it important to prevent node fingerprinting?

    Node operators may employ various techniques to obfuscate their node’s IP address, e.g. by using Tor. However, the privacy benefits may be limited or negated if attackers can link the IPv4 and Tor addresses of a node running on both networks. If a node is running on Tor only, fingerprinting could be used to link multiple Tor addresses belonging to the same node, or identify the node if/when it switches to IPv4. ➚

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.106 is the latest release of this LN node library. It adds support for channel identifier alias field proposed in BOLTs #910 which LDK uses to enhance privacy in some cases and includes several other features and bug fixes.

  • ● BTCPay Server 1.4.9 is the latest release of this popular payment processing software.

  • ● Bitcoin Core 23.0 RC4 is a release candidate for the next major version of this predominant full node software. The draft release notes list multiple improvements that advanced users and system administrators are encouraged to test before the final release.

  • ● LND 0.14.3-beta.rc1 is a release candidate with several bug fixes for this popular LN node software.

  • ● Core Lightning 0.11.0rc1 is a release candidate for the next major version of this popular LN node software.

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.