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
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.
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
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:
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.
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
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
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).