Increase blocksize with soft fork?

[BlackJacky]

Guys,

is it possible to increase the blocksize by a soft fork or only by a hard fork?

Thx

[NorrisK]

As far as I know currently bitcoin core can not accept blocks greater than 1 mb. Because of this, a hard fork is required as people running the older software will not be able to accept bigger blocks.

In softforks, older software will accept the changes made in the newer software, even though they may not themselves support the feature.

Hope this is clear

[BlackJacky]

Yes, but this rule of 1mb has been implemented by satoshi in the first or second year. If this has been impletemented by a soft fork why is it not possible to increase it by a soft fork.

[franky1]

the definitions have been plagued with word twistings and doomsdays.

right now many implementations have a rule to accept 2mb-16mb blocks.. guess what nothing happened.
in 2010-2014
many implementations had 1mb while blocks were only 0.1mb-0.9mb.. guess what. nothing happened.

mining pools will NOT make a block bigger than majority acceptable amount unless majority nodes will accept it.. not due to causing an altcoin. but due to ORPHANS.

yep thats right at the moment there is a 85% risk of orphans because only 15% of nodes have more than 1mb base block rule.

this risk is too high for pools to lose their income.. its not nor ever has been about making an altcoin. just orphan risk.
to create an altcoin the nodes need to literally ban(ip/useragent) themselves from the other side to not even see the other side to not b involved.

ethereum done this with its "--oopose-dao-fork". thus avoiding consensus orphan mechanism and splitting the network by ignoring each other. as oppose to orphaning each other.

once you realise that the base block can grow more than 1mb by having nodes accept more than 1mb. just like they accepted more then lets say 0.2mb from 2010-2016 you will see all these doomsdays about splitting the network are foolish.

the only result is orphans.
the risk of orphans reduces the more nodes that accept the rule.. pools are happy with a 5% risk which is a 95% acceptance.

in short dont think hard fork=intentional split. just think orphan risk and the losing side when the orphan drama subsides simple wont sync to anything.

again pools wont risk it without majority consent.

[AgentofCoin]

Yes, but this rule of 1mb has been implemented by satoshi in the first or second year. If this has been impletemented by a soft fork why is it not possible to increase it by a soft fork.

Most simply:
Softfork means we can change the system WITHIN the confines of the current code or consensus.
There is a single chain and the softfork keeps that single chain in effect.
Hardfork means we need to change the system OUTSIDE the confines of the current code or consensus.
There is a single chain and the hardfork creates two chains.


Since the blocksize limit was originally 32MB when debuted and was lowered to 1MB, it is a softfork.
If we now wish to raise the 1MB limit to 2MB or more, it would technically be a hardfork since it expands upon.

So a softfork can be softforked down again to a lower size, in theory, but to go up, everyone needs to agree
on the new hardforked chain. It is a transformation into a new Bitcoin. If there is no near universal agreement
and a hardfork occurs anyway, there is the potential to have two surviving chains. Two chains is not something
to be looked upon as favorable, but a failure of consensus. Bitcoin functions on consensus, not survival of the fittest.

[franky1]

Yes, but this rule of 1mb has been implemented by satoshi in the first or second year. If this has been impletemented by a soft fork why is it not possible to increase it by a soft fork.

Most simply:
Softfork means we can change the system WITHIN the confines of the current code or consensus.
There is a single chain and the softfork keeps that single chain in effect.
Hardfork means we need to change the system OUTSIDE the confines of the current code or consensus.
There is a single chain and the hardfork creates two chains.


Since the blocksize limit was originally 32MB when debuted and was lowered to 1MB, it is a softfork.
If we now wish to raise the 1MB limit to 2MB or more, it would technically be a hardfork since it expands upon.

So a softfork can be softforked down again to a lower size, in theory, but to go up, everyone needs to agree
on the new hardforked chain. It is a transformation into a new Bitcoin. If there is no near universal agreement
and a hardfork occurs anyway, there is the potential to have two surviving chains. Two chains is not something
to be looked upon as favorable, but a failure of consensus. Bitcoin functions on consensus, not survival of the fittest.

nope.
blue line
soft fork is where there is a change. but it doesnt trigger a new branch, doesnt cause an orphan

first red line
hardfork is a single chain that branchs off and then is cut off when eventually orphaned.
if there is no clear majority. then it branch off often. then get cut off often. its not 2 chains. but multiple branches that get trimmed (orphaned)

intentional split is where the branchs survive ONLY because they ban opposition from connecting to them and ignore/dont receive the orphaning blocks (avoid consensus orphan mechanism) and instead link up in their own clan to a pool(s) that have similar rules.(this is not consensus)

second redline
the 32mb rule is a protocol rule. still inplace and used due to risk of packet loss..
below that there is a consensus rule, nodes have(core default 1mb)
below that there is a policy rule, pools have.(core default 0.7mb, but most pools adjust this to 0.99 immediately)
the policy rule is a pool 'preference' which before 2013 they had it at 0.5 and slowly increased it since.

third red line
if there is no agreement pools wont risk it.. if they are stupid and do risk it, orphans take care of it. in short it wont happen unless there is agreement and eventually, orphan drama or not, there is one chain heading in one direction building ontop of the last.

the only way to make a new network is intentionally banning the opposition to avoid consensus/orphans so that both dont orphan each other out

[DannyHamilton]

- snip -
hardfork is a single chain that branchs off and then is cut off when eventually orphaned.
if there is no clear majority. then it branch off often. then get cut off often. its not 2 chains. but multiple branches that get trimmed (orphaned)
- snip -

Hardforks have multiple scenarios depending on what percentage of the nodes and hashpower choose each set of rules.

Lets say there is a set A of nodes and miners that keep 1 MB blocks as the rule, and a second set B of nodes that allow 2 MB blocks.

Hardfork Scenario 1
=============
An overwhelming number of nodes all belong to set A.
Occasionally set B will solve and attempt to broadcast a block, but other nodes in set B will have a difficult time receiving the block. The block will quickly become orphaned as soon as 2 blocks are mined by set A. All nodes and miners in set A will simply ignore the blocks from set B.  The blockchain created by set A will be the only "real" blockchain, and any miner mining in set B is effectively wasting hash power as they will never get any revenue from that hash power at all.  They are spending money on the principal of the rules they want knowing that they aren't going to actually get anything.

