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.
None this week.
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.
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_CHECKSIGFROMSTACKwas considered as a generic alternative.
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)
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:
The version currently in the mempool is below of the top 1,000,000 most profitable vbytes (the next block area)
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.
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
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
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
● 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).