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 with bc1q. 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 uppercase bitcoin: 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() and address(). 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.