Hardfork Scenario 2
=============
An overwhelming number of nodes all belong to set B.
Set B will have a blockchain that is always longer than the set A blockchain, therefore the set B blockchain will never be orphaned. Since set A will refuse to recognize any blocks from set B as "valid", it will grow its own forked blockchain that can't be orphaned by set B (as far as set A is concerned set B blocks are not valid blocks).  There will be two continuous incompatible blockchains (one for each set). Bitcoins on the set A blockchain won't be very useful (since the overwhelming majority don't recognize those as valid "bitcoin" blocks).

Hardfork Scenario 3
=============
There are many nodes and miners in each set, but neither set has an "OVERWHELMING" majority.
Set B will grow a long blockchain fork that will possibly occasionally be replaced by an even longer blockchain from set A.  Re-orgs dozens (or hundreds) of blocks deep will happen frequently enough to be VERY annoying. If set B can keep enough hashpower (or implement a modification that will reject blocks form set A) then there will be two continuous incompatible blockchains (one for each set). Bitcoins on each chain will be relatively useful (as there are a substantial number of nodes accepting them). There may even be a market that will exchange set A bitcoins for set B bitcoins at some exchange rate.  When spending your bitcoins, you'll need to know if the recipient is expecting set A or set B.

[franky1]

- snip -
hardfork is a single chain that branchs off and then is cut off when eventually orphaned.
if there is no clear majority. then it branch off often. then get cut off often. its not 2 chains. but multiple branches that get trimmed (orphaned)
- snip -

Hardforks have multiple scenarios depending on what percentage of the nodes and hashpower choose each set of rules.

Lets say there is a set A of nodes and miners that keep 1 MB blocks as the rule, and a second set B of nodes that allow 2 MB blocks.

Hardfork Scenario 1
=============
An overwhelming number of nodes all belong to set A.
Occasionally set B will solve and attempt to broadcast a block, but other nodes in set B will have a difficult time receiving the block. The block will quickly become orphaned as soon as 2 blocks are mined by set A. All nodes and miners in set A will simply ignore the blocks from set B.  The blockchain created by set A will be the only "real" blockchain, and any miner mining in set B is effectively wasting hash power as they will never get any revenue from that hash power at all.  They are spending money on the principal of the rules they want knowing that they aren't going to actually get anything.

Hardfork Scenario 2
=============
An overwhelming number of nodes all belong to set B.
Set B will have a blockchain that is always longer than the set A blockchain, therefore the set B blockchain will never be orphaned. Since set A will refuse to recognize any blocks from set B as "valid", it will grow its own forked blockchain that can't be orphaned by set B (as far as set A is concerned set B blocks are not valid blocks).  There will be two continuous incompatible blockchains (one for each set). Bitcoins on the set A blockchain won't be very useful (since the overwhelming majority don't recognize those as valid "bitcoin" blocks).

Hardfork Scenario 3
=============
There are many nodes and miners in each set, but neither set has an "OVERWHELMING" majority.
Set B will grow a long blockchain fork that will possibly occasionally be replaced by an even longer blockchain from set A.  Re-orgs dozens (or hundreds) of blocks deep will happen frequently enough to be VERY annoying. If set B can keep enough hashpower (or implement a modification that will reject blocks form set A) then there will be two continuous incompatible blockchains (one for each set). Bitcoins on each chain will be relatively useful (as there are a substantial number of nodes accepting them). There may even be a market that will exchange set A bitcoins for set B bitcoins at some exchange rate.  When spending your bitcoins, you'll need to know if the recipient is expecting set A or set B.

you scenario1
==========
you say B will have trouble receiving B blocks because A nodes wont relay it. your right so B sticks with A chain, due to high orphan risk. and because A's are acceptable to B. so no harm sticking with A. (ergo network does not implement new rule A rule still enforced)

you scenario2
==========
but you forgot scenario 1 flipped. A will have trouble getting A blocks for the same reason as scenario 1.(majority B isnt relaying A blocks if B blocks have the height) thus leaving A dormant not able to sync. here ill explain

without ignoring B.. A ends up requesting B's blocks because of height and rejecting the data due to size. requesting B's blocks and rejecting. requesting B's blocks and rejecting. endless loop.
(ergo network implements new rule B is enforced A nodes cant sync)

your scenario3
===========
reality is lots of orphans many times a day. branch out, kill off .. branch out, off kill.. branch, kill off.
eventually it settles down presumably to A due to headaches of high orphan risk and knowing A is acceptable to ALL but B is only acceptable to HALF..

but if they were to keep up the orphan fight.
if B attained a higher height. refer to scenario 2
if A attained a higher height. refer to scenario 1
logic dictates a drawn out orphan fight (not a persistent 2 chain fight) results in settling for the most compatible.

think of it this way. if personB can hold 10 oranges but personA can hold 5 oranges.. is there a problem with handing B just 5 oranges if he is not already holding any...... nope.
opposite cant be said for A. they will be dropping the oranges and asking to pick them up. eventually either A shuts down never holding oranges. or B agree's the rule should only be 5 oranges for the benefit of the network (unless B had super majority to not care about A)

its not 2 persistent chains
EG
| |
| |
| |
| |
| |
 \|

but orphans, many branches that get cut off
\ |
*|
 \|
*|
 \|
*|
 \|

summary
======
pools are not stupid enough to risk their time/income on high orphan risk. so your scenarios are meaningless..
if B didnt have majority. B would stick with A rule to avoid wasted time/money.

but i atleast helped by highlighting what would happen if pools did do it without super high majority, due to your thought process of thinking that pools would stupidly do it at lower numbers.

the only way a minority branch of A survives is to intentionally avoid connecting to the opposition and forming an intentional altcoin via banning IP addresses and forming their own DNS seed/network

[AgentofCoin]

Yes, but this rule of 1mb has been implemented by satoshi in the first or second year. If this has been impletemented by a soft fork why is it not possible to increase it by a soft fork.

Most simply:
Softfork means we can change the system WITHIN the confines of the current code or consensus.
There is a single chain and the softfork keeps that single chain in effect.
Hardfork means we need to change the system OUTSIDE the confines of the current code or consensus.
There is a single chain and the hardfork creates two chains.


Since the blocksize limit was originally 32MB when debuted and was lowered to 1MB, it is a softfork.
If we now wish to raise the 1MB limit to 2MB or more, it would technically be a hardfork since it expands upon.

So a softfork can be softforked down again to a lower size, in theory, but to go up, everyone needs to agree
on the new hardforked chain. It is a transformation into a new Bitcoin. If there is no near universal agreement
and a hardfork occurs anyway, there is the potential to have two surviving chains. Two chains is not something
to be looked upon as favorable, but a failure of consensus. Bitcoin functions on consensus, not survival of the fittest.

nope.
blue line
soft fork is where there is a change. but it doesnt trigger a new branch, doesnt cause an orphan

first red line
hardfork is a single chain that branchs off and then is cut off when eventually orphaned.
if there is no clear majority. then it branch off often. then get cut off often. its not 2 chains. but multiple branches that get trimmed (orphaned)

intentional split is where the branchs survive ONLY because they ban opposition from connecting to them and ignore/dont receive the orphaning blocks (avoid consensus orphan mechanism) and instead link up in their own clan to a pool(s) that have similar rules.(this is not consensus)

second redline
the 32mb rule is a protocol rule. still inplace and used due to risk of packet loss..
below that there is a consensus rule, nodes have(core default 1mb)
below that there is a policy rule, pools have.(core default 0.7mb, but most pools adjust this to 0.99 immediately)
the policy rule is a pool 'preference' which before 2013 they had it at 0.5 and slowly increased it since.

third red line
if there is no agreement pools wont risk it.. if they are stupid and do risk it, orphans take care of it. in short it wont happen unless there is agreement and eventually, orphan drama or not, there is one chain heading in one direction building ontop of the last.

the only way to make a new network is intentionally banning the opposition to avoid consensus/orphans so that both dont orphan each other out

I think you are talking about unintentional hardforks that reorg mostly.
When I was answering the OP, I was talking about intentional hardforks.
I believe an intentional hardfork can lead to two surviving chains such as with Ethereum.
I believe an intentional hardfork can either be an "upgrade" or an "attack" based on how its conducted.
I believe not all miners are purely financially motivated and some could be future attackers in waiting.

I'm not a programmer nor as technical as some of you, so some of my terminology and
explanations are not as precise and detailed.

- snip -
hardfork is a single chain that branchs off and then is cut off when eventually orphaned.
if there is no clear majority. then it branch off often. then get cut off often. its not 2 chains. but multiple branches that get trimmed (orphaned)
- snip -

Hardforks have multiple scenarios depending on what percentage of the nodes and hashpower choose each set of rules.
...

Hardfork Scenario 1
=============
...

Hardfork Scenario 2
=============
...

Hardfork Scenario 3
=============
...

Yes, I was really talking about Scenario 2 & 3.

[DannyHamilton]

you scenario2
==========
but you forgot scenario 1 flipped. A will have trouble getting A blocks for the same reason as scenario 1.(majority B isnt relaying A blocks if B blocks have the height) thus leaving A dormant not able to sync. here ill explain

without ignoring B.. A ends up requesting B's blocks because of height and rejecting the data due to size. requesting B's blocks and rejecting. requesting B's blocks and rejecting. endless loop.
(ergo network implements new rule B is enforced A nodes cant sync)

Bitcoin nodes automatically ban connections from nodes that serve them too many bad transactions.  So set A would ban connections from set B and would quickly consolidate on connections only to other set A nodes.  As such, the blocks and transactions would relay and continue to build on each other.

It is not an exact flip of scenario 1.  Set B accepts set A's smaller blocks in scenario 1, but set A will not ever accept set B's blocks.  Set B doesn't ban connections from set A since the transactions are all valid.

In this case, the only incentive to join set B is that set A bitcoins aren't very useful.  A small set of idealists might continue to run their "original bitcoin", but the world would move on without them.

your scenario3
===========
reality is lots of orphans many times a day. branch out, kill off .. branch out, off kill.. branch, kill off.
eventually it settles down presumably to A due to headaches of high orphan risk and knowing A is acceptable to ALL but B is only acceptable to HALF.

That really depends on how close the hashpower is, and how much each hash rate fluctuates over time.  If set B has a noticeable majority of the hashpower for many hours, and then set A ends up with a noticeable majority for a while, then it is entirely possible for set B to get a 100 blocks in the time that set A gets 90 blocks, and then for set A to get another 30 blocks before set B can get another 20.  In that case you'd see a reorg of nearly 120 blocks.

but if they were to keep up the orphan fight.
if B attained a higher height. refer to scenario 2

Correct.  A fork with 2 incompatible blockchains.

if A attained a higher height. refer to scenario 1

Correct.  A sudden reorg back to a single blockchain going all the way back to the fork point.

logic dictates a drawn out orphan fight (not a persistent 2 chain fight) results in settling for the most compatible.

Yes.  In a drawn out fight, as long as set A can EVER get a longer chain, they will always win, and set B will be forced to re-org all the way back to the fork point.  This is why hard-fork changes get set with high thresholds for activation.  No sense in implementing a 2 MB block if you can't get an overwhelming majority of nodes and miners to agree with you first.

summary
======
pools are not stupid enough to risk their time/income on high orphan risk. so your scenarios are meaningless..
if B didnt have majority. B would stick with A rule to avoid wasted time/money.

Correct. And this is why we still have 1 MB blocks, and all significant changes to bitcoin have been pushed through as soft-forks.  Hard-forks are difficult.  They require an overwhelming majority, and getting that many people to agree on ANYTHING is extremely difficult.  There are ideologues and fanatics in the world that are happy to bring down an entire system if they can't get their way.

the only way a minority branch of A survives is to intentionally avoid connecting to the opposition and forming an intentional altcoin via banning IP addresses and forming their own DNS seed/network

Bitcoin already does this.  It is built into the communications protocol.

[franky1]

I think you are talking about unintentional hardforks that reorg mostly.
When I was answering the OP, I was talking about intentional hardforks.
I believe an intentional hardfork can lead to two surviving chains such as with Ethereum.
I believe an intentional hardfork can either be an "upgrade" or an "attack" based on how its conducted.
I believe not all miners are purely financially motivated and some could be future attackers in waiting.

I'm not a programmer nor as technical as some of you, so some of my terminology and
explanations are not as precise and detailed.

hardforks under bitcoin resolve themselves due to orphans/consensus

an intentional split like ethereum (--oppose-dao-fork)
are things that are NOT proposed in any viable BIP and are not a hardfork. they are an intentional split(altcoin maker).

dont think of forks as 2 persistant chains. think of it as one chain that branches off and one limb will be cut off.. once orphan drama sorts out the victor.
any rational and viable fork should use consensus. to reduce orphan risk

a controversial hardfork is when the consensus is low. meaning LOTS of orphans (a tree branches out, you cut its limb. another branches out, you cut its limb. over and over)
again not 2 persistent chains

a consensual hardfork is when the consensus is high. meaning minimal orphans (a tree branches out, you cut the weak limb quite fast and continue the strong limb)
again not 2 persistent chains

a softfork changes a rule without branching, unless there is a bug.. (like the leveldb upgrade in 0.8 that started as soft. but ended up as hard and controversial)
a hardfork has a bigger chance of branching off even without a bug.. depending on node acceptance levels.

however
a controversial hardfork can be seen by the leveldb bug.
yep changing to leveldb was suppose to be a soft upgrade.. but ended up causing a controversial hard fork where there was not a clear majority running 0.7 or 0.8
where by 0.7nodes hung.. and were not syncing..
it was not 2 persistent chains. 0.8 continued on. 0.7 hung and didnt persist.

a decision was made to downgrade back to 0.7 and fix the cause later. thus cutting off the 0.8 limb rather than leaving 0.7 hanging in the unsyncing abyss of screaming out orphans. due to the high orphan risk

if there was a clear majority wanting to move forward. it would be more prudent to get the minority to upgrade..
if there was a clear majority wanting to stay back. it would be more prudent to get the minority to downgrade..

these days. pools wont even do anything unless there is a clear majority acceptance. they want to avoid orphans.(zero reward)
merchants want to avoid orphans(double spends)
fullnodes want to avoid orphans (bandwidth, loops, hangups)

[franky1]

as dannyhamilton has meandered upon.. the term hardfork has lost its meaning. and become an umbrella term that can be many things.

he however twists the scenarios to fit a rhetoric of A (staying low is best) by not staying on track with his scenarios.
by scenario 1
being consensual fork where A wins..

but for scenario 2
he doesnt use consensual fork where B wins.(like a mirror of A)
instead 'suggest' consensual fork where B wins but throws in intentional splits to make it sound bad.

in scenario 3
he doesnt use consensual fork where eventually A wins.
instead he ignores consensual fork and talks about controversial fork and intentional splits.

he should have, to be unbiased done a scenario 4.
consensual B majority, no mention of intentional split

he should have, to be unbiased done a scenario 5.
consensual B majority, A splits

but no he wanted to make B sound bad

but hey its funny seeing them try throwing controversial, consensual and intentional split under one buzzword to scare people. rather than explain the details and differences and what is actually involved.

[franky1]

as for the ban. the ban is not permanent.. its 100 seconds or any amount a node chooses.. (then when time is up the orphans return and wipe out that work of the minority in that time)
also the ban is if someone is intentionally broadcasting a block not requested and doesnt fit rules. (a DDoS)
however usually theres a handshake.
EG A requests data. gets bad data doesnt make B the bad guy that should be banned.. because B sent something that A requested...

unlike if lets say C (a malicious node) DDoSed A with unrequested data
in this event C would get banned.

but A would simply just not ask B to resend again. and would look for another source while keeping B active.

unlike the ethereum intentional split where its a permanent ban by extra ban rules being added.

its also not recommended to use the ban (meant for DDoS) to be used as an intentional split. (by adding in new rules)

[AgentofCoin]

I think you are talking about unintentional hardforks that reorg mostly.
When I was answering the OP, I was talking about intentional hardforks.
I believe an intentional hardfork can lead to two surviving chains such as with Ethereum.
I believe an intentional hardfork can either be an "upgrade" or an "attack" based on how its conducted.
I believe not all miners are purely financially motivated and some could be future attackers in waiting.

I'm not a programmer nor as technical as some of you, so some of my terminology and
explanations are not as precise and detailed.

hardforks under bitcoin resolve themselves due to orphans/consensus

an intentional split like ethereum (--oppose-dao-fork)
are things that are NOT proposed in any viable BIP and are not a hardfork. they are an intentional split(altcoin maker).

dont think of forks as 2 persistant chains. think of it as one chain that branches off and one limb will be cut off.. once orphan drama sorts out the victor.
any rational and viable fork should use consensus. to reduce orphan risk

a controversial hardfork is when the consensus is low. meaning LOTS of orphans (a tree branches out, you cut its limb. another branches out, you cut its limb. over and over)
again not 2 persistent chains

a consensual hardfork is when the consensus is high. meaning minimal orphans (a tree branches out, you cut the weak limb quite fast and continue the strong limb)
again not 2 persistent chains

a softfork changes a rule without branching, unless there is a bug.. (like the leveldb upgrade in 0.8 that started as soft. but ended up as hard and controversial)
a hardfork has a bigger chance of branching off even without a bug.. depending on node acceptance levels.

however
a controversial hardfork can be seen by the leveldb bug.
yep changing to leveldb was suppose to be a soft upgrade.. but ended up causing a controversial hard fork where there was not a clear majority running 0.7 or 0.8
where by 0.7nodes hung.. and were not syncing..
it was not 2 persistent chains. 0.8 continued on. 0.7 hung and didnt persist.

a decision was made to downgrade back to 0.7 and fix the cause later. thus cutting off the 0.8 limb rather than leaving 0.7 hanging in the unsyncing abyss of screaming out orphans. due to the high orphan risk

if there was a clear majority wanting to move forward. it would be more prudent to get the minority to upgrade..
if there was a clear majority wanting to stay back. it would be more prudent to get the minority to downgrade..

these days. pools wont even do anything unless there is a clear majority acceptance. they want to avoid orphans.(zero reward)
merchants want to avoid orphans(double spends)
fullnodes want to avoid orphans (bandwidth, loops, hangups)

A hardfork is a potential path for the network to take.
It is not an actual coding or protocol change that would be in a BIP.
It is the byproduct of a proposed BIP's deployment and activation.

When a hardfork occurs, it is either intentional or unintentional.
When it is intentional, it is either consensual or controversial.
When it is controversial, it is either lower than required % or malicious.
When it is unintentional, reorgs and consensus should handle it naturally.

The term hardfork does not connote that only one chain survived, only that a split in
the protocol occurred. So, it is possible that after a hardfork, two separate chains can
exist and survive. (Though personally, I think the system is a form of war and only one
chain should exist.) In the case of Ethereum, both the "original chain" and the "new chain"
survived, and which originated from an intentional controversial hardforking of the "original".

So a hardfork does not occur until there is a literal split or fork in the chain.
This fork, on one side has the original protocol and the other has the "new" protocol.
It is not a branching, but a literal "fork in the road" and we must choose a path.
The term branching assumes that it will come to an end at some point, but this is unknown.
Because it is unknown, before a hardfork is activated, there should be the required % consensus.

If a client exists that activates a new protocol and causes a hardfork intentionally with
only 50% consensus, which is designed to split the chain into two and take half the ecosystem,
not only is this an intentional controversial hardfork, but is also a malicious hardfork and would
be considered an attack. So it is an intentionally controversial malicious hardfork.

So, I think a hardfork can be many different things based upon the context that surrounds it.
I'm sure that in 5 years, there will be even more or an updated definition of what a hardfork
can or can not be. Hardforks didn't exist until Bitcoin was created and as such, we are still in
experimental waters.

[Yakamoto]

A hard fork is required in order to make block sizes larger than 1mb. There is no way to modify this based on the current understanding and implementation of the code, and because of this we are stuck with a huge debate whether or not to fork because it effectively changes the client we're using completely.

[franky1]

The term hardfork does not connote that only one chain survived, only that a split in
the protocol occurred. So, it is possible that after a hardfork, two separate chains can
exist and survive. (Though personally, I think the system is a form of war and only one
chain should exist.) In the case of Ethereum, both the "original chain" and the "new chain"
survived, and which originated from an intentional controversial hardforking of the "original".

So a hardfork does not occur until there is a literal split or fork in the chain.
This fork, on one side has the original protocol and the other has the "new" protocol.
It is not a branching, but a literal "fork in the road" and we must choose a path.
The term branching assumes that it will come to an end at some point, but this is unknown.
Because it is unknown, before a hardfork is activated, there should be the required % consensus.

If a client exists that activates a new protocol and causes a hardfork intentionally with
only 50% consensus, which is designed to split the chain into two and take half the ecosystem,
not only is this an intentional controversial hardfork, but is also a malicious hardfork and would
be considered an attack. So it is an intentionally controversial malicious hardfork.

So, I think a hardfork can be many different things based upon the context that surrounds it.
I'm sure that in 5 years, there will be even more or an updated definition of what a hardfork
can or can not be. Hardforks didn't exist until Bitcoin was created and as such, we are still in
experimental waters.

here we go someone else trying to meander all the types back into on umbrella term and then make that term sound bad. by only mentioning the worse cases

ethereum did not split and survive due to consensus.
it was not just 2 differing rules that battled it out in an orphan war.

they literally walked in different directions never looking at each other.
learn --oppose-dao-fork
im literally spelling it out for you which google can guide you further
--oppose-dao-fork is not a consensus orphan war. but a surrender and retreat to different corners and never look at eachother

ethereum should not be used as an example because ethereum did not use consensus.
no bitcoin proposal should use the intentional altcoin maker. all the blocksize bips that are viable are not using the intentional altcoin maker
the community want a consensus driven vote to grow on one mainnet. not split.
so why even mention something that requires adding intentional rules to ignore and walk away.
it has nothing to do with a viable bitcoin scaling. but everything to do with making clams2.0 (which the majority do not want anyway)

if people stop umbrella terming the creation of an altcoin to be the definition of a hard fork. and start running real simulations of using consensus
if people stop thinking that orphans only ever happen when an altcoin is potentially forming. and instead realise orphans happen more times then they think without an altcoin forming
.
they will realise consensus and orphans are part of bitcoin and a security feature built into bitcoin from day one.
banning nodes is not built into bitcoin. so atleast learn the difference and stop doomsdaying a normal consensus driven fork

[thejaytiesto]

Hard forks must be avoided at all costs and only be used if there is no other way to do something. For example, if someone launched a quantum attack against POW's current algo then the only way to protect us it would be to do a hard fork and change the mining algorithm to something else.

Or if China gov banned all mining as theymos points here:

I'm not sure that I'm convinced that hardforks are quite as bad as this article implies, but the article makes many good points. Though one thing that's important to keep in mind is that if we can never hardfork, then miners de facto control the network. For example, right now the Chinese government could completely shut down Bitcoin (or worse) because the majority of mining power is located in China. The only defense against this is the credible threat of a PoW change, which can only be done via hardfork.

[franky1]

Or if China gov banned all mining as theymos points here:

I'm not sure that I'm convinced that hardforks are quite as bad as this article implies, but the article makes many good points. Though one thing that's important to keep in mind is that if we can never hardfork, then miners de facto control the network. For example, right now the Chinese government could completely shut down Bitcoin (or worse) because the majority of mining power is located in China. The only defense against this is the credible threat of a PoW change, which can only be done via hardfork.

love the doomsday.
if china government banned mining. then pools switch to a stratum server based outside of china..(2 second switch) oh.. all the major pools already have backup stratums.. for that very reason
oh.. and many pools called 'china' are actually run in thailand, mongolia, georgia(europe), iceland, etc.. for that very reason

have a nice day

[AgentofCoin]

A hardfork is a potential path for the network to take.
It is not an actual coding or protocol change that would be in a BIP.
It is the byproduct of a proposed BIP's deployment and activation.

When a hardfork occurs, it is either intentional or unintentional.
When it is intentional, it is either consensual or controversial.
When it is controversial, it is either lower than required % or malicious.
When it is unintentional, reorgs and consensus should handle it naturally.

The term hardfork does not connote that only one chain survived, only that a split in
the protocol occurred. So, it is possible that after a hardfork, two separate chains can
exist and survive. (Though personally, I think the system is a form of war and only one
chain should exist.) In the case of Ethereum, both the "original chain" and the "new chain"
survived, and which originated from an intentional controversial hardforking of the "original".

So a hardfork does not occur until there is a literal split or fork in the chain.
This fork, on one side has the original protocol and the other has the "new" protocol.
It is not a branching, but a literal "fork in the road" and we must choose a path.
The term branching assumes that it will come to an end at some point, but this is unknown.
Because it is unknown, before a hardfork is activated, there should be the required % consensus.

If a client exists that activates a new protocol and causes a hardfork intentionally with
only 50% consensus, which is designed to split the chain into two and take half the ecosystem,
not only is this an intentional controversial hardfork, but is also a malicious hardfork and would
be considered an attack. So it is an intentionally controversial malicious hardfork.

So, I think a hardfork can be many different things based upon the context that surrounds it.
I'm sure that in 5 years, there will be even more or an updated definition of what a hardfork
can or can not be. Hardforks didn't exist until Bitcoin was created and as such, we are still in
experimental waters.

here we go someone else trying to meander all the types back into on umbrella term and then make that term sound bad. by only mentioning the worse cases
I was only defining each type of hardfork that I am aware of.
I am not aware of any good hardforks beyond an intentional consensual hardfork.

ethereum did not split and survive due to consensus.
it was not just 2 differing rules that battled it out in an orphan war.
ETH used intentional controversial (consensus) hardfork to "reverse" the DAO hack.
There was no battling out because a hardfork does not always have a battle.
ETH intentionally hardforked the chain to diverge from the older protocol.

they literally walked in different directions never looking at each other.
learn --oppose-dao-fork
im literally spelling it out for you which google can guide you further
--oppose-dao-fork is not a consensus orphan war. but a surrender and retreat to different corners and never look at eachother
You're basically trying to argue that ETH did not do a hardfork since there was no battle of the chain.
What I'm saying is that the term of a hardfork does not include orphaning in its definition.
A hardfork is the mechanism used to create a new chain with a new protocol.
A hardfork has nothing to do with how the two chains determine which is the "true" chain.

ethereum should not be used as an example because ethereum did not use consensus.
They claim they had near majority of consensus prior to the hardfork.
They also claimed that nodes and wallets that did not vote either way, was also vote Yes to hardfork.
no bitcoin proposal should use the intentional altcoin maker. all the blocksize bips that are viable are not using the intentional altcoin maker
the community want a consensus driven vote to grow on one mainnet. not split.
I agree.
so why even mention something that requires adding intentional rules to ignore and walk away.
Because that is a result of the hardfork mechanism, additional rules does not negate that it was a hardfork.
it has nothing to do with a viable bitcoin scaling. but everything to do with making clams2.0 (which the majority do not want anyway)
Yes. A hardfork does not only apply to scaling, but for anything that currently is not allowed.

if people stop umbrella terming the creation of an altcoin to be the definition of a hard fork. and start running real simulations of using consensus
if people stop thinking that orphans only ever happen when an altcoin is potentially forming. and instead realise orphans happen more times then they think without an altcoin forming
A true altcoin creation only comes from a forking off the codebase to create a second codebase,
it does not need to be the mainchain itself. An altcoin can be a clone of that codebase.
A hardfork is the mainchain itself forking off its own codebase. You can argue that created an altcoin, but originally an
altcoin is just a simple forking of the Github, like Litecoin. Because we now know two chains could survive after a hardforking,
we can now also argue that a hardfork can lead to an altcoin, like ETH and ETC.
.
they will realise consensus and orphans are part of bitcoin and a security feature built into bitcoin from day one.
I agree, but I think that only applies to an unintentional hardfork and an intentional malicious hardfork.
banning nodes is not built into bitcoin. so atleast learn the difference and stop doomsdaying a normal consensus driven fork
I think you have taken the term Hardfork and placed it into a box.
I never doomsayed an intentional consensual hardfork. I was only pointing out the other types of hardforks.
The definition of hardfork does not include orphaning or a battle of the chains.

My comments in red.

[franky1]

again now you are trying to claim an consensual fork as being an altcoin maker..
seriously!!

consensual = consensus
consensus breaks results in orphans and fixes itself as the SINGLE chain to what the majority consent to the minority just doesnt sync.

bitcoin has consensus built into it. from day one.
orphans happen all the time
https://blockchain.info/charts/n-orphaned-blocks

its all part of bitcoin

however
banning opposing nodes purely based on politics requires adding opposition ban list outsode of the built in Ddos parameters, outside of the time limit defaults of the ddos ban.

to get an altcoin it has to be an INTENTIONAL CONTROVERVIAL SPLIT where they IGNORE CONSENSUS/ORPHANS

[AgentofCoin]

again now you are trying to claim an consensual fork as being an altcoin maker..
seriously!!

consensual = consensus

consensus results in orphans
...

I never intentionally made that claim and don't know where you are getting that.
In a consensual hardfork, the old chain will die off and thus the new chain becomes the main chain.
There is no potential altcoin when there is a consensual hardfork.

[franky1]

I never intentionally made that claim and don't know where you are getting that.
In a consensual hardfork, the old chain will die off and thus the new chain becomes the main chain.
There is no potential altcoin when there is a consensual hardfork.

"old chain"... dies off??

its never a 2 chain event. its a BRANCH that gets trimmed off depending on which branch is the strongest where the weakest branch gets cut off

by claiming old chain. thats a imagery of claiming everything before the branch right to the genesis block dies.
its doesnt
blocks are still mined ontop of the previous blocks. the CHAIN continues on. just that there are not 2 persistent branches

no new genesis block is created, the mining doesnt start at block 1 again. it continues on..

again you do realise that consensus rule breaks happen everyday right.. up to about 2-3% average risk
https://blockchain.info/charts/n-orphaned-blocks

an nobody bats an eyelid because the majority of 97-98% exist to trim the branch pretty quick

again no viable BIP is asking for a altcoin maker. so i have no idea why you keep trying to make everything sound like an altcoin maker when nothing is even proposing that.

again the RATIONAL debate is about using consensus. the REALISTIC debate is about using consensus.
where the RATIONAL AND REALISTIC result is due to RATIONAL acceptance of a 5% risk.. is slightly elevated orphans

if a block was created at under 95% then the orphans would happen more noticeably.

take 51% mining.. that would be orphan hell and merchants would hold off on withdrawals/trading until the drama passes.

i dont know why you are obsessed with making everything sound like altcoin making.
have you even run any simulations.
have you even run a node that you have altered outside of blockstream devs perceived defaults. to realise that it does not create an altcoin
by you having 2mb base 4mb weight. right now.

yep thats right. nodes right now can have any blocksize setting they want be it 1.1mb, 1.5mb 2mb 4mb it wont change nothing.
pools wont however push out anything bigger until they know the SINGLE NETWORK can cope with it

[AgentofCoin]

I never intentionally made that claim and don't know where you are getting that.
In a consensual hardfork, the old chain will die off and thus the new chain becomes the main chain.
There is no potential altcoin when there is a consensual hardfork.

"old chain"... dies off??
When I say "old chain" I am implying "old protocol that no longer is majority supported".

its never a 2 chain event. its a BRANCH that gets trimmed off depending on which branch is the strongest where the weakest branch gets cut off
Yeah, that was the theory before Ethereum hardforked.
Post ETH hardfork it was discovered that hardforks have different outcomes based on different circumstances.
The term chain is not a constant. It ebbs and flows based on its future or current state and this is why I disagree with the
"branch" term, since all branches by their design, such as in nature, must end at some point. In theory, both chains can survive,
but with the term branch, it is whether one is longer than the other. Using the term "branch" misconstrues what a hardfork
can and can not do. By saying "branch", it implies that there can be no surviving "old protocol" chain.

by claiming old chain. thats a imagery of claiming everything before the branch right to the genesis block dies.
its doesnt
blocks are still mined ontop of the previous blocks. the CHAIN continues on. just that there are not 2 persistent branches
One "branch" will effectively "die off" in an intentional consensual hardfork.
One "chain" will effectively be "abandoned" in an intentional consensual hardfork.
One "fork" will effectively "not be built upon" in an intentional consensual hardfork.

In my understanding, the three above statements have the same meaning.

no new genesis block is created, the mining doesnt start at block 1 again. it continues on..
Yes. There is no new Genesis block, but that is irrelevant to a hardfork normally.

again you do realise that consensus rule breaks happen everyday right.. up to about 2-3% average risk
https://blockchain.info/charts/n-orphaned-blocks
Yes of course, but no one really cares about those since the system is designed to take care of those on their own.
Common orphans such as you describe is not a hardfork that most people regard as a hardfork,
but would be considered an unintentional fork that in time, is self correcting.

an nobody bats an eyelid because the majority of 97-98% exist to trim the branch pretty quick
Yes, as designed.

again no viable BIP is asking for a altcoin maker. so i have no idea why you keep trying to make everything sound like an altcoin maker when nothing is even proposing that.
Of course not. That wouldn't even be considered for a BIP number probably.
What am I saying sounds like an altcoin maker? As long as the hardfork creates one surviving
chain that 95% agree to follow, there is no reasonable possibility for an altcoin. The hardfork is
effectively an "upgrade", but if two survive, one must be an altcoin. I don't understand what I am
saying that leads you to think I am saying each hardfork leads to an altcoin. I am only saying that it is a
possibility based on how the hardfork is performed.

again the RATIONAL debate is about using consensus. the REALISTIC debate is about using consensus.
where the RATIONAL AND REALISTIC result is due to RATIONAL acceptance of a 5% risk.. is slightly elevated orphans
Yes, a 5% is acceptable only because the community believes not only can we not really get 100% but also
5% is so small there is no reasonable possibility of the "old protocol" chain surviving. Though I agree the current debate
is about whether if there will be a consensual hardfork, the fact is that there are more definitions and interpretations for the
word "hardfork" than just a full consensus one.

A slightly offtopic point: Your assumption is that when 95% agree to run one protocol over another, that
they will stick to that. That 95% is effectively a pledge to perform a future act, it does not guarantee that
post-hardfork. So with that understanding in mind, within a system that no one should trust anyone
else, including miners, we choose to take a risk at a 95% pledge. Because there is a risk due to whether
individuals will keep their word, there can always be an altcoin possibility, IMO. The act of reversing the
pledge after a hardfork, would result in an intentional malicious hardfork, IMO.

if a block was created at under 95% then the orphans would happen more noticeably.

take 51% mining.. that would be orphan hell and merchants would hold off on withdrawals/trading until the drama passes.
I agree, but I would categorize that as an attack or malicious hardfork since that shouldn't happen naturally.
It is also possible that could be a bug with the mining clients, so that would be considered an unintentional hardfork.


i dont know why you are obsessed with making everything sound like altcoin making.
have you even run any simulations.
have you even run a node that you have altered outside of blockstream devs perceived defaults. to realise that it does not create an altcoin
by you having 2mb base 4mb weight. right now.
No I have not and as I have stated previously I have no programming nor technical background.
I think you might be obsessed with portraying me a being obsessed about "altcoin making".
Are you arguing that every possible hardfork combination does not ever create a potential altcoin creation and existence?

If I can clone someone and make another, thus having two of that person, only one is the true version and the
other is the clone. This truth will continue that way forever until one or the other dies. When that death occurs,
there is now only one version, whether that one is the original or the clone, no longer matters, the surviving one
is the only one that now matters and becomes the "true" person. So when a hardfork occurs, there is a possibility
of an altcoin or a clone, but ultimately when one is effectively "dead" or "abandoned" does that altcoin label fade
and whatever chain exists becomes the mainchain.

yep thats right. nodes right now can have any blocksize setting they want be it 1.1mb, 1.5mb 2mb 4mb it wont change nothing.
pools wont however push out anything bigger until they know the SINGLE NETWORK can cope with it
Yes of course and I agree, but that is an assumption. But, if a block is created higher than 1MB and
propagated, majority of the network currently rejects it as you previous described. This is what I consider an
unintentional hardfork (by that miner or group of miners) that isn't allowed to survive (by a majority of others).

My comments in red.
I hope this explains my rational.

[franky1]

"old chain"... dies off??
When I say "old chain" I am implying "old protocol that no longer is majority supported".

its never a 2 chain event. its a BRANCH that gets trimmed off depending on which branch is the strongest where the weakest branch gets cut off
Yeah, that was the theory before Ethereum hardforked.
Post ETH hardfork it was discovered that hardforks have different outcomes based on different circumstances.
The term chain is not a constant. It ebbs and flows based on its future or current state and this is why I disagree with the
"branch" term, since all branches by their design, such as in nature, must end at some point. In theory, both chains can survive,
but with the term branch, it is whether one is longer than the other. Using the term "branch" misconstrues what a hardfork
can and can not do. By saying "branch", it implies that there can be no surviving "old protocol" chain.

the old protocol is still acceptable to the branch.. because they are connected.

EG lets say old protocol block 0-450000 new consensus 450001..
by saying old protocol not supported. thats like saying it will reject blocks below 450k
killing off the old chain.
wrong on so many levels.

with 2mb, blocks of 0.0002mb->1.99mb are supported. it also does not mean all blocks have to be over 1mb but under 2mb
again blocks of 0.0002mb->1.99mb are supported. the old protocol IS supported.

as for your ethereum mention. please please please research ethereum. rather than just the media hype
learn how they AVOID and drop connection to.. rather than using consensus.
and stop comparing ethereums intention avoidance to a proposed bitcoin consensus. they are not the same thing

[franky1]

by claiming old chain. thats a imagery of claiming everything before the branch right to the genesis block dies.
its doesnt
blocks are still mined ontop of the previous blocks. the CHAIN continues on. just that there are not 2 persistent branches
One "branch" will effectively "die off" in an intentional consensual hardfork.
One "chain" will effectively be "abandoned" in an intentional consensual hardfork.
One "fork" will effectively "not be built upon" in an intentional consensual hardfork.

In my understanding, the three above statements have the same meaning.

no new genesis block is created, the mining doesnt start at block 1 again. it continues on..
Yes. There is no new Genesis block, but that is irrelevant to a hardfork normally.

if you want the imagery of a chain. then it would be
some double links of a chain are abandoned and replaced with new single links..
NOT the chain is abandoned

the reason i use trees/branches is 2 fold. one.. devs love their merkle tree and also trees grow naturally they naturally make branches and can have their branches cut off. devs's also love to "prune" .. not wirecut.. so branches instead of metal chain seems to fit their narative as a way of explaining things

[franky1]

A slightly offtopic point: Your assumption is that when 95% agree to run one protocol over another, that
they will stick to that. That 95% is effectively a pledge to perform a future act, it does not guarantee that
post-hardfork. So with that understanding in mind, within a system that no one should trust anyone
else, including miners, we choose to take a risk at a 95% pledge. Because there is a risk due to whether
individuals will keep their word, there can always be an altcoin possibility, IMO. The act of reversing the
pledge after a hardfork, would result in an intentional malicious hardfork, IMO.

you do know that if 95% have nodes that accept 2mb.. they accept ANYTHING below 2mb.
meaning

when nodes get to 95% ... 2 weeks grace pass to make sure it isnt a fluke.
miners then do a upto 95% period too plus a grace period.
by which time the node count should exceed 95%.

if it deminishes, pools wont risk it if the orphan rate risk jumped.
if it stays stable, pools would try it out

where pools only risk making blocks of 10000250byte block and see what the orphan rate is like
if happy they naturally test the waters with slightly more.

in short. back in 2009-2016 miners were not jumping to 1mb. they slowly progressed to 1mb.
dont think/imagine that pools are suddenly going to make 1.99mb the day of activation. (rationally/logically/logistically they wont)

if the orphan rate is too high we stick to 1mb.
this does not mean nodes have to downgrade. because 2mb accepts any data below 2mb
whether its 250bytes 1kb, 100kb 0.99mb whatever.

its more then a pledge because the nodes would already have the 2mb rule inplace BEFORE activation. meaning nodes are fully accepting even before pools push the envelope

right now many nodes are HAPPILY running with 2mb active. just like old nodes were happily running 1mb rule when blocks were only bing made at 0.2mb in 2009-2011 or 0.5mb upto 2013..
yep the rule was 1mb but blocks were under 1mb
future rule of 2mb while blocks are under 2mb.. same thing

but here is the funny part.. segwit IS a pledge. if you did not realise it 0.8->0.13.1 NEEDS to be upgraded to a new release (not yet available) AFTER activation for users to actually use segwit transaction features. yes only avaiable AFTER.

but things like BU, and other blocksize consensus nodes are ACTIVE AND RUNNING now. they are just waiting for a  majority to give miners confidence to push the envelope and test the water.. with worse case, them getting thier attempt orphaned.

[Xester]

Everything just get complicated. When the discussion is about fork I got headache about different ideas pertaining to what kind of fork should be used. Hope there will be subtle and less complicated explanations that is easily absorbed. But let us get back to the topic guys, the author asks if it is possible that the blocksize will increase if soft fork is used? Please answer yes or no only so it will be less complicated.

[AgentofCoin]

"old chain"... dies off??
When I say "old chain" I am implying "old protocol that no longer is majority supported".

its never a 2 chain event. its a BRANCH that gets trimmed off depending on which branch is the strongest where the weakest branch gets cut off
Yeah, that was the theory before Ethereum hardforked.
Post ETH hardfork it was discovered that hardforks have different outcomes based on different circumstances.
The term chain is not a constant. It ebbs and flows based on its future or current state and this is why I disagree with the
"branch" term, since all branches by their design, such as in nature, must end at some point. In theory, both chains can survive,
but with the term branch, it is whether one is longer than the other. Using the term "branch" misconstrues what a hardfork
can and can not do. By saying "branch", it implies that there can be no surviving "old protocol" chain.

the old protocol is still acceptable to the branch.. because they are connected.

EG lets say old protocol block 0-450000 new consensus 450001..
by saying old protocol not supported. thats like saying it will reject blocks below 450k
killing off the old chain.
wrong on so many levels.

with 2mb, blocks of 0.0002mb->1.99mb are supported. it also does not mean all blocks have to be over 1mb but under 2mb
again blocks of 0.0002mb->1.99mb are supported. the old protocol IS supported.

Yes, I agree with what you are saying mostly.
The issue here is that I do not speak as technically as I should, since this is not my field.
When I refer to the old protocol chain, it assumes two surviving chains each building different
blocks based upon their separate rules. When only one chain exists, the old protocol chain is the
past of the new protocol chain, since the new protocol won majority.

as for your ethereum mention. please please please research ethereum. rather than just the media hype
learn how they AVOID and drop connection to.. rather than using consensus.
and stop comparing ethereums intention avoidance to a proposed bitcoin consensus. they are not the same thing

My understanding is that there were no changes made and the two chains was a direct failure of consensus.
15% of the Ethereum network chose to not update before the hardfork and chose to intentionally continue
on the "original" chain. I am not aware that those who chose not to update took any specific actions to ignore
the "new chain". If anything, the many weeks of replay attacks after the hardfork showed that they didn't
anticipate that two chains could co-exist.

by claiming old chain. thats a imagery of claiming everything before the branch right to the genesis block dies.
its doesnt
blocks are still mined ontop of the previous blocks. the CHAIN continues on. just that there are not 2 persistent branches
One "branch" will effectively "die off" in an intentional consensual hardfork.
One "chain" will effectively be "abandoned" in an intentional consensual hardfork.
One "fork" will effectively "not be built upon" in an intentional consensual hardfork.

In my understanding, the three above statements have the same meaning.

no new genesis block is created, the mining doesnt start at block 1 again. it continues on..
Yes. There is no new Genesis block, but that is irrelevant to a hardfork normally.

if you want the imagery of a chain. then it would be
some double links of a chain are abandoned and replaced with new single links..
NOT the chain is abandoned
the reason i use trees/branches is 2 fold. one.. devs love their merkle tree and also trees grow naturally they naturally make branches and can have their branches cut off. devs's also love to "prune" .. not wirecut.. so branches instead of metal chain seems to fit their narative as a way of explaining things

Well the reason why I say "two chains" is because when a split occurs, there is literally two separate blockchains.
So the single blockchain has become two, yet prior to the hardfork point, there was only one past.
                          /============O
O==========|============O

So when I say the "old chain/protocol is abandoned" I mean the following:
                          /============O
O==========|==X

You have to remember I am only talking in the sense that a hardfork has occurred.
When that happens, there will either be two chains, or a single chain, but both will always share the same past.
The issue here is that I do not use the proper terms for certain technically recognized things.

A slightly offtopic point: Your assumption is that when 95% agree to run one protocol over another, that
they will stick to that. That 95% is effectively a pledge to perform a future act, it does not guarantee that
post-hardfork. So with that understanding in mind, within a system that no one should trust anyone
else, including miners, we choose to take a risk at a 95% pledge. Because there is a risk due to whether
individuals will keep their word, there can always be an altcoin possibility, IMO. The act of reversing the
pledge after a hardfork, would result in an intentional malicious hardfork, IMO.

you do know that if 95% have nodes that accept 2mb.. they accept ANYTHING below 2mb.
meaning
when nodes get to 95% ... 2 weeks grace pass to make sure it isnt a fluke.
miners then do a upto 95% period too plus a grace period.
by which time the node count should exceed 95%.
if it deminishes, pools wont risk it if the orphan rate risk jumped.
if it stays stable, pools would try it out
where pools only risk making blocks of 10000250byte block and see what the orphan rate is like
if happy they naturally test the waters with slightly more.
in short. back in 2009-2016 miners were not jumping to 1mb. they slowly progressed to 1mb.
dont think/imagine that pools are suddenly going to make 1.99mb the day of activation. (rationally/logically/logistically they wont)
if the orphan rate is too high we stick to 1mb.
this does not mean nodes have to downgrade. because 2mb accepts any data below 2mb
whether its 250bytes 1kb, 100kb 0.99mb whatever.
its more then a pledge because the nodes would already have the 2mb rule inplace BEFORE activation. meaning nodes are fully accepting even before pools push the envelope
right now many nodes are HAPPILY running with 2mb active. just like old nodes were happily running 1mb rule when blocks were only bing made at 0.2mb in 2009-2011 or 0.5mb upto 2013..
yep the rule was 1mb but blocks were under 1mb
future rule of 2mb while blocks are under 2mb.. same thing

Yes, I understand this. My off topic statement was just to point out that when nodes signal for a change,
that does not guarantee they will follow through, and that is also a risk that we take. I agree with everything
you say in theory, I'm just saying that if we hardforked and a large % of hash and nodes decided to immediately
downgrade back to their prior protocol version that rejected higher than 1MB block, that couldn't be stopped. So
when we do hardfork, we take the risk by taking the signalers at their word that they will follow through and not
backtrack after the hardfork. If this did occur, it would be an attack vector on the economy IMO. That's my only
point. So I don't think it is more than a pledge, since there is no guarantee they will stick with their pledge until
well after the hardfork. The pledge is only a signalling prior to the hardfork.

but here is the funny part.. segwit IS a pledge. if you did not realise it 0.8->0.13.1 NEEDS to be upgraded to a new release (not yet available) AFTER activation for users to actually use segwit transaction features. yes only avaiable AFTER.

but things like BU, and other blocksize consensus nodes are ACTIVE AND RUNNING now. they are just waiting for a  majority to give miners confidence to push the envelope and test the water.. with worse case, them getting thier attempt orphaned.

Yes, in theory it is a pledge as well, but there is no hardfork since it uses the softfork method.
But yes, if enough pledge for SegWit and that softfork is activated, only after will the SegWit
addresses and transactions be functional. The only difference between the two pledges discussed
is that one is a hardfork pledge and the other is a softfork pledge and personally I think a hardforked
pledge that is reneged upon is bad for the economy. But a reneged softfork pledge shouldn't effect the
economy, that I can currently think of. But yes, they both are activated by % pledges at first, then they
back it up with work/numbers later after the fork.

[AgentofCoin]

Everything just get complicated. When the discussion is about fork I got headache about different ideas pertaining to what kind of fork should be used. Hope there will be subtle and less complicated explanations that is easily absorbed. But let us get back to the topic guys, the author asks if it is possible that the blocksize will increase if soft fork is used? Please answer yes or no only so it will be less complicated.

No, using a softfork to increase the Bitcoin blocksize limit is not possible.
For an increase in the blocksize limit, a hardfork is needed.