Topic: Increase blocksize with soft fork? (Read 1604 times)

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

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.



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.



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.



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.



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.

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.

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.

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

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

"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

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.

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

My comments in red.

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

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:

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

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.

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.

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)

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.

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)

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.


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.


Correct.  A fork with 2 incompatible blockchains.


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


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.


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.


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