Topic: Increase blocksize with soft fork? - page 2. (Read 1604 times)

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.



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

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

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.

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

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.

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.

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.

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

Guys,

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

Thx