● CVE-2017-18350 SOCKS proxy vulnerability: a full disclosure of a vulnerability in Bitcoin Core versions 0.11.0 (Sept 2012) to 0.15.1 (Nov 2017) was published to the Bitcoin-Dev mailing list. The vulnerability only affects users who have configured a SOCKS proxy to use either an untrusted server or to connect over an untrusted network. Almost all affected versions of Bitcoin Core are also affected by previously disclosed vulnerabilities, such as CVE-2016-10724 (see Newsletter #1 ) and CVE-2018-17144 (see Newsletter #14 ), so users should have already upgraded to Bitcoin Core 0.16.3 or higher.

● Taproot review, discussion, and related information: 163 people signed up for the structured taproot review mentioned in Newsletter #69. Last week they began reviewing the first part of bip-taproot and related concepts, including participating in question and answer sessions with Bitcoin experts who previously contributed to the taproot design.

One question asked was about why taproot allows v1 segwit scriptPubKeys to use fewer or more than 34 bytes—the amount needed for a Pay-to-Taproot (P2TR) scriptPubKey. This seems odd since BIP141 v0 native segwit scriptPubKeys are only allowed to use exactly 22 bytes for P2WPKH or 34 bytes for P2WSH. The response was that fewer restrictions will allow a later soft fork to define other uses for v1 scriptPubKeys with shorter or longer lengths. In the meantime, if taproot is adopted, those shorter and longer v1 scriptPubKeys will be spendable by anyone (as they are today).

This started a discussion among experts about how this flexibility interacts with an issue in the bech32 address encoding algorithm that was reported in May and recently described in detail. Bech32 addresses as specified in BIP173 are supposed to guarantee that up to four errors will be detected in an incorrectly copied address and that only about one miscopied address in a billion that had five or more errors would go undetected. Unfortunately, those calculations were made under the assumption that the length of the copied address would be the same as the original. If the copied address is instead longer or shorter, bech32 can fail to detect even a single-character error on rare occasions.

For existing P2WPKH and P2WSH bech32 addresses, this is very unlikely to be an issue since the restriction that v0 scriptPubKeys be exactly 22 or 34 bytes means that a miscopied P2WPKH address would need to either contain an extra 12 bytes or a P2WSH address would need to omit 12 bytes, meaning a user would need to type about 19 extra or fewer bech32 characters—an awfully big mistake.

But if P2TR is only defined for 34-byte v1 scriptPubKeys and it remains the case that anyone can spend 33-byte and 35-byte v1 scriptPubKeys, then it would be possible for a user to make a single-character mistake and lose all of the money they intended to spend. Author of both BIP173 and the taproot proposal Pieter Wuille posted to the Bitcoin-Dev mailing list some options for addressing the problem and requested feedback on what options people would prefer to see implemented. One option would be restricting all current bech32 implementations to rejecting any native segwit addresses that don’t result in a 22 or 34 byte scriptPubKey. Then an upgraded version of bech32 could later be developed with better detection of inserted or deleted characters.

Many other less critical discussions also resulted from the week’s review of taproot, and discussion logs are available (1, 2) for anyone interested in the discussion details.

In other schnorr/taproot news, Jonas Nick published an informative blog post about a recent major change to bip-schnorr and bip-taproot that reduced the size of serialized public keys from 33 bytes to 32 bytes without reducing security. See Newsletters #59 and #68 for previous discussion of this optimization.