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