Re: Estranged Core Developer Gavin Andresen Finally Makes Sensible 2MB BIP Proposal!

This is all complete nonsense. Are you really suggesting that nodes with differing consensus rules would "re-align" with one another? Why? There is nothing enforcing consensus between 2mb and 1mb nodes.

The picture is silly -- consider another common situation, post-rules activation:

Group C (2MB miners) finds and publishes Blocks 400,000c, 400,001c and 400,002c (all > 1MB) at 12:05-12:15, making it the longest valid chain by 3 blocks for all nodes enforcing 2MB rules. Groups A or B (1MB miners) finds and publishes Block 400,000a at 12:16.

Now, why would nodes enforcing 2MB rules orphan any of Blocks 400,000c-400,002c? They are valid blocks built on the longest valid chain by timestamp. Block 400,000a was found well after Block 400,000c. There is no reason for 2MB nodes to "re-align" with Groups A or B. To 2MB nodes, Block 400,000a is a stale block and nothing more. 2MB nodes will continue to recognize blocks built on top of 400,002c as valid.

Meanwhile, Blocks 400,000c-400,002c break the consensus rules enforced by 1MB nodes. So for them, the next valid block on the longest valid chain is 400,000a. 1MB nodes will continue to recognize blocks built on top of 400,000a as valid.

When you break consensus, there is no incentive for nodes with different rules to "re-align" their blockchains. Miners running one set of rules or the other will continue to build on the longest valid chain. If a different chain is the longest but is built on top of invalid blocks, they cannot be re-aligned. Miners running incompatible software will continue to mine on top of separate chains, and so on, and so forth.

Having the 2mb setting "as a buffer" does nothing to avoid orphans or headaches; it could help to trigger a hard fork that results in multiple blockchains built on top of differing consensus rules.

maybe worth you looking how orphans work
then realise that 2mb miners can accept blocks below 1mb aswell..its a 0 to 2000000... not a 1000001 to 2000000 rule

so at the 400,002 where the <1mb block gets a block solved first.. the 1mb block wins because it solved a block first (wins the block height race)
(i wrote it twice for emphasis)

and when it sees the chain of previous blocks of that winning block.. they do not contain any over1mb blocks.. so then that causes C to orphan the chain to realign..

please learn about orphans

Please don't tell people to learn how things work when nearly everything you've said is factually incorrect.

Sure, 2MB nodes can accept blocks smaller than 1MB. So what? That a 900kb block found 3 blocks later is valid doesn't mean nodes will orphan the 3 valid blocks that came before it based on block height.

Why would the 1MB block (according to 2MB nodes) win the block height race? Group C mined Blocks 400,000-400,002 before Group A mined Block 400,000. 2MB nodes recognize Blocks 400,000-400,002 as valid. Why would they possibly orphan them? Because some other software version disagrees? LOL.

Group C won't orphan any blocks because they have built on the longest valid chain, according to their 2MB rules and according to block height. And that's how a chain fork occurs.

and thats only the assumption that the C miners ALWAYS and FOREVER miner faster.. (which you failed to take into the equation, processing time. propagation time, etc.)

but with all that said my point is that there is a risk of orphans. and so miners are not going to risk adding more data to blocks and risk the extra few milliseconds of propagation time by doing so. if their HARDER work gets orphaned, even if there is a setting to allow them to work harder, they wont do it unless they know its safe to.

so even at 70% magic number.. miners wont automatically push forward making their life harder and riskier.. they would wait until conditions are better and that extra limit will just sit as a buffer for when things are BETTER THAN THE MINIMUM CONSENSUS.

again. they wont jump forward as soon as the minimum consensus is reached. its too risky.. the minimum consensus is just a wet fish slap in blockstreams face to finally get their act together if they havnt already, because its a signal that miners may soon start pushing harder. its not a signal for miners to force the issue. just a signal that blockstream should do something because miners may move forward.

again
i would say that 50% is a amber warning for blockstream to do something.(human decision to make some code) and 70% is a flashing red light. and even after the 28 days if blockstream have ignored the warnings. then miners still wont automatically jump forward that instant. they will wait till its safer(im presuming a 90% safety decision to push forward.). so if and when miners finally do move forward, the only people to blame are blockstream for being left behind because at that point they would have lost any considerable hashpower to be able to keep up with the blockheight and so that would be the fault of blockstream for not acting on the warnings.