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.

Action items

  • ● 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.

News

  • ● 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.

    Percentage of blocks including segwit transactions, last several weeks

    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.

    $ ## GBT with default parameters
$ bitcoin-cli getblocktemplate | jq '.coinbasevalue / 1e8'
12.54348709

$ ## GBT with segwit enabled
$ bitcoin-cli getblocktemplate '{"rules": ["segwit"]}' | jq '.coinbasevalue / 1e8'
12.56368175

    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 disable it).

  • ● Overflow bug in reference C-language bech32 implementation: Trezor publicly disclosed a bug they discovered in the reference implementation of the bech32 address function for the C programming language. A patch has been released fixing the bug. The bug does not affect users of the other reference implementations written in other programming languages (source).

    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 Newsletter #16.

    1. 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.

    2. 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.

Optech recommends

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.

Notable code changes

Notable code changes this week in Bitcoin Core, LND, C-lightning, and libsecp256k1.

  • ● 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 mistake.

  • ● C-Lightning #2061 fixes the overflow bug in bech32 decoding as described in the News section.