This week’s newsletter describes a proposed change to the bech32 address format
for taproot, mentions a bug handling certain QR-encoded addresses, thanks
new members of the Cryptocurrency Open Patent Alliance, and mentions new
features of the Minsc policy language and compiler. Also included are
our regular sections with summaries of a recent Bitcoin Core PR Review
Club meeting, new software releases and release candidates, and notable
changes to popular Bitcoin infrastructure software.
Action items
None this week.
News
-
● Bech32 addresses for taproot and beyond: Pieter Wuille
published the results of research he conducted with
Gregory Maxwell into finding an optimal constant for updated bech32
addresses to both eliminate the mutability problem
and mitigate other data entry problems as best as possible. He also
replied to research performed by several individuals (1, 2, 3, 4) into
which wallets support forward address compatibility.
That research revealed most wallets will need to be updated in order to pay
taproot addresses even if we continue using an
unchanged BIP173 address scheme. Based on his research and the
other information available, and if there are no convincing
objections, he plans to write a BIP for the tweaked bech32 checksum
formula to be used for segwit v1 addresses (taproot) and subsequent
segwit versioned addresses. If the proposed alternative bech32
addresses are adopted, the following implications exist for wallets
and services:-
● Support for current addresses remains unchanged: wallets that
can send to current native segwit addresses (version 0) or receive
to current segwit addresses will continue to work
without modification. Current native segwit addresses all start
withbc1q. P2SH-wrapped segwit addresses are also unaffected. -
● Wallets that support segwit v1+ addresses now won’t be forward compatible:
wallets that implemented BIP173 forward compatibility will find it
doesn’t work with taproot and subsequent addresses generated using
Wuille’s new proposal. Those addresses will fail with a checksum
mismatch. According to the survey results posted to the mailing
list, the only known wallets affected are Bitcoin Core and BRD
wallet. -
● All other wallets will need to update eventually anyway: the
other wallets and services surveyed don’t currently support
planned taproot addresses, so they’ll need to upgrade anyway when
users start requesting money be sent to those v1 addresses. For
any wallets that already support sending to current segwit
addresses, the update should be easy as the planned algorithm
change is minimal.
-
-
● Thwarted upgrade to uppercase bech32 QR codes: BTCPay Server
recently implemented an optimization described in BIP173 (covered
in Newsletter #46) of creating QR codes for bech32
addresses that start with all capital letters in
order to create smaller and less complex QR codes. Unfortunately, a
merchant using BTCPay soon reported that one of their
customers was unable to pay the new QR codes. With impressive speed,
contributors to BTCPay confirmed that the wallet software used by the
customer did not properly implement RFC3986 case insensitive
schema parsing. Although the wallet’s developers quickly resolved the
issue, BTCPay contributors reverted the QR code change and began
testing a large number of popular user wallets to see how many
supported uppercasebitcoin:schema strings. Unfortunately, from
their initial results, it appears several other popular wallets also
don’t implement case insensitive RFC3986 schema parsing. Anyone
interested in addressing the problem is encouraged to help
test so that the developers of the affected wallets can
be notified about the issue. -
● Cryptocurrency Open Patent Alliance (COPA) gains new members:
Square Crypto announced on Twitter that several new organizations
joined this alliance to prevent patents from being abused to prevent
innovation and adoption of cryptocurrency technology. We join many
others in thanking all the current members of COPA: ARK.io, Bithyve,
Blockchain Commons, Blockstack, Blockstream, Carnes Validadas,
Cloudeya Ltd., Coinbase, Foundation Devices, Horizontal Systems,
Kraken, Mercury Cash, Protocol Labs, Request Network, SatoshiLabs,
Square, Transparent Systems, and VerifyChain. -
● Minsc adds new features: a recent release of this
policy language and compiler adds support for several new data types:
pubkeys, hashes, polices, miniscript,
descriptors, addresses, and networks. It also
adds new functions for conversions:miniscript(),wsh(),wpkh(),
sh()andaddress(). Here’s an example taken from
the project’s website that uses a specified public key, as a BIP32
extended public key with derivation path, and several conversion
functions, returning the set of data specified on the final line:$alice = xpub68Gmy5EdvgibQVfPdqkBBCHxA5htiqg55crXYuXoQRKfDBFA1WEjWgP6LHhwBZeNK1VTsfTFUHCdrfp1bgwQ9xv5ski8PX9rL2dZXvgGDnw/9/0; $policy = pk($alice/1/3) && older(1 month); $miniscript = miniscript($policy); // compile policy to miniscript $descriptor = wsh($miniscript); // wrap with a p2wsh descriptor $address = address($descriptor); // generate the address [ $policy, $miniscript, $descriptor, $address ]
Bitcoin Core PR Review Club
In this monthly section, we summarize a recent Bitcoin Core PR Review Club
meeting, highlighting some of the important questions and answers. Click on a
question below to see a summary of the answer from the meeting.
Periodically make block-relay connections and sync headers is a PR (#19858) by Suhas Daftuar to make eclipse
attacks more difficult by adding a new method
for finding high quality peers. The proposal opens an outbound
connection every five minutes on average to a new peer and syncs headers
with it. If the peer tells the node about new blocks, the node
disconnects an existing block-relay-only peer and gives that connection
slot to the new peer. This
would raise the cost to an attacker to sustain a partitioning attack against a
node because, as long as the node has at least one honest peer in its peer address manager (addrman),
it should always eventually find the valid chain with the most work.
Most of the discussion focused on understanding the proposed change.
-
What are block-relay-only connections?
Block-relay-only connections are a type of connection introduced in Bitcoin Core #15759 that relays blocks but not transactions or the IP addresses of potential peers.
-
Are block-relay-only connections less observable than full-relay connections?
Yes, full-relay connections gossip transactions and addresses, which can reveal information about the network topology and be used by a spy to map connections. ➚
-
Describe a scenario in which periodic block-relay-only connections could help prevent an attack?
When a node has been eclipsed but its addrman still has honest addresses in it. ➚
-
What happens if we learn about new blocks when opening one of these new block-relay-only connections?
If we learn of a new block, we would rotate out an existing next-youngest block-relay-only peer in favor of the new peer. ➚
-
What are potential trade-offs of this change?
It could reduce the number of open listening sockets on the network and increase the network load sustained. Finally, there is the cost/complexity/maintenance associated with any change.
-
Beyond individual node resistance to eclipse attacks, how could this behavior potentially benefit the whole network?
Periodically connecting to new peers to sync tips should help bridge the entire network via more frequent connections and therefore more edges to the network graph, providing more security against partitioning attacks. ➚
Releases and release candidates
New releases and release candidates for popular Bitcoin infrastructure
projects. Please consider upgrading to new releases or helping to test
release candidates.
- ● Bitcoin Core 0.21.0rc2 is a release candidate
for the next major version of this full node implementation and its
associated wallet and other software.
Notable code and documentation changes
Notable changes this week in Bitcoin Core,
C-Lightning, Eclair, LND,
Rust-Lightning, libsecp256k1,
Hardware Wallet Interface (HWI), Bitcoin Improvement Proposals
(BIPs), and Lightning BOLTs.
- ● LND #4782 adds watchtower client support for LN
channels that use anchor outputs, allowing these
anchor channels to back up their states, similar to how legacy channels can
currently be backed up.