pull down to refresh

122 sats \ 7 replies \ @oomahq 16 Jan \ parent \ on: The asymmetric advantage of a BIP-110 fork bitcoin

Yes. The pre BIP-110 chain can always be wiped out again and again even if it gets ahead momentarily, while the BIP-110 chain cannot be wiped out when it falls behind.

To neuter this effect a counter-softfork would need to be deployed. Thence the lowest friction to a miner is to go with a soft fork.

write
preview
252 sats \ 1 reply \ @Scoresby OP 16 Jan

Same energy:

It seems to me that this is all predicated on having a majority of hashrate. My frustration has been with an argument that goes: "We don't need a majority of hashrate because we will eventually get a majority of hashrate."

reply
412 sats \ 0 replies \ @Murch 16 Jan
"We don't need a majority of hashrate because we will eventually get a majority of hashrate."

That’s it: you have distilled the essence of the RDTS fallacy perfectly.

reply
0 sats \ 4 replies \ @Murch 16 Jan

That’s unnecessary if support for RDTS remains as marginal as expected. Miners could also use invalidateblock on the first block of the RDTS chain to ignore the RDTS chain permanently; no fork necessary.

reply
21 sats \ 3 replies \ @oomahq 17 Jan

Well, what you just described is a fork. The counter-softfork I alluded to, actually.

reply
0 sats \ 2 replies \ @Murch 17 Jan

Fair enough! I thought you meant to express that it required a coordinated software update with a consensus rule change.

reply
2 sats \ 1 reply \ @oomahq 17 Jan

Running invalidateblock in the manner you described is a consensus rule change (soft fork, introduction of a new rule) that targets RDTS, so.. Yes, that's what I meant.

reply
0 sats \ 0 replies \ @Murch 17 Jan

Yeah, that’s why I said “fair enough”.

reply