This week’s newsletter summarizes meetings from the CoreDev.tech event, describes a proposed amendment to BIP125 replace-by-fee, links to an Optech executive briefing video about Schnorr/Taproot, and briefly celebrates the 50th weekly issue of the Optech Newsletter. Also included are our regular sections on bech32 sending support and notable changes to popular Bitcoin infrastructure projects.

Action items

None this week.

News

• ● Bitcoin Core contributor meetings: many contributors met in person for a periodic CoreDev.tech event last week, with real-time transcripts provided by contributor Bryan Bishop:

  • ● June 5th: a session on code review discussed a survey sent to active Bitcoin Core contributors and developed several suggestions for streamlining reviews.

    Participants discussed changing the wallet architecture to using output script descriptors for generating addresses, tracking when they’ve been paid, and finding or deriving the particular private keys necessary for spending.

  • ● June 6th: discussion of the consensus cleanup soft fork included its interaction with bip-taproot, whether parts of it should be dropped, and whether anything should be added. (More background)

    The group asked what they could do to make the maintainers’ work easier. Among other considerations, the maintainers noted appreciation for the issue and PR management provided by long-time contributor Michael Ford. Meeting participants responded to this by granting maintainer status to Ford so that he can be even more effective.

    Potential script changes were discussed. Discussion of the BIP118 and bip-anyprevout sighashes revolved around output tagging (see Newsletter #34) and chaperone signatures (#47). The renamed bip-coshv opcode was reviewed (see #48) and OP_CHECKSIGFROMSTACK was considered as a generic alternative.

    A Taproot topic included discussion about using a merkle tree instead of an accumulator and risks related to fast quantum computers. (More background)

    A Q&A session about the Utreexo accumulator for the UTXO set highlighted some interesting details of this developing proposal for minimizing full node storage requirements.

  • ● June 7th: code for the assumeutxo proposal was demoed and discussed, including how to make the proposal compatible with other ideas. (More background)

    Contributors discussed getting hardware wallet support via HWI directly integrated into Bitcoin Core. A particular concern was code separation—ensuring that code for specific hardware devices is maintained by the manufacturer and not Bitcoin Core. (More background)

    The version 2 P2P transport protocol and the related countersign protocol (see #27) were discussed. Several possible enhancements were mentioned during the discussion. (More background)

    A review of the signet idea for a testnet-like chain where all blocks are signed by a trusted party focused on the various ways to distribute the signatures. (More background)

    Although just announced this week on the Bitcoin-Dev mailing list, blind statechains were also discussed.

• ● Proposal to override some BIP125 RBF conditions: BIP125 opt-in Replace-By-Fee (RBF) only allows replacing a transaction with a higher-feerate alternative if the replacement increases the total amount of transaction fee paid in the entire mempool. This stops a cheap bandwidth-wasting Denial-of-Service (DoS) attack against full nodes but makes possible a fairly cheap transaction pinning DoS attack against certain uses of RBF, such as in time-sensitive protocols like LN.

  Several developers have previously attempted to solve this dilemma, with a proposal late last year from Matt Corallo containing a possible solution using CPFP fee bumping (CPFP carve out, see Newsletter #24) and suggesting an alternative workaround that tweaks RBF. Rusty Russell previously discussed this RBF change with Corallo, has further refined it, and now proposed it to the Bitcoin-Dev mailing as the addition of a single rule to the BIP125 ruleset. The new rule allows any BIP125 replaceable transaction in the mempool to be fee bumped under two conditions:

  1. The version currently in the mempool is below of the top 1,000,000 most profitable vbytes (the next block area)

  2. The replacement version pays a high enough fee that it will be in the next block area

  This would allow any transaction to be fee bumped without consideration of any of that transaction’s children, eliminating the problem with pinning. However, anyone using this rule could reduce the overall amount of fee in the mempool and might be able to use it to excessively waste node bandwidth. Several people replied to the proposal asking questions and offering analysis about these risks.

• ● Presentation: The Next Softfork: Bitcoin Optech contributor Steve Lee gave a presentation during last month’s Optech Executive briefings about possible future Bitcoin soft forks. The video is now available. In his presentation, Lee describes the various phases of a soft fork from idea to proposal to implementation to activation. Using this framework, he identifies the current state of the Schnorr/Taproot soft fork (see Newsletter #46), the consensus cleanup soft fork (#36), and the noinput soft fork proposals (BIP118 and bip-anyprevout, see #47). Although later in the presentation he provides an overview of the consensus cleanup soft fork (fixing several non-urgent problems in the protocol) and the noinput proposals (enabling new features for contract protocols such as the Eltoo layer for LN), his talk—and this summary of it—focuses on the combined bip-schnorr, bip-taproot, and bip-tapscript proposal.

  After providing a high-level overview of Schnorr signatures and signature aggregation—information probably already familiar to readers of this newsletter—Lee builds a significant portion of his presentation around 2-of-3 multisig security for business spenders, a feature used by many businesses today. He first describes the savings available to users of threshold keys, aggregated public keys that only require a subset of the original parties in order to create a valid signature, such as an aggregated key created from three individual keys that can be signed for by any two of the participants for 2-of-3 multisig security. The upside of this approach is maximal efficiency and privacy onchain, but the downside is required interactivity creating the pubkey, interactivity creating the signature, and an inability of the keyholders to use block chain data for auditing to determine which subset of them actually participated in signing.

  Addressing both the public key interactivity and the signature auditing concerns, Lee uses an easy-to-understand sequence of illustrated slides to demonstrate an alternative construction possible using a combination of Taproot’s key-path and script-path spending. Three MuSig-style 2-of-2 aggregated pubkeys are created—one for each of the three possible pairs of signers in 2-of-3 multisig. Because this is MuSig n-of-n key aggregation, it doesn’t require interaction. The most likely of these combinations (e.g. a hot wallet key and a third-party security key) is made available for Taproot key-path spending, allowing an output to be spent using a single aggregate signature that looks like any single-sig spend. The two alternative options (e.g. each involving a cold backup key) are placed in a MAST tree for a script-path spend. This isn’t as private or as cheap but it provides redundancy. For any of these options, any third-party looking at the block chain data sees only a single signature and no direct information about how many parties are involved, but each of the three key holders knows which two of the participants’ public keys were used to create the particular aggregated key that the spending signature matched, giving them private auditability. Lee concludes this portion of the talk by summarizing the tradeoffs and showing the clear overall benefits of Schnorr and Taproot for current multisig spenders.

  In addition to enhancing current uses of Bitcoin, also described are new features that aren’t currently practical but which would become so if Schnorr-style signatures and MAST-style script trees become available. Lee finishes his talk by providing a rough, and heavily caveated, timeline for when we might see the changes described in his talk.

• ● Optech celebrates Newsletter #50: in early June of last year, John Newbery emailed Dave Harding about some plans he had for the newly formed Optech organization—including the single sentence, “We’ll also produce some written material [such as] weekly or monthly news summaries.” Being a bit bored that day, Harding replied back with an unsolicited proof-of-concept newsletter. Newbery and other early Optech contributors liked it, so a few details were worked out and regular weekly publication of this newsletter began.

  Fifty issues later, the newsletter now has over 2,500 email subscribers and an unknown number of additional unique subscribers via RSS, Twitter, and Max Hillebrand’s readings. We’ve published over 85,000 words overall—about 250 printed pages of content—with draft versions of the newsletters having received a total of 948 comments so far from an amazing team of reviewers who help ensure technical accuracy and readable prose. Announcements of new newsletters have accumulated over 1,300 retweets and 3,000 likes, plus many upvotes on Reddit. Most importantly, we’ve heard directly from many of our readers that they find the newsletter to be especially useful.

  We’re amazed, gratified, and humbled that a purely technical newsletter focused solely on Bitcoin has received such an amazing reception in its first year of publication. We know you all have high expectations from us going forward, and we hope that we can live up to those aspirations in our next fifty issues. As always, we thank our founding sponsors, member companies, all the people who have contributed to the newsletter, and everyone who has contributed to Bitcoin development in general—without you, we’d be writing about something much less exciting than the future of money.

Bech32 sending support

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

Bech32 addresses aren’t the first time some Bitcoin users have changed address formats. In April 2012, P2SH addresses starting with a 3 were introduced and eventually came to be used in about 25% of all transaction outputs. This week, we’ll look at the relative speed of adoption of the two different address formats. For reasons we describe later, this can’t be an entirely fair comparison, but it may provide us with a rough guide to how well we’re doing so far with bech32 adoption.

We’ll first look at the percentage of outputs per block sent to P2SH or native segwit (bech32) addresses as measured from the day each proposal became active on mainnet. All plots in this section are averaged over 30 days using a simple moving average. We also limit the data points on P2SH plot to about two months before segwit activation so that almost no P2SH-wrapped segwit outputs are miscounted as legacy P2SH.

One particularly unfair aspect of the above plot is that P2SH is really only useful for advanced scripts (such as multisig). There was no need and no benefit for anyone using single-sig addresses (those starting with a 1) to upgrade to P2SH. By comparison, there are native segwit addresses for both single-sig users (P2WPKH) and advanced script users (P2WSH). To try to make that comparison more fair, the following plot over a smaller date range separates the two uses of native segwit so you can compare bech32 P2WSH use to its rough equivalent P2SH.

Notably, we see that almost all use of native segwit addresses to date is for single-sig P2WPKH. The P2SH activity prior to segwit activation, which peaked at 25% of all outputs, has not migrated to native P2WSH outputs. Indeed, when we consider that all LN deposit transactions (and at least some other onchain LN transaction) are using native P2WSH outputs, it appears as if almost none of the late-2017 P2SH activity has converted to P2WSH so far.

This points to another aspect that makes the different address data hard to compare: all the things that were possible using legacy P2SH are also possible using either P2SH-wrapped segwit addresses or native P2WSH addresses. P2SH-wrapped segwit addresses are backwards compatible and can significantly reduce transaction fees whereas bech32 addresses aren’t backwards compatible with older wallets and only save a small fixed amount of extra fees compared to P2SH-wrapped segwit. This may give users of advanced scripts less incentive than other users to switch from P2SH-wrapped segwit address to native segwit addresses in the short term.

Overall, the plot seems to show that it took about three years for P2SH addresses to really start taking off, but that bech32 address were already successful within just a few months of the segwit soft fork activation. With some wallets already defaulting to bech32 and several more planning to do so in the coming months, we expect to see increased adoption before the end of 2019.

Notable code and documentation changes

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

• ● LND #2802 allows LND to calculate the probability that a particular route will succeed. It then uses that probability to choose the best route in combination with existing calculations of the total fee cost and maximum HTLC timeout for the path. Several new configuration options are added that allow the user to tweak constant values used in the probability calculation, such as the “assumed success probability of a hop in a route when no other information is available.” The author of the PR also discussed routing success probability in his talk last weekend at the Breaking Bitcoin conference.

• ● C-Lightning #2644 changes how C-Lightning keeps track of which channel updates it has gossiped to its peers. Previously, a map was kept for each peer tracking which updates had been sent and which were waiting to be sent. Now, a single ordered list of updates is kept by the entire program and each peer connection simply tracks how far it is through sending all the entries in that list. When a connection reaches the end of the list, its position is marked so that it can send any new entries that are subsequently added to the list. When a later update makes a previous update irrelevant, the previous update is removed from the global list and any connections that haven’t sent that update will never see it. In testing (presumably as part of the million channels project), this reduced overall memory usage by 35% (about 150 MB) and sped up sending all gossip announcements to all peers by 62% (about 11 seconds).