This week’s newsletter describes fidelity bonds for JoinMarket-style decentralized coinjoin, mentions a PR for BIP322 signmessage support (including the ability to sign for bech32 addresses), and summarizes a discussion about bloom filters. Also included are our regular sections about bech32 sending support, popular Q&A from the Bitcoin Stack Exchange, and notable changes to popular Bitcoin infrastructure projects.

Action items

• ● Help test Bitcoin Core 0.18.1 release candidates: this upcoming maintenance release fixes several bugs that affected some RPC commands and caused unnecessarily high CPU use in certain cases. Production users are encouraged to test the current release candidate to ensure that it operates as expected.

News

• ● Fidelity bonds for improved sybil resistance: JoinMarket developer Chris Belcher posted to the Bitcoin-Dev mailing list about a possible solution to a previously-known problem that affects decentralized coinjoin implementations. Users of JoinMarket operate as either makers advertising their willingness to participate in a coinjoin or as takers who initiate mixes with the makers they select. It’s possible for a single sybil attacker to pose as enough different makers that one or more of their sockpuppets is selected in almost every coinjoin, giving them the ability to eliminate or significantly reduce the privacy benefits of coinjoining.

  Belcher proposes that makers create a persistent cryptographic identity by either destroying (“burning”) bitcoins or by timelocking bitcoins for an extended period of time. These sacrifices would be accompanied by a public key that the maker could use to sign their ephemeral identity in JoinMarket. Takers would then randomly select qualifying makers for coinjoins weighted by the size of their sacrifice (as determined by a formula).

  On the upside, this would require attackers to sacrifice significant amounts of bitcoins or the ability to sell bitcoins, making sybil attacks more expensive. On the downside, honest makers would likely charge more for coinjoins in order to receive compensation for their sacrifices, raising the cost of JoinMarket coinjoins.

• ● PR opened for BIP322 generic signed message format: Kalle Alm opened a PR to Bitcoin Core with an implementation of BIP322 that updates the signmessage, signmessagewithprivkey, and verifymessage RPCs to support signing for P2WPKH and P2SH-P2WPKH addresses in addition to legacy P2PKH addresses. The PR is currently seeking feedback and conceptual review. Although this PR only provides a basic implementation of BIP322 support, future extensions could allow Bitcoin Core to sign and verify messages for any spendable script, with such support easily upgradable for future changes in the scripting language such as taproot. Hopefully other wallets would then consider implementing BIP322 themselves to provide flexible forward-compatible message signing support. See Optech’s previous bech32 section where we lamented the lack of a BIP322 implementation.

  Based on early feedback on the PR, BIP322 has also been updated so that signing and verifying messages with legacy P2PKH keys uses the old signmessage format. This allows BIP322 tools to be fully backwards compatible with the existing and widely-implemented signmessage standard (which only supports P2PKH).

• ● Bloom filter discussion: in the notable changes section of last week’s newsletter, we mentioned a merged PR that disabled bloom filters in Bitcoin Core’s default configuration. The author of the PR announced this unreleased change to the Bitcoin-Dev mailing list and several people replied with questions or concerns. Some takeaways from the discussion include:

  • ● No urgent action required: as of this writing, over 20% of nodes accepting incoming connections (listening nodes) are running a version of Bitcoin Core that’s over a year old according to BitNodes. At least 5% are running a version that’s over two years old. Extrapolating to the future, that means there will still be over 500 listening nodes providing bloom filters at the beginning of 2022. So, even with no further action, wallet developers may have a significant amount of time in which to adapt their programs.

  • ● Spies likely to run their own nodes: additional to non-upgraded nodes, it’s possible that block chain analysis companies will continue to run their own nodes providing bloom filter support in the future so that they can collect statistics from wallets whose filters leak information about what addresses they contain.

  • ● DNS seeds can return only nodes signaling BIP111: most P2P light wallets query one or more Bitcoin DNS seeds for a list of nodes to use. Some seeds allow filtering which nodes they return by what service bits that node has configured¹, with the service bit for bloom filter support being specified by BIP111.

  • ● BIP157 would use more bandwidth than BIP37: it was suggested that some users of BIP37 bloom filters will be unable to switch to BIP157 compact block filters because of the later’s higher bandwidth usage. Optech briefly investigated filter size in Newsletter #43 and found the filters themselves to use less than 100 MB a month. Clients would also need to download matching blocks, which would vary depending on their activity (roughly one block for every sent or received transaction for typical users; most blocks are less than 2 MB in size). It’s unclear how many users would be significantly affected by having to download that amount of data.

  • ● Interested parties can run their own nodes: the change to Bitcoin Core only disables serving bloom filters by default. It doesn’t remove the feature. Authors of wallets depending on bloom filter support can easily operate their own nodes, and they can also try to persuade other node operators who aren’t worried about the DoS vulnerability to set the configuration option to true, e.g. peerbloomfilters=1.

Bech32 sending support

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

