The last Bitcoin Optech Newsletter describes a proposal to remove details from the LN specification that are no longer relevant to modern nodes and includes the penultimate entry in their limited weekly series about mempool policy, plus the regular sections summarizing a Bitcoin Core PR Review Club meeting, announcing new releases and release candidates, and describing notable changes to popular Bitcoin infrastructure software.

YOU CAN LISTEN THE ORIGINAL PODCAST HERE

News

• ● LN specification clean up proposed: Rusty Russell posted to the Lightning-Dev mailing list a link to a PR where he proposes to remove some features that are no longer supported by modern LN implementations and to assume other features will always be supported. Related to the proposed changes, Russell also provides the results of a survey he ran of public node features according to their gossip messages. His results imply that nearly all nodes support the following features:

  • ● Variable-sized onion messages: made part of the specification in 2019 (see Newsletter #58) around the same time as the specification was updated to use Type-Length-Value (TLV) fields. This replaced the original format for encrypted onion routing that required each hop to use a fixed-length message and limited the number of hops to 20. The variable-sized format makes it much easier to relay arbitrary data to specific hops, with the only downside being that the overall message size remains constant, so any increase in the amount of data sent decreases the maximum number of hops.

  • ● Gossip queries: made part of the specification in 2018 (see BOLTs #392). This allows a node to request from its peers only a subset of gossip messages sent by other nodes on the network. For example, a node may request only recent gossip updates, ignoring older updates to save bandwidth and reduce processing time.

  • ● Data loss protection: made part of the specification in 2017 (see BOLTs #240). Nodes using this feature send information about their latest channel state when they reconnect. This may allow a node to detect that it has lost data, and it encourages a node that has not lost data to close the channel in its latest state. See Newsletter #31 for additional details.

  • ● Static remote-party keys: made part of the specification in 2019 (see Newsletter #67), this allows a node to request that every channel update commit to sending the node’s non-HTLC funds to the same address. Previously, a different address was used in every channel update. After this change, a node that opted into this protocol and lost data would almost always eventually receive at least some of their funds to their chosen address, such as an address in their HD wallet.

  This is a short extract, remember that you can visit the original source or listen the complete podcast on the links below.