pull down to refresh

I would suggest that you first address the points @Scoresby raised in the OP, but beyond that for starters:

  • You are wrong about the fork activating immediately upon reaching the threshold
  • It makes no sense to claim that miners should signal late. If they support the proposal signaling early would help build momentum and be less risky.
  • You misrepresent the potential downsides of being on the wrong side of the soft fork attempt

Scoresby's critique assumes that BIP-110 could fail to activate, but it can't. There's no timeout or "failed" state. Mandatory signaling forces lock-in at max_activation_height, regardless of organic support. The chain-split scenarios described rely on minority hashrate activation, but the 55% threshold prevents this.

reply
145 sats \ 0 replies \ @Murch 2h
Scoresby's critique assumes that BIP-110 could fail to activate, but it can't. There's no timeout or "failed" state. Mandatory signaling forces lock-in at max_activation_height, regardless of organic support. The chain-split scenarios described rely on minority hashrate activation, but the 55% threshold prevents this.

Uh… Your own article has table columns that are labeled “BIP 110 doesn’t activate”:

And you see, that’s where you lose me: when RDTS activates, all nodes running RDTS software will start to enforce it. If that covers only a minority of the hashrate, where does the additional hashrate suddenly come from to suddenly make the hashrate of the RDTS chaintip jump to 55%?

If e.g., 10% of the hashrate runs RDTS and participates in the mandatory signaling, the first block not signaling spawns a separate chaintip that with 90% of the hashrate builds block 9× as fast and just leaves the RDTS nodes behind.

reply

I agree with you that it will certainly activate.

I'm wondering why you don't include the scenario where it activates with a minority of hash rate in your matrix.

How does a 55% threshold prevent a minority hashrate activation?

reply