I thought it might be important to write up a quick explanation for how SegWit2x actually works, as there seems to be a lot of confusion on the matter. I have a fairly decent understanding of the actual SegWit2x code itself; so, If anyone has any questions, please don't hesitate to ask.
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. If you run a node, however, you will eventually 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.
@Zero: spoko, możesz sam sprawdzić kod i powiedzieć, gdzie się myli:) imo to nie ma znaczenia, który to subr, jeśli gościu omawia tylko techniczne strony bez oceniania, co lepsze.
@emjot86: wiesz że to się nie dzieje tak że chłopaki maja tam maxblock=1MB potem zmiana maxblock=2MB ;D *** tam w tym kodzie masz kilkanaście tysięcy linijek programu od zarządzania pamięcią itp. to nie będzie tak ze gość zmieni cos w kodzie i będzie gotowe na jutro Ci od seg2MB nie sa świadomi. Segwit był szlifowany z rok po zaprogramowaniu :) a oni chcą zrobić zmiany w parę tygodni i HF - deweloperzy core to
@WeselnyGiermek00: ale segwit wejdzie, więc to już coś. Nie twierdzę, że zmiana na 2mb jest łatwa, w końcu to hard fork. Czytam komentarze, że zapowiedź 2mb to tylko żeby chinole mogli wyjść z twarzą i i tak tego nie wprowadzą :) Wojna trwa, ale widzę, że zamiast walić atomówkami obie strony próbują jeszcze dyplomacji.
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.
#bitcoin
potem zmiana
maxblock=2MB ;D
***
tam w tym kodzie masz kilkanaście tysięcy linijek programu od zarządzania pamięcią itp. to nie będzie tak ze gość zmieni cos w kodzie i będzie gotowe na jutro Ci od seg2MB nie sa świadomi.
Segwit był szlifowany z rok po zaprogramowaniu :) a oni chcą zrobić zmiany w parę tygodni i HF - deweloperzy core to
@emjot86: