This week’s newsletter announces the maintenance release of Bitcoin Core 0.18.1, summarizes a discussion about BIP174 extensions, and notes a proposal for LN trampoline payments. Our bech32 sending support section this week features a special case study contributed by BRD and our notable changes section highlights several possibly significant developments.

Action items

  • Upgrade to Bitcoin Core 0.18.1 when binaries are released: this maintenance release has been tagged, and binaries are expected to be uploaded to bitcoincore.org in the next few days. The release makes available several bug fixes and other improvements. Upgrading is recommended when the binaries are available.

News

  • BIP174 extensibility: the author of the Partially Signed Bitcoin Transactions (PSBTs) specification, Andrew Chow, proposed a few minor changes for general adoption:

    • Reserved types for proprietary use: some applications are already including data in PSBTs using types that aren’t specified in BIP174. It’s proposed that one type byte or a range of type bytes be reserved for private PSBT extensions, similar to reserved IP address ranges for private networks. The exact construction of this mechanism was a particular focus of discussion this week.

    • Global version number: although the goal is to design enhancements to PSBTs so that they’re backwards compatible, Chow proposed to add a version byte to PSBTs indicating the most advanced feature they use so that older parsers can detect when they’re being given a PSBT they might not understand. PSBTs without an explicit version number would be considered to use version 0.

    • Multi-byte types: To allow more types, multi-byte types are proposed. Mailing list discussion seems to favor using the same CompactSize unsigned integers used in the Bitcoin protocol.

  • Trampoline payments: Bastien Teinturier opened a PR in the BOLTs repository and started a discussion on the Lightning-Dev mailing list about adding support to the protocol for the trampoline payments described in Newsletter #40 where the spender sends the payment to an intermediate node who calculates the path either to another intermediate node (for privacy) or to the receiving node. This can be very beneficial to low-bandwidth LN clients (such as on mobile devices) that don’t want to keep up with gossip traffic and so only know how to route to a small number of nodes. Sending a trampoline payment will require coordination between multiple nodes, so it should be documented in the Lightning specification.

Bech32 sending support

Week 21 of 24 in a series about allowing the people you pay to access all of segwit’s benefits.

The following case study contributed by Optech member company BRD describes what they learned implementing bech32 and other segwit technology for their wallet.

We began implementing bech32 support in BRD wallet in January 2018 with the addition of bech32 decoding and encoding support to breadwallet-core, an MIT-licensed cross-platform C library with no external dependencies. All of our software avoids third-party library dependencies as much as possible, with it currently using only Pieter Wuille’s libsecp256k1. Minimizing dependencies is typical for a high-security crypto project. For the bech32 implementation, we found that bech32’s BIP173 is pretty well documented, so there were no specific issues that were complex to deal with.

In March 2018, breadwallet-core was updated to automatically parse anything provided as a Bitcoin address to determine whether it was a legacy P2PKH, legacy P2SH, or segwit bech32 and to automatically generate the appropriate scriptPubKey in each case. This allowed BRD to begin sending to bech32 addresses. Finally in October 2018, we implemented full segwit support across the library backend and mobile app frontends, allowing users to begin receiving to bech32 addresses and making the default that all change addresses were now bech32.

One thing we never implemented was support for receiving to P2SH-wrapped segwit addresses, instead going straight to bech32. This was a deliberate design optimization to make the best use of the bloom filter mechanism BRD uses to scan for transactions affecting user wallets. To allow users to track when they’ve been paid, bloom filters are matched against each data element in a scriptPubKey. For a given public key, the data element in the scriptPubKey is identical for both legacy P2PKH and native segwit (bech32) P2WPKH. Here’s an example previously used by Optech:

  • Legacy P2PKH scriptPubKey for address 1B6FkNg199ZbPJWG5zjEiDekrCc2P7MVyC:

    OP_DUP OP_HASH160 OP_PUSH20 6eafa604a503a0bb445ad1f6daa80f162b5605d6 OP_EQUALVERIFY OP_CHECKSIG

  • Native segwit (bech32) P2WPKH scriptPubKey for address bc1qd6h6vp99qwstk3z668md42q0zc44vpwkk824zh:

    OP_0 OP_PUSH20 6eafa604a503a0bb445ad1f6daa80f162b5605d6

