Quote from: franky1 on March 05, 2017, 03:48:02 PM

Quote from: Senor.Bla on March 05, 2017, 03:03:04 PM

Here is the part where i'm confused. The argument goes like this.

1. We have dynamic blocks and there is a 2.5MB blocked mined.

2. Node A sees it as invalid and drops it, but node B and C accept it as well as all Miners. Bitcoin will built on this block and Node A will have to accept it or fork. Right?

Now we have the same scenario but Nodes A and B (the majority) rejects the block and only Node C and all miners accept it. Wouldn't this mean we would still built on top of this 2.5MB block and lose 2 nodes? It's an invalid block to the majority of Nods,

3. but they have no miners behind them, so who is going to mine for them? Wouldn't this situation be technically considered as a fork?

1. thats where your skipping to step 3..
three step process based on your 2.5mb scenario
step one
92% of nodes say 4mb is fine...(reality is a mix of more than 4mb to lets say 16mb)
1% of nodes say 3.6mb is fine
1% of nodes say 3.3mb is fine
1% of nodes say 3mb is fine
5% of nodes say 2.5mb is fine...
^ the nodes 'consensus.h limit'

but ALL nodes then have a policy.h limit too which is at 2.5mb

pools too have 2 limits. they see the 95% 2.5 limit and that becomes the POOLS consensus.h limit (2.5)
pools then have the policy.h limit where they make blocks at 1.001mb to test the water, see the orphan risk rate. if fine they then move to 1.002mb and it grows from there..
DO NOT think pools will jump straight to 2.5 or 4mb instantly

step two.(2)
as the blocks get to 2.5mb. orphans start to occur(due to A). but at an acceptable 5% risk tolerance. meaning the 5% (node A) rejects and has to choose to either move up its consensus limit to allow the policy limit to have some wiggle room or be left unsynced with the network.(3)
pools then decide if they move their limit up to 3mb consensus.h and try 2.6mb policy.h (depending on orphan risk)

step three.
by nodeA continuing to run but not moving the limit.. if blocks got to 3mb.. the orphan risk goes above 5% and pools start to get worried and stop growing. because network consensus is no longer at or below 95% tolerance

by nodeA continuing to run and moving the limit.. if blocks got above 2.5 but only to 3mb.. the orphan risk is below 5% and pools continue
by nodeA not running.. if blocks got to 3mb.. the orphan risk is below 5% and pools continue

3. defining your understanding of "fork"
the node if not moving its limits. is just going to continue rejecting blocks(left unsynced) its an ORPHAN EVENT. or it switchs off its node.

by continuing to run but not upping the limit. it and other nodes where by the network goes under 95% would stop pools from growing.

the thing most forget is that there are 2 'limits' not one.

now..
lets imagine there was a pool that separately dcided it wanted to hlp node A by not following the network dynamic consensus. and dropped down to 2mb to mine for node A.
again an orphan event. this time also affecting the pool aswell(2 opposing pools fighting for blockheight of a single chain)

to cause a altcoin (bilateral split) node A and the pool will have to intentionally BAN the other pools and nodes to avoid the orphan game of consensus and then they become their own little network we would probably call 'clams 2.0'

the thing most forget is that even in a soft fork event nodes can ban opposition and cause a bilateral split (altcoin maker). even gmaxwll admits to wanting this to happen for certain reasons

First of all thank you for a better explanation than i could come up with. I do have to miner questions i'm not sure about if i got it right.
1. Regarding step three. Can the node with the lowest consensus.h limit hold back/block the network by not upping the limit while still running?
2. Regarding the bilateral split. Why do the Node and the pool need to intentionally ban the others to become a small network of their own? I thought this happens automatically since they assume they have the longest legit chain.