Super Testnet
· 2d
If all miners "obey" BIP110 and start signaling "for" it at height 963648, my app will start rejecting their blocks 1109 blocks later, specifically at block 964757. They can only "obey" URSF-110 by si...
Thanks for that. I'm going to follow up here, but I apologize in advance if it seems like I'm changing the subject a bit ๐. My goal is to clarify the order of events, and I'm doing that to help myself think about exactly when we should reject blocks:
TL/DR: even if 55% signalling is reached in one block, the RDTS rules won't be enforced until at least two weeks later.
Two scenarios, discussed separately:
The simplest of the two scenarios is that it never reaches 55% hashrate. In that case, mandatory signalling starts at 961632. This is the first time that BIP110 nodes can reject blocks that would be acceptable to the conventional (i.e. Taproot) nodes. This doesn't guarantee that a split will happen immediately, the BIP110 miners could be lucky and get the first few blocks, but it is the earliest [in this scenario] when a split could occur. After 2016 blocks in this state, they reach their 'LOCKED_IN' state. From the BIP "The deployment transitions to LOCKED_IN at height 963648 (one retarget period before max_activation_height), then to ACTIVE at height 965664". During LOCKED_IN, further signalling is *not* required, and miners do not enforce any of the RDTS rules on transactions. It's only in the following retarget period, that they finally reject transactions with large OP_RETURNS and all the other banned transactions
So, summararizing the timeline in this "low hashrate" scenario:
- 961632 to 963647: mandatory signalling, i.e. a permanent chain split can occur here.
- 963648 to 965663: LOCKED_IN. No rules applied, not even any mandatory signalling
- 965664 onward. ACTIVE. Blocks are rejected based on whether the transactions follow the rules
The second scenario kicks in if they get 55% of hashrate. Once they get 55%, they don't immediately reject non-signalling blocks, and they don't reject big OP_RETURNs. When they reach 55% (1109+ blocks out of 2016), the *following* 2016 blocks are in the LOCKED_IN state, i.e. no rejection rules applied. After 2016 blocks in LOCKED_IN, then they switch to ACTIVE and reject blocks with large OP_RETURNs