This week’s newsletter links to draft specifications related to taproot assets and describes a summary of several alternative message protocols for LN that can help enable the use of PTLCs. 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

  • ● Specifications for taproot assets: Olaoluwa Osuntokun posted separately to the Bitcoin-Dev and Lightning-Dev mailing lists about the Taproot Assets client-side validation protocol. To the Bitcoin-Dev mailing list, he announced seven draft BIPs—one more than in the initial announcement of the protocol, then under the name Taro (see Newsletter #195). To the Lightning-Dev mailing list, he announced a draft BLIP for spending and receiving taproot assets using LN, with the protocol based on the experimental “simple taproot channels” feature planned to be released in LND 0.17.0-beta.

    Note that, despite its name, Taproot Assets is not part of the Bitcoin Protocol and does not change the consensus protocol in any way. It uses existing capabilities to provide new features for users that opt-in to its client protocol.

    None of the specifications had received any discussion on the mailing list as of this writing.

  • ● LN messaging changes for PTLCs: as the first LN implementation with experimental support for channels using P2TR and MuSig2 is expected to be released soon, Greg Sanders posted to the Lightning-Dev mailing list a summary of several different previously-discussed changes to LN messages to allow them to support sending payments with PTLCs instead of HTLCs. For most approaches, the changes to messages do not seem large or invasive, but we note that most implementations will probably continue using one set of messages for handling legacy HTLC forwarding while also offering upgraded messages to support PTLC forwarding, creating two different paths that will need to be maintained concurrently until HTLCs are phased out. If some implementations add experimental PTLCs support before the messages are standardized, then implementations might even be required to support three or more different protocols simultaneously, to the disadvantage of all.

    Sander’s summary has not received any comments as of this writing.

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.

Transport abstraction is a recently-merged PR by Pieter Wuille (sipa) that introduces a transport abstraction (interface class). Concrete derivations of this class convert a (per-peer) connection’s (already serialized) send and receive messages to and from wire format. This can be thought of as implementing a deeper level of serialization and deserialization. These classes do not do the actual sending and receiving.

The PR derives two concrete classes from the Transport class, V1Transport (what we have today) and V2Transport (encrypted on the wire). This PR is part of the BIP324 Version 2 P2P Encrypted Transport Protocol project.

  • What is the distinction between net and net_processing?

    Net is at the bottom of the networking stack and handles low-level communication between peers, while net_processing builds on top of the net layer and handles the processing and validation of messages from net layer. ➚

  • More concretely, name examples of classes or functions that we’d associate with net_processing, and, in contrast, with net?

    net_processing: PeerManager, ProcessMessage. net: CNode, ReceiveMsgBytes, CConnMan. ➚

  • Does BIP324 require changes to the net layer, the net_processing layer, or both? Does it affect policy or consensus?

    These changes are only at the net layer; they don’t affect consensus. ➚

  • What are examples of implementation bugs that could result in this PR being an (accidental) consensus change?

    A bug that restricts the maximum message size to less than 4MB, which may cause the node to reject a block that other nodes consider valid; a bug in block deserialization that causes the node to reject a consensus-valid block. ➚

  • CNetMsgMaker and Transport both “serialize” messages. What is the difference in what they do?

    CNetMsgMaker performs the serialization of data structures into bytes; Transport receives these bytes, adds (serializes) the header, and actually sends it. ➚

  • In the process of turning an application object like a CTransactionRef (transaction) into bytes / network packets, what happens? Which data structures does it turn into in the process?

    msgMaker.Make() serializes the CTransactionRef message by calling SerializeTransaction(), then PushMessage() puts the serialized message into the vSendMsg queue, then SocketSendData() adds a header/checksum (after the changes from this PR) and asks the transport for the next packet to send, and finally calls m_sock->Send(). ➚

  • How many bytes are sent over the wire for the sendtxrcnclmessage (taking that message, used in Erlay, as a simple example)?

    36 bytes: 24 for the header (magic 4 bytes, command 12 bytes, message size 4 bytes, checksum 4 bytes), then 12 bytes for the payload (version 4 bytes, salt 8 bytes). ➚

  • After PushMessage() returns, have we sent the bytes corresponding to this message to the peer already (yes/no/maybe)? Why?

    All are possible. Yes: we (net_processing) don’t have to do anything else to cause the message to be sent. No: it’s extremely unlikely to have been received by the recipient by the time that function returns. Maybe: if all the queues are empty it will have made it to the kernel socket layer, but if some of the queues aren’t, then it will still be waiting on those to drain further before getting to the OS. ➚

  • Which threads access CNode::vSendMsg?

    ThreadMessageHandler if the message is sent synchronously (“optimistically”); ThreadSocketHandler if it gets queued and picked up and sent later. ➚

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.

  • ● LND v0.17.0-beta.rc2 is a release candidate for the next major version of this popular LN node implementation. A major new experimental feature planned for this release, which could likely benefit from testing, is support for “simple taproot channels”.

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), Lightning BOLTs, and Bitcoin Inquisition.

  • ● Bitcoin Core #26567 updates the wallet to estimate the weight of a signed input from the descriptor instead of doing a signing dry-run. This approach will succeed even for more complex miniscript descriptors, where the dry-run approach was insufficient.