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