This week’s newsletter describes a proposed change to the way LN commitment
transactions are constructed, summarizes discussion of a default signet, and
links to a proposal for standardizing temporarily trusted LN channels. Also
included are our regular sections with recently transcribed talks and
conversations, releases and release candidates, and notable changes to popular
Bitcoin infrastructure projects.
None this week.
● Witness asymmetric payment channels: Lloyd Fournier posted to
the Lightning-Dev mailing list this week with a request for feedback
on a proposed change to the way LN commitment transactions are
created. Currently, in-channel payments are made by constructing two
transactions that conflict with each other, meaning Bitcoin’s
consensus rules will only allow one of the transactions to be included
in the block chain. Each of these transactions includes the same two
outputs with the same two amounts—one paying Alice and one paying
Bob—but with slightly different scripts.
The script for Alice allows her to unilaterally close the channel, but
it gives Bob a chance to spend her funds if he knows a revocation key that
Alice previously created. Similarly, if Bob unilaterally closes the
channel, Alice gets a chance to spend his funds using a revocation key he
created. Giving your counterparty a private key that allows them to spend
your money makes it possible to effectively revoke that old channel
state so that you’re strongly incentivized to publish the latest
unrevoked channel state onchain when it comes time to close the
What Fournier proposed this week was only creating a single commitment
transaction that would be shared between
Alice and Bob. When creating the transaction, Alice creates two
private keys she’ll need to spend her output and gives Bob the
corresponding public keys. Bob then gives Alice a signature
adaptor for his half of the 2-of-2 multisig spend in the commitment
transaction; the adaptor can only be transformed into Bob’s signature
if that signature will reveal one of Alice’s private keys to Bob. The
other private key Alice created is the revocation private key, which
she’ll give to Bob if she wants to revoke this channel state in favor
of a later state. Similarly, Bob generates his own keys and receives
a signature adaptor from Alice.
In this way, even though the commitment transaction is the same for
both parties, there will be a difference in the signatures (called
witnesses) each of them uses to unilaterally close the channel.
The difference in the signatures will give the party who didn’t close
the channel a chance to create and broadcast a penalty transaction if
the channel was closed in an old state. Otherwise, if the channel was
closed in its latest state, both parties get their money, just like in
the current LN.
The proposal also suggests using basically the same scheme to
transition from Hash Time Lock Contracts (HTLCs) to Point Time Lock
Contracts (PTLCs), which is a goal several LN contributors
have voiced support for in the past.
Advantages of this approach are that it might require less private
data storage (though this is debated), it makes unilateral closes
a bit smaller onchain, and it describes a path to using PTLCs that
will provide LN users with additional privacy against routing
node surveillance as well as bring the protocol a little closer to what it may
look like when it can take advantage of the benefits of schnorr
● Default signet discussion: Michael Folkson posted to the
Bitcoin-Dev mailing list a question about whether there should be a
default signet similar to Bitcoin’s existing default testnet.
Signets are test networks where valid blocks must be
signed by one or more trusted keys; this allows them to be more
predictable for testing than fully decentralized test networks that
are often subject to vandalism. BIP325 describes the signet
protocol, which anyone can use to create their own signet, but there
is a desire to include a default signet into
Bitcoin Core (and possibly other software) that
users will be able to enable with a single configuration option.
Folkson’s first question was whether anyone has any objection to this.
If there is to be a default signet, Folkson posted several additional questions about how it should be administered. For example, who should control its signing keys? How many keys should there be? Under what circumstances should the default signet be reset? When should proposed consensus changes to mainnet Bitcoin be implemented by the trusted signet block signers?
Anyone interested in helping answer these questions is encouraged to respond.
● Standardizing temporarily trusted LN channels: Roei Erez
posted to the Lightning-Dev mailing list a proposal to standardize
the way LN implementations deal with new channels when the
participants are willing to trust an unconfirmed deposit transaction.
For example, Alice pays Bob’s established business to fund a
channel to her. In that case, Alice may be willing to trust Bob to not
double spend his deposit transaction. Bob can also safely accept
in-channel payments from Alice because he gets all his money back
anyway if the deposit transaction doesn’t confirm.
Erez noted that several LN implementations already allow users to opt in to trusting certain unconfirmed channels but that the different implementations vary in some aspects, such as what
short_channel_idto use until the deposit transaction confirms (this value usually identifies the location of the deposit transaction in the block chain, which doesn’t apply to unconfirmed transactions).
Participants in the mailing list discussion seemed supportive of the proposal.
Releases and release candidates
New releases and release candidates for popular Bitcoin infrastructure
projects. Please consider upgrading to new releases or helping to test
- ● btcd 0.21.0-beta is now released. This is the first major release for
btcd since 0.20.0-beta in October 2019, and contains numerous improvements
and bug fixes.
Recently transcribed talks and conversations
Bitcoin Transcripts is the home for transcripts of technical
Bitcoin presentations and discussions. In this monthly feature, we
highlight a selection of the transcripts from the previous month.
● nix-bitcoin: nixbitcoindev appeared on the Stephan Livera Podcast to
discuss nix-bitcoin. nix-bitcoin is an experimental project
that aims to improve the security of installing Bitcoin and Lightning nodes. It
uses the NixOS functional Linux distribution, where upgrading is equivalent to
installing from scratch due to atomicity. Through minimalism, reproducibility,
and compartmentalization, nix-bitcoin aims to reduce the attack
surface of a Bitcoin and Lightning software stack—ensuring programs are unaware of
other running processes unless they need to be. (transcript, audio)
● Taproot activation: Eric Lombrozo, Luke Dashjr, and Aaron van Wirdum
discussed the various taproot activation proposals (see
Newsletter #107) and gave their opinions
on what lessons, if any, could be derived from activating the
segwit soft fork. Lombrozo and Dashjr both believe that the taproot activation
process should not be drawn out and that all opposition, criticism, or review of
the proposed code changes should be completed prior to starting an
activation process. As a result, they support a single-phase BIP8 activation
method with parameters still to be determined. Community feedback on activation
proposals continues to be collected. (transcript,
● Signet: Kalle Alm and AJ Towns participated in a discussion on
signet. The design decisions of signet were explored as well
as the mechanics of how testnet and regtest work. For more details, see the
Default signet discussion news item.
● Bitcoin Core GUI meeting: Anonymized participants, including designers and
developers, met to discuss the Bitcoin Core graphical user interface, its
current state, how it could be improved, and the constraints that
a revamp would be subject to. For example, one change that has been
discussed in the past is moving from Qt Widgets to the Qt QML framework, which
is more flexible and easily customized. (transcript).
● Sydney meetup discussion: Ruben Somsen and Rusty Russell participated in a
discussion on statechains, upgrading LN channels, and lnprototest. Somsen
outlined how statechains (see Newsletter #91) could
potentially be used to swap out your Lightning channel counterparty or, in the
case of DLCs (see Newsletter #81), swap out a portion of your
position without closing the channel. With various proposed Lightning channel
upgrades on the horizon, participants speculated about which upgrades could use dynamic commitments
(see Newsletter #108) and which would require
splicing. Finally, Russell explained how the Lightning
protocol test suite lnprototest could be used to find bugs in existing
implementations and assist with ensuring interoperability across
implementations when building out new features. (transcript).
Notable code and documentation changes
● Bitcoin Core #19797 strays from Satoshi’s original vision™ by
removing an obsolete validity check for IPv6 addresses constructed by
Bitcoin (Core) 0.2.8 and earlier. Those early nodes had a bug that
would produce malformed addresses.
This change should have no impact on the current P2P network, as
affected versions are unable to communicate with current software due
to the introduction of checksums for P2P messages in Bitcoin
(Core) 0.2.9, which were later made mandatory.
● Bitcoin Core #19731 extends the
getpeerinfoRPC output with two new
last_blockis the time that
the peer sent the local node a block which the node had not seen
before and which passed preliminary validity checks.
last time that the peer sent the local node a transaction that the node
accepted to its mempool. Both of these metrics are used when choosing peers
to disconnect, so it’s useful for node operators to be able to access
● LND #4527 adds a new
option that allows the user to specify the default maximum number of
unresolved HTLCs (payments) allowed in a channel. This can minimize
the amount of onchain fees the user will have to pay if they need to
unilaterally close their channel, such as because of a fee ransom attack
(see Newsletter #103).
● BIPs #982 adds changes to BIP340 schnorr signatures (which
also affect BIP341 taproot). BIP340 was previously
changed to use two different tiebreakers for
conveying the Y coordinate of points: squaredness for the R point
inside signatures and evenness for the public keys. As described on
the mailing list (see Newsletter
#111), this update
changes the R point to use evenness, since the performance gains of using
squaredness were not observed in practice, and having consistent
tiebreakers reduces complexity. Other changes included small fixups,
clarifications, and typo corrections.
Similar to previous revisions, the tag for the
tagged hashes in BIP340 was changed, ensuring that any code written for
the earlier drafts will generate signatures that fail validation under
the proposed revisions.