A misunderstanding can travel halfway around the world while the truth is putting on its shoes.
Here is the response
I wrote on reddit:
Limitation of the twitter medium I assume there. I don't know why he's invoking "blockstream" there.
I asked Jeff on IRC what specifically the 75% that was in his document meant:
13:44 Technical question, it's unclear to the writeup how exactly you suggest miners signal their new size preference? are you thinking that mine
rs express a preferred size in their blocks, and then the 75-th percentile size is used? (subject to the 2x limit) ?
...
13:50 What made you go for 75%?
...
13:52 75% = political science. 3/4 majority.
...
14:09 as far as the actual mechenism (which I don't see in the BIP); what I'd guess is that each block would express a preferred limit in the coinbase, next to the height, and then at the update period those limits would get processed? e.g. taking the n-th percentile?
14:10 (if that detail is in the bip, I'm missing it)
...
14:14 Anyway, on the BIP 100, basically the floor (least) of the range of most popular miner suggested sizes
14:14 "we all agree on this floor"
14:15 jgarzik yea, if it took all the sizs, sorted, and then discarded 25% of the smallest ones, then took the smallest remaining size, it would accomplish that.
14:16 size can decrease too, with 1MB absolute minimum.
14:16 though maybe a number different than 75/25 would be good, I should talk to petertodd and see if his position would be changed if, say, it were 90%/10%. Basically if you're below 5% hashpower you're not even getting a block per day on average, and so you couldn't even be doing much to prevent censorship.
14:18 But e.g. should be we changing how the limit works slightly, e.g. making the 'size' include the change in the utxo size as I'd proposed before? so that the limit actually reflects the real costs in the network; .. absent something like that fees will never peanlize costly behavior there.
14:18 nod - IMV tweaking those constants are easy while getting us past the 1MB hard fork
14:18 & addressing governance are the hard parts
14:19 agree RE UTXO - economically signaling those costs is important
I believe this is the entirety of my conversion with Jeff on the subject. (I've removed many interspersed comments because IRC usually bifurcates into multiple threads of discussion due to latency; but I believe they are unrelated to this topic). AFAICT, I never suggested 20% but rather suggested a sensible meaning for what a 75% threshold might mean in his scheme, which to my eyes was under-defined but might have already meant that.
I don't think there is anything wrong with 20% as things go; though the main limitation in BIP100 (assuming any of the under-specified parts are filled in with things I find unobjectionable) is that it addresses only miner-vs-miner incentives issues, and even then only under assumptions about hashrate distribution which are currently untrue (e.g. right now less than one percent of the miners have >>50% of the hashrate, so BIP100 is basically a blank check to those few parties up to the 32MB limit).
Jeff's stated view is that users can be protected by exiting Bitcoin if miners are not acting perfectly, but there is incredible friction around markets (e.g. solution via exodus guarantees losers)-- "sell all your bitcoins and go use something else, is a really weak threat, in general. Because of the weakness of the threat I don't think this is a reasonable first-resort mechanism for assuring the security of the system-- I think we've already seen it disproved in practice, and under that argument, e.g. we could just give miners the ability to print infinite bitcoin, steal arbitrary coins, etc.