This week’s newsletter describes a proposal to tweak Bitcoin Core’s
relay policy for related transactions to help simplify onchain fees for
LN payments, mentions upcoming meetings about the LN protocol, and
briefly describes a new LND release and work towards a Bitcoin Core
Bitcoin Core is preparing for upcoming maintenance release 0.17.1.
Maintenance releases include bugfixes and backports of minor features.
Anyone intending to take this version is encouraged to review the list of
backported fixes and help with testing when a release
candidate is made available.
CPFP carve-out: in order to spend bitcoins, the transaction
where you received those bitcoins must be added to the block chain
somewhere before your spending transaction. That addition can be in a
previous block or it can be earlier in the same block as the spending
transaction. This protocol requirement means that a spending
transaction with a high feerate can, through averaging, make it
profitable to mine its unconfirmed parent transaction even if that
parent has a low feerate. This is called Child Pays For Parent
CPFP even works for multiple descendant transactions, but the more
relationships that need to be considered, the longer it takes the node
to create the most profitable possible block template for
miners to work on. For this reason, Bitcoin Core
limits1 the maximum number and size of related
transactions. For users fee bumping their own transactions, the
limits are high enough to rarely cause problems. But for users of
multiparty protocols, a malicious counterparty can exploit the
limits to prevent an honest user from being able to fee bump a
transaction. This can be a major problem for protocols like LN that
rely on timelocks—if a transaction isn’t confirmed before the
timelock expires, the counterparty can take back some or all of the
funds they previously paid.
To help solve this problem, Matt Corallo has suggested a change to the CPFP policy to carve-out (reserve) some
space for a small transaction that only has one ancestor in the
mempool (all of its other ancestors must already be in the block
chain). This accompanies a proposal for LN described in the News
section of last week’s newsletter where LN would mostly ignore
onchain fees (except for cooperative closes of channels) and use
CPFP fee bumping to choose the fee when the channel was
closed—reducing complexity and improving safety. However, to make
this safe for LN no matter how high fees get, nodes need to also
support relaying packages of transactions that include both
low-feerate ancestors plus high-feerate descendants in a way that
doesn’t cause nodes to automatically reject the earlier transactions
as being too cheap and so not see the subsequent fee bumps. Whereas
the carve-out policy is probably easy to implement, package relay is
something that’s been discussed for a long time without yet being
formally specificed or implemented.
Organization of LN 1.1 specification effort: although LN protocol
developers decided which efforts they want
to work on for the next major version of the common protocol, they’re
still working on developing and coming to agreement on the
exact specifications for those protocols. Rusty Russell is organizing
meetings to help speed up the specification process and has started a
thread asking for feedback about what medium to
use for the meeting (Google Hangout, IRC meeting, something else) and
how formal to make the meeting. Anyone planning to participate in the
process is recommended to at least monitor the thread.
Releases:LND 0.5.1 is released as a new minor version with
improvements particularly focused on its support for Neutrino, a
lightweight wallet (SPV) mode that LND can work with to make LN
payments without having to directly use a full node. This release also
fixes an accounting bug for users of the btcwallet backend where not
all change payments to yourself may have been reflected in your
displayed balance. Upon upgrading, a rescan on the block chain will
be performed so that the missing accounting information is recovered
and your correct balance will be displayed. No funds were at risk,
they just weren’t tracked correctly.
The Bitcoin Core project is planning to start tagging release
candidates for maintenance version 0.17.1 soon.
This is expected to resolve some bugs with build system incompatibilities on
recent Linux distributions as well as fix other minor issues.
LND #1937 stores the most recent channel reestablishment message
in the node’s database so that it can be resent even after a channel
has been closed. This improves the node’s chance of recovering from a
connectivity problem combined with partial data loss.
Bitcoin Core #14477 adds a new desc field to the
getaddressinfo, listunspent, and scantxoutset RPCs with the
output script descriptor for each address
when the wallet has enough information to consider that address
solvable. An address is solvable when a program knows enough about
its scriptPubKey, optional redeemScript, and optional witnessScript in
order for the program to generate an unsigned input spending funds
sent to that address. A new solvable field is added to the
getaddressinfo RPC to independently indicate that the wallet knows
how to solve for that address.
The new desc fields are not expected to be particularly useful at
the moment as they can currently only be used with the
scantxoutset RPC, but they will provide a compact way of providing
all the information necessary for making addresses solvable to
future and upgraded RPCs for Bitcoin Core such as those used for interactions between
offline/online (cold/hot) wallets, multisig wallets, coinjoin
implementations, and other cases.
LND #2081 adds RPCs that allow signing a transaction template
where some inputs are controlled by LND. Although this particular
tool mirrors functionality already provided by the lnwallet.Signer
service, the mechanism used to enable this new service makes it
possible for developers to extend the RPCs (gRPCs) provided through
LND with gRPCs provided by other code on the local machine or even a
remote service. Several additional new services using this mechanism
are planned for the near future.
Bitcoin Core’s ancestor and descendant depth limits:
$ bitcoind -help-debug | grep -A3 -- -limit
Do not accept transactions if number of in-mempool ancestors is <n> or
more (default: 25)
Do not accept transactions whose size with all in-mempool ancestors
exceeds <n> kilobytes (default: 101)
Do not accept transactions if any ancestor would have <n> or more
in-mempool descendants (default: 25)
Do not accept transactions if any ancestor would have more than <n>
kilobytes of in-mempool descendants (default: 101).