This week’s newsletter announces a new maintenance release of Bitcoin
Core, describes continued discussion about new signature hashes, and
links to a post about possible economic barriers to LN payments crossing
different currencies. Descriptions of notable code changes in popular
Bitcoin infrastructure projects are also provided.
Upgrade to Bitcoin Core 0.17.1: this new minor
version released December 25th restores some previously-deprecated
functionality to the listtransactions RPC and includes bug fixes and
other improvements. Consider reading the release notes and upgrading.
Continued sighash discussion: as mentioned in the News section of
Newsletter #25, developers on the Bitcoin-Dev mailing list
discussed how signature hashes could be modified to give transactions
access to new capabilities. Sighashes give spenders the ability to
allow their transactions to be modified in specified ways after they
are signed—for example, two people who open a payment channel
together can use a particular type of sighash to allow either one of
them to unilaterally attach additional transaction fees to a channel
The most recent discussion in this thread of almost 70 posts has
mostly involved edge cases related to new sighash flags,
particularly a BIP118-like SIGHASH_NOINPUT_UNSAFE. As part of the
discussion, protocol developer Johnson Lau described an
optimization for Eltoo-based payment channels. Also
discussed is whether the OP_CODESEPARATOR opcode
should be disabled in a script update that supports MAST (e.g. via
Taproot). That opcode is not in common use, but if you plan to use
it in future Script versions, you should comment on the thread.
Cross-chain LN as an options contract: pseudonymous LN
contributor ZmnSCPxj started a thread on the Lightning-Dev mailing
list pointing out that users could abuse payments that cross
currencies to create almost free short-term options contracts by
delaying payment settlement. A previous thread by Corné
Plooy in May 2018 described the same thing.
For example, Mallory learns that Bob is willing to route payments
from Bitcoin to Litecoin, so she sends a payment from one of her
Bitcoin nodes through Bob to one of her Litecoin nodes. If this
were a normal payment, she’d settle it immediately by releasing the
preimage for the payment’s hashlock—but instead her node delays
for 24 hours waiting for the exchange rate to change. If the
exchange rate increases in Litecoin’s favor, Mallory settles the
payment and receives litecoin today at yesterday’s exchange rate.
If the exchange rate stays the same or increases in Bitcoin’s favor,
Mallory causes the payment to fail and gets her bitcoin back. Since
no fees are charged for failed payments, Mallory received an
opportunity to temporarily lock-in the price of Litecoin for nothing
but the cost of owning the bitcoins Mallory would’ve traded.
There currently aren’t any known cross-currency LN nodes, but the
availability of this trick means that future such nodes could be
abused for speculation rather than payment routing. If this turns
out to be a real problem and if an acceptable solution isn’t found,
it may be the case that payment channel networks for different
currencies will be isolated from each other.
Bitcoin Core #14565 significantly improves the error handling for
the importmulti RPC and will return a warnings field for each
attempted import with an array of strings describing any problems with
the that import (but only if there were any problems).
Bitcoin Core #14811 updates the getblocktemplate RPC to require that the segwit flag be passed. This
helps prevent miners from accidentally not using segwit, which reduces
their fee income. See Newsletter #20 for a recent instance where
this may have happened to a large mining pool.
C-Lightning #2172 allows lightningd to be shutdown normally even
if it’s operating as the primary process (PID 1), which can be useful
in Docker containers. This is, for example, how the open source
BTCPay server runs C-Lightning.
C-Lightning #2188 adds notification subscription handlers that can
be used by plugins, with initial support for notifications that the
node has connected to a new peer or disconnected from an existing
peer. The plugin documentation and sample
plugin have been updated for these handlers.
LND #2374 increases the maximum size of the gRPC messages the
lncli tool will accept, raising it from 4 MB to 50 MB. This fixes a problem
some nodes were encountering where the describegraph RPC was failing
due to the network having grown so large that messages exceeded this
limit. Developers using gRPC directly will need to increase their
client-side maximum message size setting—descriptions of how to do
this have already been added as comments to the PR for python and nodejs.
Ultimately it’s expected that the network will grow large enough to
exceed even this new maximum, so developers are planning to revamp the
relevant RPCs to handle this situation.
LND #2354 adds a new invoicestate field and deprecates the former
settled field in RPCs that get information about invoices. The
settled field was boolean but the new state field can support multiple
values. Currently this is just “open” or “settled”, but additional
future states are planned.