This week’s newsletter requests help testing release candidates for
Bitcoin Core and LND, tracks continued discussion about the proposed
noinput and anyprevout sighash flags, and describes several notable
changes to popular Bitcoin infrastructure projects.
Help test Bitcoin Core 0.19.0rc1: production users of Bitcoin Core
are especially encouraged to test this latest release candidate to ensure that it fulfills all of your organization’s needs.
Experienced users who plan to test are also asked to take a few
moments to test the GUI and look for problems that might
disproportionately affect less-experienced users who don’t normally
participate in RC testing.
Help test LND 0.8.0-beta-rc2: experienced users of LND are
encouraged to help test the next release. For the
first time ever, this testing can include creating a reproducible
build of LND and verifying that it has the same hash
as the binaries distributed by the LND developers.
Continued discussion about noinput/anyprevout: this proposed
sighash flag that would allow LN implementations to use eltoo was
discussed again on the Bitcoin-dev and Lightning-dev mailing lists.
After summarizing previous discussions, Christian Decker asked several
questions: is the idea behind the proposal useful? (Respondents seemed
to agree that it was.) Do people want mandatory chaperon signatures?
(Respondents seemed moderately opposed.) Do people want mandatory output
tagging? (Respondents seemed opposed, some strongly.)
In response to the question about output tagging, C-Lightning
contributor ZmnSCPxj proposed an alternative
tagging mechanism that would put the tag inside the taproot
commitment, making it invisible unless a script-path spend was used.
This could allow a spender who was worried about noinput to ensure
they didn’t pay noinput-compatible scripts—the original goal behind output tagging—but without the decrease in
privacy and fungibility created by output tagging. Several people
seemed to express interest in this idea, although it wasn’t clear
whether they wanted to see it as part of a proposal or they just
preferred it to external output tagging (which, as noted above, was
generally opposed by respondents).
The entire thread is more than 20 messages at present and started a
spin-off discussion about OP_CAT. Hopefully the
discussion will be able to settle the major unresolved issues
related to noinput and help get this proposal on track for
inclusion in a subsequent soft fork.
Bitcoin Core #13716 adds -stdinrpcpass and
-stdinwalletpassphrase parameters to
bitcoin-cli that allow it to read either an RPC or wallet
passphrase from the standard input buffer rather than as a CLI
parameter that would be stored in shell history. Echoing is also
disabled on stdin during reading so that the passphrase isn’t visible
to anyone watching your screen.
Bitcoin Core #16884 switches the default address type
for users of the RPC interface (including via bitcoin-cli) from
P2SH-wrapped P2WPKH to native segwit (bech32) P2WPKH. This change is on the
master development code branch and is not expected to be released
until Bitcoin Core 0.20.0 sometime in mid-2020. However, a previous
change expected to be released as part of 0.19.0 in the
next month or so will switch the default address type for GUI users to
also use bech32 P2WPKH.
Bitcoin Core #16507 fixes a rounding issue where a
node would accept transactions into its mempool if they had a
feerate greater than the node’s dynamic minimum feerate but wouldn’t
relay those transactions to peers if the transactions’ feerates were
less than minimum rounded up to next 0.00001000 BTC.
LND #3545 adds code and documentation that allows
users to create reproducible builds of LND. This should allow anyone with
moderate technical skills to build identical binaries to those
released by Lightning Labs, ensuring that users are running the
peer-reviewed code from the LND repository and its dependencies.
LND #3365 adds support for using option_static_remotekey
commitment outputs as described later in this section.
This new commitment protocol is particularly useful when something has
gone wrong and you’ve lost data. If that happens, you need only wait
for your channel counterparty to close the channel by paying a key
directly derived from your HD wallet. Because the key was generated
without any additional data (“tweaking”), your wallet doesn’t need any
extra data in order to find and spend your funds. This is a simplified
alternative to the data loss protection protocol that LND
previously used and continues to understand.
C-Lightning #3078 adds support for creating and using channels
that spend Liquid-BTC on the Liquid sidechain.
C-Lightning #2803 adds a new python package named pyln that
includes a partial implementation of the LN specification. As
described in its documentation, “This package
implements some of the Lightning Network protocol in pure python. It
is intended for protocol testing and some minor tooling only. It is
not deemed secure enough to handle any amount of real funds (you have
C-Lightning #3062 causes the plugin command to return an error if a
requested plugin hasn’t reported successful startup within 20 seconds.
BOLTs #676 amends BOLT2 to specify that a node should not send
the funding_locked message until it has validated the funding
transaction. This warns future implementers about the problem that
lead to the vulnerabilities described in last week’s newsletter.
BOLTs #642 allows two peers opening a channel to negotiate an
option_static_remotekey flag. If both peers set this flag, any
commitment transactions they create which they’re able to spend
unilaterally (e.g. to force close the channel) must pay their peer’s
funds to a static address negotiated during the initial channel open.
For example, if Alice has the address bc1ally, Bob has the address
bc1bob, and they both request option_static_remotekey,
any commitment transactions that Alice can publish onchain must pay
bc1bob and any commitment transactions that Bob can publish
onchain must pay bc1ally. If at least one of them doesn’t set
this flag, they’ll fall back to the older protocol of using a different
payout address for each commitment transaction, with the addresses
created by combining the remote peer’s pubkey with a commitment
Always paying the same address allows that address to be a normal
derivable address in the client’s HD wallet, making it possible for
the user to recover their funds even if they’ve lost all of their
state besides their HD seed. This is believed to be superior to the
data loss protection protocol which depends on storing enough
state to be able to at least contact the remote peer and identify
the channel. With option_static_remotekey, it can be assumed that
the remote peer will eventually get tired of waiting for a missing
peer to show up and will unilaterally close the channel, putting the
funds onchain in an address where your HD wallet will find them.