Because a bloom filter for a given element will match both P2PKH and P2WPKH addresses for the same public key, BRD is able to scan for either type of payment with zero additional overhead. It also makes the implementation much cleaner and doesn’t increase the resource use of public nodes that serve bloom filters. This may be a worthwhile optimization for wallets and services using other types of scanning as well, as it may produce less overhead than the separate HD derivation path recommended by BIP84.

ScriptPubKeys generated from bech32 addresses vary in length, affecting the amount of transaction fee that needs to be paid. Fee calculation on Bitcoin is hideous—feerates spike multiple orders of magnitude in a 24 hour period sometimes—but that was already true before segwit so we previously spent a lot of time on fee calculation and made it as flexible as possible. That means the variability in size of scriptPubKeys generated from bech32 addresses doesn’t change anything for BRD.

We want today’s app to be future-proof so the code supports sending to future segwit versions (see Optech’s description). That means, for example, BRD will support paying to taproot addresses automatically if Bitcoin users choose to make that soft fork change to the consensus rules.

Once real momentum is established and most other wallets and services support sending to bech32 addresses, BRD’s bech32 receiving support will be rolled out to our entire user base as the default setting. In preparation of this transition, it is important to get as many companies and services as possible to voluntarily start supporting bech32 sending capability. To help encourage adoption, we created the WhenSegwit website and became a member company of Optech. We hope that other wallets and services will make their own transitions to full segwit support soon while fees are still relatively low.

Notable code and documentation changes

Notable changes this week in Bitcoin Core, LND, C-Lightning, Eclair, libsecp256k1, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

  • Bitcoin Core #15911 changes the walletcreatefundedpsbt to signal BIP125 Replace-by-Fee (RBF) if the wallet is configured to use RBF (the configuration option walletrbf).

  • Bitcoin Core #16394 changes the createwallet RPC so that if an empty string is passed for the passphrase parameter, an unencrypted wallet will be created (and a warning printed).

  • LND #3184 adds a watchtower client sub-server to LND that replaces the private watchtower implementation added for the most recent release.

  • LND #3164 creates a new database into which information about the past 1,000 payments is stored. (The default of 1,000 can be changed.) This is meant for use with LND’s Mission Control feature that tries to better use information from past payment attempts (especially failures) to choose better routes for subsequent payment attempts. During the first upgrade to a version including this change, details about previous payments will be populated into this database from LND’s lower-level HTLC-tracking database.

  • LND #3359 adds an ignore-historical-filters configuration option that will cause LND to ignore a gossip_timestamp_filter sent from a peer. That filter allowed peers to request all announcements that would’ve been gossiped during an earlier date range. By ignoring requests for the filter, LND uses less memory and bandwidth. The ignore option currently defaults to False, so there’s no change in default LND behavior, but a commit comment notes “down the road, the plan is to make this default to True.”

  • C-Lightning #2771 allows plugins to indicate whether or not they can be started and stopped during runtime rather than just being started on init and stopped on shutdown. This information is used by a new plugin command that allows users to perform these runtime stops and starts.

  • C-Lightning #2892 now always runs plugins from the Lightning configuration directory, reducing inconsistencies between different installs and making it easy for plugins to store and access data within that directory.

  • C-Lightning #2799 provides a new forward_event notification for plugins that alerts when an HTLC has been offered, settled, failed by both parties, or failed locally (unilaterally). Additionally, the PR extends the listforwards RPC with a payment_hash field to allow the user to find additional information about the HTLC.

  • C-Lightning #2885 spaces out reconnections to channel peers on startup in order to reduce the chance that a traffic flood causes C-Lightning to take more than 30 seconds to re-establish a channel after connecting to a peer. This was the problem that was causing LND to send sync error messages as described in last week’s newsletter.

  • BOLTs #619 adds support for variable-sized payloads in LN onion routing. Combined with Type-Length-Value (TLV) encoded fields, which was merged into the specification three weeks ago (see Newsletter #55), this makes it much easier to place extra data into the encrypted packets that relay payments, enabling the addition of several features (including the trampoline payments discussed earlier in this week’s newsletter).