Status update #2 on Mastering Bitcoin, 3rd edition: I sent my editor the first draft of Chapter 9 about transaction fees. This chapter consists of 90% new material. It describes the basic principles of Bitcoin's fee (block space) market, fee estimation, fee bumping (both CPFP and RBF, with a infobox about opt-in RBF vs full RBF), transaction pinning, CPFP carve out, and package relay. Sections from the previous edition's Transactions chapter about fees being implicit in a transaction and (anti) fee sniping are moved to this chapter.

This is the last planned major change from the 2nd edition, so I'm hoping to finish the remaining chapters pretty quick.

What prevents an image server from adding an identical-appearing watermark to an alternative image?

I'm not a "screw you" kinda guy, so when I couldn't write short, I usually wrote nothing at all. Sometimes, in retrospect, that was a good call, but it other cases it just meant that misinformation stayed out there or it received a "screw you" or other unhelpful response from someone else.

I think brevity should be encouraged but not required.

Unfortunately, with stock BIP158, you can't avoid monitoring for reused addresses until you've spent all the coins you want to spend that you previously received to those addresses. That's because BIP158 "basic" filters use the output scriptPubKey to track both receiving bitcoins and spending them.

For example, Alice receives some bitcoins to bc1pfoo in a transaction in a block. The filter for that block commits to OP_0 foo.

Later, Alice spends that transaction output. The filter for that later block also commits to OP_0 foo.

If, in between those two blocks, someone else sent bitcoins to bc1pfoo, then the filter for that block would also commit to OP_0 foo. It wouldn't be possible for Alice's wallet to determine whether the filter made that commitment because new bitcoins were received to bc1pfoo or because of a spend of the bitcoins she had previously received.

It depends a lot on the threat model. Let's consider two scenarios:

1. Mallory is monitoring all traffic to a given IP address (no Tor, or Tor is completely broken) and wants to learn which outputs it controls. Every transaction downloaded by that IP address which doesn't belong to its wallet increases the anonymity set of the transactions which do belong to that IP addresses's wallet. Because BIP157/8 involves downloading whole blocks (typically a few thousand transactions), it would create decent-sized anonymity sets even if there was never a false positive; adding the occasional false positive block just improves that.

By comparison, Bitcoin Core is like having a 100% false positive rate; now the anonymity set is every transaction in the entire best block chain.

2. Mallory knows a Bitcoin address and wants to find the IP address of the wallet controlling that Bitcoin address (again, no Tor). If Mallory has the ability to surveil IP addresses that the wallet might be using, she can spent a tiny bit of money to that address to get the wallet to download that block. Many other wallets will also download that block, either because they had transactions in it or because of the false positive rate, so that's the initial anonymity set. Mallory can then send another tiny bit of money to the address. The wallet she's interested in will download that new block but many of the other wallets which previously downloaded it won't (they didn't have a tx in that block or it wasn't a false positive for them). This shrinks the anonymity set. Each time Mallory sends a bit more money to the address, the anonymity set shrinks further, until she finds the IP address.

By comparison, Bitcoin Core is immune to this attack. It downloads every seemingly-valid block unconditionally.

I disagree about there not being any privacy benefit. Every Wasabi instance that's paired with a local node performs exactly the same non-coinjoin/non-broadcasting network operations, making it impossible to use network activity to determine which instance received which transaction outputs. (This is called information theoretic perfect privacy.)

Wasabi instances that use BIP157/8 compact block filters each perform different network operations depending on their transaction history. These operations are performed over Tor, with Wasabi frequently rotating network identities, which defeats simple attacks---but is still far from perfect. If the threat model includes global passive surveillance, record-now-decrypt-when-post-quantum surveillance, crypto or protocol vulnerabilities in Tor or Wasabi, or other threats, then it may be possible to identify the IP address of a wallet controlling a certain address.

More importantly "it only saves a bit of bandwidth and storage" ignores what is, to me, the primary benefit of running a full node: the assurance that the bitcoins you receive have all the characteristics necessary to make them easy to sell in the future, specifically that every previous transfer of those bitcoins was valid according to the consensus rules and that all of those transfers are documented on the block chain currently known to have the most proof of work.

What's anti-klepto?

Want? Yes. Should? Probably not. Keeping on top of Bitcoin and LN is already more than full time some weeks (including this week, alas).

I'd definitely read that.

I think that's kind of an interesting dynamic. One one hand, if you have >50% of hash rate in the US, then you have a ~$5 billion/yr industry that at least some politicians are going to want to keep happy. On the other hand, if the censorship is egregious, either the value of BTC is going to drop (contracting the industry) or some users are going to switch to a new PoW function (possibly decimating the industry). It's kind of the same dynamic you get from regulating industry in general, e.g. raising local minimum wage, but the feedback loop in Bitcoin is currently much faster than most industries, so the same politician who's in power when the problem is created is likely to still be in power when the problem manifests.

❤❤❤

I had the same thought when reading that book, although I rather enjoyed the rest. But during the Money chapter, I was thinking, "nah, I like Szabo's theory way better".

Status update on Mastering Bitcoin, 3rd edition: yesterday I sent my editor the first draft of Chapter 8 about digital signatures. In addition to small revisions from the second edition about ECDSA and sighashes, the draft now describes schnorr signatures, scriptless multisignatures, and scriptless threshold signatures. Plus there's now a description of the major differences between ECDSA and schnorr signatures. If I finish the remaining 6 chapters early, I hope to come back and add some information about signature adaptors.