Quote from: Foxpup on July 11, 2017, 09:50:05 AM

Quote from: pooya87 on July 11, 2017, 08:43:17 AM

i fail to understand what the drama is all about.
the fork only needs 1 block to happen, and this one block can be delayed a little bit (a couple of minutes tops) before being mined. then the rest of the blocks building on top of it can be from nearly 0 (empty block with only coinbase tx) to 2 MB.

so where is the problem with that?

There are many problems with that, but the specific problem that caused this particular failure is that the hardfork block was delayed not by "a couple minutes", but by 29 hours, because that's how long it took the miners to realise that the segwit2x client won't actually produce >1MB blocks by default, and hence rejects its own blocks when the fork happens. Roll Eyes

(Many probably still haven't realised the default is broken as it only took a single miner with custom settings to mine the fork block, and since the issue was closed without changing the default behaviour, it's likely to happen all over again if they try to fork on mainnet. Get your popcorn ready.)

that doesn't exactly answer my question though.
go to http://statoshi.info/dashboard/db/memory-pool and set the dates to

Code:

from 2017-07-09 @16:00:50.187
to 2017-07-10 @20:20:54.700

this is the most recent period of time (more than a day) with no spam attack and a clean and nearly generic transactions
you can see what i mean when i say in reality it will take only a couple of minutes to fill the 1MB+ block if not already above 1 MB!

i still find the insisting part on the 2 MB fork this soon very weird and unnecessary because the current 1 MB is enough without the spam attack and with activation of SegWit it will be more than enough. but that is another discussion for another time and another place Roll Eyes