0
If the Nitwit proposal is activated at the end of July then as I understand a hard fork will occur because miners and nodes that continue using the old software will generate blocks in the old format, but those blocks will be ignored by nitwit clients, and vice versa. So, basically there will be two chains.
If that happens and I transfer some coins, how is it decided which chain the transaction occurs on? Can I double spend my coins, once on each chain?
2
No, all clients will be compatible until the HF and will mine one chain.
If SegWit2x reaches 80% support during a 336 block signaling period, it means that the SegWit softfork locks in and will activate another 336 blocks later on all SegWit2x clients. Those clients will then, upon SegWit activating, automatically turn on bit1 signaling to assist the Core BIP141 clients in reaching the 95% threshold they require for their own SegWit activation.
Then, exactly 12,960 blocks (~3 months) after SegWit activates on the SegWit2x clients, the SegWit2x 2MB hardfork will automatically activate on any/all nodes that are still running SegWit2x at that time.
That hardfork, if it maintains 75+% of the hashpower at the time of its activation, will force every other node in the entire network to update to SegWit2x (or SegWit2x compatibility), or be forked off the network.
As a normal holder, you can just sit back and watch all of the above. You may wish to pay attention to the SegWit2x compatibility of your chosen wallet, and adjust accordingly, but otherwise you're mostly safe throughout this entire ordeal. (You can always import your keys into a SegWit2x-compatible wallet later).
If you run a node, however, you will soon need to decide whether or not to switch it over to SegWit2x before, or immediately after, the hardfork. The code for the SegWit2x hardfork is actually rather simple. It involves two fairly straightforward variables that act as activation triggers (~3 months, or 90x144 blocks, after SegWit activates): BIP102active and fSegwitSeasoned.
As well as two variables that actually enforce the hardfork changes (increase the block weight settings):
MaxBaseBlockSize and MaxBlockWeight.
That's it. There are a few other small changes to other lines of code that are meant to account for the signaling and size changes, as well as a few new tests, but everything else pretty much stays the same as Core's 0.14.1.
So, what does this mean for "blocksize" and throughput in the real world? With Core 0.14.1 and SegWit2x softfork:
Base Size = 1,000,000 bytes.
Max Block Weight = 4,000,000 bytes.
Real-world block size results = ~2MB.
Transactions: 4,000 - 5,000 per block.
With SegWit2x 2MB hardfork:
Base Size = 2,000,000 bytes.
Max Block Weight = 8,000,000 bytes.
Projected real-world block size results = ~4MB.
Projected Transactions: 8,000 - 10,000 per block.
So, just to clarify: will the new stuff try to block the old stuff by saying their transactions are bad (vote against them), or will it just ignore old transactions types? If it ignores them, then the old clients could vote to confirm them, right? If it votes against them, then the old transactions basically get stuck forever in the mempool and never get confirmed. Which is the case? – Tyler Durden – 2017-06-22T11:56:03.377
1What do you mean by nitwit proposal? – Nick ODell – 2017-06-22T04:14:01.047
1Do you mean UASF or Segwit2x? – MCCCS – 2017-06-22T08:56:00.810
1Hello Tyler Durden, the situation is opaque enough without using obfuscating terms. Could you please edit your question to call things by their name for clarity's sake and kindly check the politics at the door? The actual question is plenty interesting without opening another stage for the schism to dance on. – Murch – 2017-06-23T05:46:08.827