This week’s newsletter describes two suggested improvements to LN static
backups and links to a proposal for a new version of PSBTs. Also
included are our regular sections with summaries of changes to services
and client software, popular questions and answers from the Bitcoin
StackExchange, new releases and release candidates, and notable changes
to popular Bitcoin infrastructure projects.
None this week.
● Proposed improvements to static LN backups: anyone receiving money
in a payment channel, including those currently used by LN, needs to
keep track of the channel’s latest state—all the details that make
it possible to close the channel and receive the correct share of the
channel’s funds onchain. Unfortunately, computers have a bad habit of
losing data and regular periodic backups don’t help much when a
channel’s state could have changed just milliseconds before a disk drive
LN has always provided some robustness against this type of problem: if your node is offline, your channel counterparty will eventually close the channel so that they can start spending their funds again. This will send your funds to the onchain part of your LN wallet, which you hopefully backed up using a normal BIP32 seed. This should be reasonably safe: LN’s regular penalty mechanism encourages your counterparty to close the channel in its latest state—if they use an old state, they could lose all their money from the channel.
The downside of the above approach is that you have to wait for your counterparty to decide that you’re not coming back. This wait can be eliminated if you back up some static information about your channel (e.g. the ID of your peer), reconnect to the peer after you lose data, and request that the peer immediately close the channel. This does seem to indicate that you’ve lost data and so your peer could close the channel in an old state—but, if they try that and you still have your old data, you can penalize them.
This week, Lloyd Fournier started two threads on the Lightning-Dev mailing list about possible improvements to the above mechanisms:
● Fast recovery without backups: the static per-channel backups
that allow fast recovery of funds require you to create a new backup
each time you open a new channel. If you fail to make a backup,
your only option is to wait until your channel counterparty
decides to close the channel on their own. Fournier instead
proposed a deterministic key derivation method that would allow a
node to search through the list of public LN nodes, combine
information about its private keys derived from its HD wallet with
information about each node’s main public key, and determine
whether or not it had a channel with that node. This backup strategy would only
work for channels opened with public nodes, which are expected
to be the most common type of channel for typical users.
● Covert request for mutual close: the existing mechanism for
closing a channel requires that your counterparty broadcast their
unilateral commitment transaction. It would be better to use a
mutual close transaction—this uses less space onchain, requires
paying less fees, is not identifiable onchain as having belonged
to an LN channel, and allows both parties to spend their funds
immediately. However, mutual close transactions don’t contain any
penalty mechanism, so if you request a channel be closed and your
counterparty gives you an inaccurate mutual close transaction,
there’s no way for you to penalize them. In the normal protocol,
this isn’t an issue—you’d just broadcast the latest state, but
if you’ve lost your state, then you have no remedy.
Fournier proposed a solution using a cryptographic primitive called oblivious transfer that allows your counterparty to send you the mutual close transaction encrypted in a way that allows you to either use it (closing the channel) or prove that you can’t decrypt it (allowing them to safely continue accepting payments in the channel). If you use this procedure every time you reconnect, you don’t reveal to them that you lost any data until after they’ve provided you all the information you need to recover.
● New PSBT version proposed: Andrew Chow, author of the BIP174
specification of Partially Signed Bitcoin Transactions
(PSBTs), proposed a new version of PSBTs that will contain
several backwards incompatible features, although it’ll be largely the
same as the current version 0 PSBT.
Changes to services and client software
In this monthly feature, we highlight interesting updates to Bitcoin
wallets and services.
● Bitcoin Wallet Tracker adds descriptor support:
Bitcoin Wallet Tracker’s 0.2.0 release adds support for tracking
output script descriptors and introduces libbwt,
a library for allowing Electrum-backed wallets to easily support a Bitcoin
Core full node.
● Bisq adds segwit for trade transactions:
Building on previous bech32 support for deposits and
withdrawals, Bisq v1.5.0 adds segwit support within trade
transactions as well as implementing fee optimizations.
● Ledger Live adds Bitcoin Core full node support:
Ledger Live, using the open source Ledger SatStack
application, can now connect to a Bitcoin full node for
sending transactions and providing balances in a more private way, without
using Ledger’s explorers.
Selected Q&A from Bitcoin StackExchange
Bitcoin StackExchange is one of the first places Optech
contributors look for answers to their questions—or when we have a
few spare moments to help curious or confused users. In
this monthly feature, we highlight some of the top-voted questions and
answers posted since our last update.
● What is the difference between “native segwit” and “bech32”?
Murch describes that bech32 is the method used for encoding native
segwit v0 witness programs; it’s equivalent to the base58check encoding
used for legacy Bitcoin addresses. The same bech32 encoding is also
used for other purposes, such as LN invoices. Bech32 was planned
to be used for later versions of segwit witness programs but
a length extension mutation was discovered
that necessitates using a modified bech32 address format, possibly
called “bech32m”, for Pay-to-Taproot (P2TR) segwit v1 witness programs.
● What makes cross input signature aggregation complicated to implement?
Michael Folkson references a Bitcoin dev mailing list post by AJ Towns
in explaining challenges to implementing cross input signature aggregation in Bitcoin.
● How do BIP8 and BIP9 differ, how are they alike?
Murch provides an overview of some different activation methods: early soft
fork activations using the block version, BIP9’s multiple-proposal-supporting
activation method, and BIP8’s block height and lock-in adjustments to BIP9.
Releases and release candidates
New releases and release candidates for popular Bitcoin infrastructure
projects. Please consider upgrading to new releases or helping to test
● Bitcoin Core 0.21.0rc3 is a release candidate
for the next major version of this full node implementation and its
associated wallet and other software. Note, the macOS version of the
signed binary will not run due to a problem with the
code signing tool. The unsigned version (which can
still be verified with PGP) should run if opened
using the right-click (or control-click) context menu. Developers are
working on fixing this problem for future release candidates and the
● LND 0.12.0-beta.rc1 is the first release candidate
for the next major version of this LN node. It makes anchor
outputs the default for commitment
transactions and adds support for them in its watchtower implementation, reducing costs and increasing safety, and
adds generic support for creating and signing PSBTs.
Also included are several bug fixes.
Bitcoin Core 0.20.2rc1 and 0.19.2rc1 are expected to be
available sometime after the publication of
this newsletter. They contain several bug fixes, such as an
improvement described in Newsletter #110 that will
prevent them from redownloading future taproot transactions that they
Notable code and documentation changes
● Protocol version: Bitcoin Core will only negotiate support for
addrv2messages with peers that signal
they are using P2P version 70016 or higher. This restriction isn’t required by BIP155,
but release testing has revealed that some other implementations will disconnect
from Bitcoin Core if they receive any unknown message, including
sendaddrv2. This change may be reverted in future versions of Bitcoin Core,
so other implementations are advised to tolerate unknown P2P messages at any time in the connection.
● Updated BIP: The
sendaddrv2message will now be sent between the
verackmessage, as required by the latest version of BIP155. See BIPs
#1043 below for more information about that change to the BIP.
● Bitcoin Core #19776 updates the
getpeerinfoRPC with two new
bip152_hb_toindicates that we asked the peer to relay new
blocks to us by sending a BIP152 compact block without waiting to
ask if we need that specific block, called High-Bandwidth (HB) mode.
bip152_hb_fromindicates that the peer asked us to be one of their
high-bandwidth peers. By default, each node selects up to 3 high-bandwidth compact block peers. (Despite the name,
high-bandwidth mode doesn’t use much bandwidth compared to legacy block
relay; its optimizations for fast relay of new blocks just uses more
bandwidth than BIP152’s low-bandwidth mode.)
● Bitcoin Core #19858 adds a new method for finding high-quality peers with
the goal of making eclipse attacks more difficult.
It opens an outbound connection every five minutes on average to a new peer
and syncs headers with it. If the peer tells the node about new blocks, the
node disconnects an existing block-relay-only peer and gives that connection
slot to the new peer; otherwise, the new peer is dropped. Provided the node
knows the IP address of at least one other honest node, this peer rotation should raise the cost of
sustaining a partitioning attack against it, as the node should always
eventually find the valid chain with the most work. The increased rotation and
security will slightly reduce the number of open
listening sockets on the network, but it is expected to help bridge the network
as a whole via more frequent connections, add edges to the network
graph, and provide more security against partitioning attacks in general.
● Bitcoin Core #18766 disables the ability to get fee estimates when
blocksonlyconfiguration option. This bandwidth-saving
option stops Bitcoin Core from requesting and relaying unconfirmed
transactions. However, Bitcoin Core’s fee estimates are also
dependent on tracking how long it takes transactions to become
confirmed. Previously, when
blocksonlywas enabled, Bitcoin Core
stopped updating its estimates but continued to return the
estimates it had already generated, producing increasingly out of date
estimates. After this change, it won’t return any estimates at all
blocksonlymode is enabled.
● C-Lightning #4255 is the first of a series of pull requests for an
initial version of offers—the ability to request and receive invoices
over the LN. A common use of this feature would be that a
merchant generates a QR code, the customer scans
the QR code, the customer’s LN node sends some of the details from the
QR code (such as an order ID number) to the merchant’s node over LN,
the merchant’s node returns an invoice (also over LN), the invoice is
displayed to the user (who agrees to pay), and the payment is sent.
Although this use case is already addressed today using BOLT11
invoices, the ability for the spending and receiving nodes to
communicate directly before attempting payment provides much more flexibility. It
also enables features that aren’t possible with BOLT11’s one-time-use
hashlocks, such as recurring payments for subscriptions and donations.
See the BOLT12 draft for more information.
● Eclair #1566 abstracts out all connection-handling logic into a front
node, which can be distributed across multiple hosts to achieve
high availability for production deployments. These front nodes also handle
CPU/bandwidth-intensive BOLT7 messages, such as routing table related
gossip and syncing requests, in a distributed manner, improving scalability
for larger node deployments like ACINQ’s. For readers looking to deploy this
change, an AWS Beanstalk bundle is available, and the author recommends using
the AWS Secrets Manager to store the node’s private key, a topic previously
covered in the SuredBits field report.
● BIPs #1043 changes the way that support for BIP155 is negotiated between
peers. Previously, the BIP specified that a node should send a
to signal support for BIP155 after receiving a
verackmessage from its peer.
The BIP now specifies that the node must send the
earlier in connection establishment, between sending its
messages. This is consistent with how BIP339 negotiates wtxid relay support
and also with a generic method for negotiating features
proposed to the mailing list earlier this year.
John Newbery posted a summary of all the changes to BIP155 since it was proposed in February 2019 to the Bitcoin-dev mailing list.
● BOLTs #803 updates BOLT5 with recommendations for preventing
a transaction pinning attack. The recent
anchor outputs update to the LN specification
allows multiple payments (HTLCs) that were pending at the time a
channel was unilaterally closed to all be settled in the same
transaction. A potential problem is that some of those outputs may
pay your channel counterparty, giving them the ability to pin the
transaction and prevent the other HTLCs in the batch from confirming
until after their timelocks expire. The recommendation is to allow
batching the HTLCs for maximum efficiency when there’s plenty of time
left but to split each HTLC into a separate transaction when the
timelock expiration is approaching so that pinning isn’t a problem.
Newsletter #87 incorrectly claimed that “previous versions of Bitcoin
Core would terminate a new connection if certain messages didn’t appear
in a particular order”. We were alluding to a belief that the
message needed to be immediately followed by the
introduced in Bitcoin 0.2.9 (May 2010). Subsequent code review and
testing of old versions of Bitcoin Core by Optech contributors did not
substantiate this statement and we’ve added a correction to the original
text. We apologize for the error.
Holiday publication schedule
Happy holidays! This issue is our final regular newsletter for the
year. Next week we’ll publish our annual special year-in-review issue.
We’ll return to regular publication on Wednesday, January 6th.