This week’s newsletter contains a security notice about the C
implementation of bech32 address decoding, an analysis of a temporary
reduction in the number of segwit blocks, a link to an interesting
discussion about future features for LN payments, and a few notable code
changes in popular Bitcoin infrastructure projects.
Bech32 security update for C implementation: if you use the
reference implementation of bech32 address decoding for
the C programming language, you need to update to fix
a potential overflow bug. Other reference implementations are
unaffected; see the News section below for details.
Temporary reduction in segwit block production: Optech
investigated reports that a mining pool had stopped producing blocks
that included segwit transactions. We found that the number of segwit
blocks decreased suddenly around October 20th and began rebounding
towards normal a few days ago.
A simple explanation for this sudden decrease and rebound could be a
minor misconfiguration. By default, Bitcoin Core does not produce
segwit-including blocks in order to maintain getblocktemplate (GBT) compatibility with older pre-segwit mining
software. When miners change their software or configuration, it’s
easily possible to forget to pass the extra flag to enable segwit.
To illustrate how easy it is to make this mistake, the example below
calls GBT with its default parameter and its segwit parameter—and
then compares the results by the total potential block reward
(subsidy + fees) each block template could earn.
As you can see, a miner who enabled segwit would’ve earned more
income than a non-segwit miner if one of those example block
templates had been mined. Although a small difference in absolute
terms due to currently almost-empty mempools (about 0.02 BTC or
$100 USD), in relative terms the segwit-including example block
template receives almost 50% more fee income than the legacy-only
template. As mining is expected to be a commodity service with thin
profit margins, this seems to be enough of an incentive to get miners to
create segwit-including blocks—and it will only become more
important in the future as more users switch to using segwit, the
block subsidy decreases, and perhaps fees increase.
Bitcoin Core 0.17.0.1 updated bitcoind’s built-in documentation
for GBT to mention the need to enable segwit, and it has been proposed
in developer discussion to enable segwit GBT by default in some
future version (but still provide a backwards-compatible option to
As Trezor responsibly disclosed the bug to multiple other projects,
they learned from Ledger about an additional bug in the
trezor-crypto library for Bitcoin Cash-style addresses that use
the same basic structure as Bitcoin bech32 addresses. A
patch for that has also been released.
Discussion about improving Lightning payments: in advance of an
upcoming meeting between LN protocol developers, Rusty Russell started
a discussion about two problems he thinks could
potentially be solved using scriptless scripts as described in
An invoice can only be paid a maximum of one time. It’d be nice
for multiple people to be able to pay the same invoice, such as a
static donation invoice or a monthly recurrent payment.
The protocol doesn’t provide proof of payment by a particular spender. You can prove that
a particular invoice was paid, and that invoice could commit to
the identity of the person who was supposed to pay it, but both
the spender and the nodes who help route the payment to the
recipient all have the same data about the payment, so any one of
them could claim to have sent the payment themselves.
If you’re looking for more news about Lightning, check out Rene
Pickhardt’s new weekly collection of the best tweets about LN and what
people are building with it. Follow @renepickhardt on Twitter to
get the latest news and check out the previously published issues:
1, 2, and 3.
Bitcoin Core #14454 adds support to the importmulti RPC for segwit addresses and scripts (P2WPKH, P2WSH, and
P2SH-wrapped segwit). A new witnessscript parameter fulfills the
same role for segwit as the redeemscript parameter for P2SH. Also a
solvable parameter is added to the getaddressinfo RPC to let the user know whether the wallet knows the
redeemScript or witnessScript for a P2SH or P2WSH address, i.e.
whether it knows how to create an unsigned input for spending payments
sent to that address.
LND #2027 adds a configuration option that allows a node to reject
new channels being opened with an initial “push” of funds. This
eliminates an occasional problem merchants are seeing where
inexperienced users receive a BOLT11 invoice for some amount of
money, realize they don’t have a channel open, and so manually open a
channel with an initial payment for the invoiced amount. This
manually-issued payment is not associated with the unique invoice, so
the user doesn’t receive the product or service they attempted to
purchase and the merchant needs to manually issue a refund (if they
can). Merchants who enable the new configuration option provided by
this PR will be able to automatically prevent users from making this
C-Lightning #2061 fixes the overflow bug in bech32 decoding as
described in the News section.