Hardfork lock-in period
hardforkmatters opened this issue · comments
Hello. Why not to use BIP91 method for hardfork?
My vision:
Hardfork lock-in period occurs 2016 blocks before 494 784 block. After lock-in, we reject every block from non-BTC1 miner client AND/OR without some flag/bit.
What is out goal? Consolidation. So there will be no pool with populist voting like sluch pool.
Bitcoin community will be able to prepare for hardfork within 2016 blocks. This helps prevent chain-split and any panic.
@jgarzik Why not? Maybe deploy client with --hardforklockin optional flag?
Best part about this? "scluch pool". Carry on.
How to avoid (possible) sabotage - it's all about it. Nothing more.
S2x hard fork consensus can become achieved by simple financial motivation.
For example, we just change obvious flag "NYA" to "S2X" in next release.
This will point, that NYA's hard fork isn't part of roadmap anymore, because it's fact since now.
All btc's chain explorers will show support level of "S2X".
For example, 15% within first 48 hours (the most greedy and hardfork-aggressive pools).
IMHO, at least next 10% will join them because of moving "Overton window". And because of greedness and/or financial caution.
In this place, my aggressive initiative will be close to psihological 30%. Maybe in mid-October.
After that, more and more users, node holders and, of course, miners will join us with growing speed, because of understanding fact of our unavoidable success (and financial caution).
"Success" means splitless guaranteed hard fork.
What can be better for all community?
Main motivator is automatic lock-in 2016 blocks before 494 784 block.
No threshold of "S2X" support should be specified, coz of this my BIP is a chance for peaceful hard fork without splits.
For example, if this chance (s2x flag support) is ~55% - This is much more better, than undefined chance below 20% as of for now (split almost guarantieed). Why anybody didn't see this?.. This BIP is a hope, biggest chance as it can even be. Markets love hope.
@hardforkmatters Maybe write the code as a PR?
@AllanDoensen You're right, that's straightest way. But my skill isn't good enough yet.
There already exists a PR for this #64.
It was closed as orphaning non-signalling blocks will simply lead to false-signalling.
This problem sounds realistic. But it can be solved, theoretically.
Solution is insane, but it will be able to determine mining client.
What if we build-in the code, which will be incompatible with Core client, but legal in chain?
For example, we could generate CRC32(current block hash AND/OR prevous valid BTC1's blocks+something else) and put this CRC32 HEX to version (or anything else) of each new block. We need to verify CRC32 of previous block(s) on next height during mining: if the data is incorrect - previous block(s) will be orphaned.
That's a miner-enforced soft-fork. Non-compliant miners can apply a patch to apply the specific behaviour and still not follow the fork. Miners aren't stupid (whichever side of the split they're on), they'll take appropriate steps to protect their revenue.
If you want to force everyone to follow the fork you can do much better than signalling requirements:
- The only valid block to generate is an empty block with 0 miner reward.
- In the coinbase transaction there must be the hash of the actual merkle tree which points to a new transaction tree with up to 2MB of transactions.
- This means old nodes still follow the chain (but no transactions ever seem to confirm for them).
- Upgraded nodes see the actual 2MB block.
This is the hard-fork-as-a-soft-fork approach. There's good reasons not to do this (it's a huge hack, breaks SPV wallets until they upgrade, etc.) but if you want to actually force people to follow the chain it's how you do it.
The problem is that even that technique won't work in the long run because people who don't want to follow that chain can then soft-fork in incompatible rules of their own and break off.
It's flat-out impossible to stop people from splitting off if they're determined.
@christophebiocca Hmm, interesting. Indeed, my skill is not enough, cuz of I didn't think so deep.
But my intuition insists:
There must be intermediate solution, some kind of combination of discussed ways, without breaking SPV.
Just need a simple thing, that nobody will use as a patch. Maybe even politically unaccaptable. IMHO, that's enought for sabotage prevention.
We can game this method and delay the upgrade. NACK
what you mean by there could be no fork "There COULD be no fork at all...". I believe dates were set and we are heading to it, is it not ?
Delaying will simply reject proposal and its implementation as latest "core" nodes already disconnect from non-compliant ones. Dont you agree ?
Core can change their minds at witching hour (or any other time) and go 2x. There may be no fork whatsoever. Making assumptions that Core will follow ~%10 of the net hash rate is not wise.
Nevertheless this "lock-in" can be gamed and delay deployment so again NACK.
Delaition is unacceptable. We need to gather oneself together. That's what I pointed out.
"Core can change their minds at witching hour (or any other time) and go 2x." - Ha-Ha. Or they could turn current "cold war" to the real battle. And I adviced to prepare code for "Empire Strikes Back".
Alas, would need a time machine to properly set up a HF lock-in and activation period a la BIP 91, even 21 days ago when this was opened. The ship has sailed, as it were.