<p>No, all clients will be compatible until the HF and will mine one chain.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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).</p>

<p>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.</p>

<p>As well as two variables that actually enforce the hardfork changes (increase the block weight settings):</p>

<p><code>MaxBaseBlockSize</code> and <code>MaxBlockWeight</code>.</p>

<p>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.</p>

<p>So, what does this mean for "blocksize" and throughput in the real world?
With Core 0.14.1 and SegWit2x softfork:</p>

<pre><code>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.
</code></pre>

<p>With SegWit2x 2MB hardfork:</p>

<pre><code>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.
</code></pre>

CC BY-SA 3.0
2017-06-22T11:56:03.377Z
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?
Harry Pillsbury
CC BY-SA 3.0
2017-06-22T11:29:25.250Z
2017-06-27T01:41:31.317Z
2017-06-27T01:41:31.317Z
user51971
<p>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.</p>

<p>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?</p>

CC BY-SA 3.0
2017-06-22T04:14:01.047Z
What do you mean by nitwit proposal?
Nick ODell
CC BY-SA 3.0
2017-06-22T08:56:00.810Z
Do you mean UASF or Segwit2x?
MCCCS
CC BY-SA 3.0
2017-06-23T05:46:08.827Z
Hello 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
<blockchain-fork><segregated-witness><segwit2x>
What is impact of the possible nitwit fork on August 1? Will it double the coins I have?
Harry Pillsbury
# What is impact of the possible nitwit fork on August 1? Will it double the coins I have?

(Asked by: username_0 on 2017-06-22)

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?

**Tags:** blockchain-fork, segregated-witness, segwit2x

> **Comments:**
> **username_1**: What do you mean by nitwit proposal?  
> **username_2**: Do you mean UASF or Segwit2x?  
> **username_3**: Hello 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.  

---

## 1 answers

### Answer by username_4 on 2017-06-22. Score: 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.

```

> **Comments:**
> **username_0**: 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?  

---

