Todays newsletter continuous with chapter 1 from Bitcoin: A Work in Progress.
This weekend I experimented with more Podcasting 2.0 stuff, inspired by the latest Bitcoin Review episode featuring the Podfather Adam Curry. I installed Castopod, which is a self hosting solution for podcasts. I then cloned the entire archive of Bitcoin, Explained. Don’t update your RSS feeds just yet, but you can take a look at podcast.sprovoost.nl/@nado. Hey, does that look like a Mastodon username? Yes!
I also shipped an update to nthKey. Nothing visible, just keeping libwally up to date.
Last week we covered bech32, the new address format introduced with SegWit. Well, it turns out…
In 2019 it was discovered that, if a bech32 address ends with a P, then if you accidentally add one or more Qs to it, it still will match the checksum, and you won’t be told there’s a typo. In turn, your software would think it’s correct, you’d be sending money to the wrong address, and it would be unspendable, as we explained above.
The good news is that bech32 was only used for SegWit, and SegWit addresses were constrained — they had to be either 20 bytes or 32 bytes. So luckily, if you add another Q to a 20- or 32-byte address, then its length would be invalid. Your wallet would detect this and refuse to send coins. A similar size constraint was considered for Taproot, but thanks to the solution below, it wasn’t needed. A flexible length makes future improvements to Taproot easier.
To fix this bug, a new standard called bech32m was proposed (BIP 350). It’s actually a very simple change. It adds one extra number to the bech32 checksum math, which then makes sure no extra characters can be added without causing an invalid checksum.
The new standard is only used for Taproot and future addresses. For SegWit, nothing changes, because it’s already protected by the 20- or 32-byte length constraint. At the time of writing, most wallet software supports the new bech32m standard.
As an aside, Pay-to-Public-Key-Hash (P2PKH) was thought to be safer against quantum attacks, because you didn’t have to say which public key you had. The downside was that the hash consumed more block space — but this wasn’t an issue back then, because blocks were nowhere near full.
Many people are worried that quantum computers will eventually break the security offered by Bitcoin’s cryptography, allowing future quantum hackers to steal coins, potentially crashing the market if they steal millions.
The problem is that, despite widespread P2PKH use, there’s 5 to 10 million BTC out there for which the public key is already known. The irony is that because so much BTC is already vulnerable to quantum theft, there’s no use trying to protect the rest. Even if your coins won’t be stolen, they’ll be worthless from the price crash.
The (un)likeliness of such quantum troubles in the near future, as well as possible countermeasures, is explained in two What Bitcoin Did podcast episodes — with physicist Stepan Snigirev and mathematician Andrew Poelstra.
Block space is much scarcer now, so not having to put public key hashes on precious block space would save users fees. This is why in the new Taproot soft fork, Bitcoin addresses are P2PK again (rationale) Note that the use of Taproot addresses isn’t mandatory, so if you don’t agree with the above reasoning, you can simply choose to not use Taproot.
This is the end of chapter 1. You can also read it as a blog post.