In percentage terms, the number of native segwit outputs—payments to bech32 addresses—has slightly declined over the past year (~50,000 blocks). The obvious explanation would be that people tried bech32 addresses, didn’t like them, and went back to using legacy addresses or P2SH-wrapped segwit addresses. If that’s the case, should we give up on bech32 addresses?

Note: all charts in this section use a simple moving average over 10,000 blocks.

Perhaps first we should investigate whether there’s an alternative explanation. Percentages are synthetic results—information derived from combining multiple other sources—so the first thing to look at is the raw data. The graph below shows the total number of outputs paid to various types of scripts over the past two years:

Contrary to the percentage data, we see the number of P2WPKH outputs slowly (but steadily) increasing. What we also see is that the number of other outputs is also increasing. This may become more clear if we stack the totals:

Now we can see that the average number of outputs is slightly higher today than it was at the previous peak of Bitcoin activity during late 2017 and early 2018. That makes sense—the more transactions that use segwit, the more block space there is available for other transactions. However, despite the overall increase, there are slightly fewer payment outputs (P2PKH, P2SH, and native segwit). The remaining outputs constitute a significant increase in the number of OP_RETURN (nulldata) scripts.

This growth in the overall number of outputs and the number of nulldata outputs explains why the percentage of bech32 outputs has been declining despite the absolute number increasing. It means that we shouldn’t give up on bech32. Indeed, the recent spike in overall outputs (and other recent data available elsewhere) may be a sign of upcoming feerate increases that will encourage more users and organizations to cut costs by switching to bech32.

Selected Q&A from Bitcoin Stack Exchange

Bitcoin Stack Exchange is one of the first places Optech contributors look for answers to their questions—or when we have a few spare moments of time to help curious or confused users. In this monthly feature, we highlight some of the top voted questions and answers made since our last update.

• ● Why does the importmulti RPC not support zpub and ypub? Fontaine asks why Bitcoin Core’s importmulti RPC supports the xpub public key derivation format but not ypub or zpub formats. Pieter Wuille explains that the xpub format was specified in BIP32 and was used to generate P2PKH addresses types which were the most common at the time. Pieter goes on to describe Bitcoin Core’s output script descriptors as a more sustainable approach to address generation.

• ● Is Bitcoin PoW actually SHA256 + Merkle tree generation? User ascendzor wonders about the consequences of miners needing to recompute the merkle root as part of proof of work mining and why the nonce cannot be increased to 64 bits. Pieter Wuille explains that not only is the overhead in computing the merkle root negligible, but an increase in the nonce size would require a hard fork.

• ● What is the difference between bytes and virtual bytes (vbytes)? Ugam Kamat and Murch note the differences between virtual size (vsize, denominated in vbytes) and size (denominated in bytes) and go on to explain the block weight limit and segwit discount.

• ● To what extent does asymmetric cryptography secure bitcoin transactions? RedGrittyBrick and Pieter Wuille explain that while asymmetric cryptography was not used in Bitcoin to prevent a bug or attack, it is the mechanism by which an individual’s coins are secured from others.

Notable code and documentation changes

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

• ● BIPs #800 updates BIP174 to note that wallets must only sign with the signature hash (sighash) type requested in a Partially Signed Bitcoin Transaction (PSBT) if the wallet considers that sighash type to provide acceptable security. Most wallets dealing with common transaction types should reject anything besides SIGHASH_ALL.

• ● BIPs #766 assigns BIP155 to the addr v2 proposal described in Newsletter #37. This proposal will allow nodes to share their Tor hidden service (onion) version 3 addresses with each other, as well as provide compatibility with other network address protocols.

• ● BIPs #643 adds BIP301 about blind merge mining as previously discussed on the Bitcoin-Dev mailing list in late 2017. Blind merge mining is intended to be used with the type of decentralized sidechains called “drivechains”. Similar to other decentralized sidechain proposals, drivechains have SPV security, meaning miners with enough hashrate are able to steal funds from the users of the sidechain.

• ● C-Lightning #2842 triggers a reconnection attempt instead of failing a channel when a “sync error” is received from a channel peer. This is a deliberate decision to deviate from the LN specification because LND nodes seem to be generating this error quite frequently and C-Lightning maintainers are worried that if C-Lightning properly fails channels “at this rate, we risk bifurcating the network.”

Footnotes

1. For example, here we query a seeder for nodes that have the service bits enabled for complete chain history (NODE_NETWORK) and bloom filter support (NODE_BLOOM):

   $ python3
   >>> NODE_NETWORK = 1 << 0  ## Original Bitcoin 0.1 protocol
   >>> NODE_BLOOM = 1 << 2    ## BIP111
   >>> hex(NODE_NETWORK | NODE_BLOOM)
   '0x5'
   
   $ dig x5.seed.bitcoin.sipa.be
   [...]
   
   ;; ANSWER SECTION:
   x5.seed.bitcoin.sipa.be. 3118	IN	A	84.77.52.0
   x5.seed.bitcoin.sipa.be. 3118	IN	A	165.227.110.22
   x5.seed.bitcoin.sipa.be. 3118	IN	A	52.163.63.49
   [...]
   

   ↩