What happens if BU fails VS What happens if SegWit fails

[franky1]

check out the unconfirmed
https://blockchain.info/charts/mempool-size?daysAverageString=7&timespan=1year

apart from a blip in june/july (ill get to this later)
mempool size was 2mb-3mb..

then in october. (around the 10th october) it started to get into 4mb.. and started rising...and rising. and rising.. hmmm i wonder what new feature was introduced in october that needed the community to get frustrated and delayed to "sell" the community into thinking this feature being the promise to fix the issue..

hmm.. oh yea.. segwit.

as for june july. (CLTV+CSV)

what a coincidence.. spam attacks right around the times blockstream devs want pools to think certain features need to be added to be stepping stones to something that (may) eventually fix spam attacks..

[1713285707]

1713285707

[1713285707]

1713285707

[Searing]

If neither happens, bitcoin core is just fine with the current block size. They likely
would never have moved to even seg witness yet without the push for bigger blocks

Their viewpoint is 1mb blocks are just dandy, because btc is mainly a store of value
and currency is not relevant as long as price goes up.

Thus this impasse will likely go on for years as long as BTC price rises and continues to
act as bitcoin core assumes, as store of value, that continues to rise steadily.

Impasse/stalemate

[Sadlife]

There are no clear consensus to Bitcoin scaling problem but whether BU or Segwit will not be implemented for now, will not be a problem in Bitcoin cause this currency will still move forward.
The bitcoin network can still handle the volume of transactions in a daily basis with the drawback to pay high fees in order for your transactions to get confirmed faster.
I think this problem will remain for many years if the community continues to debate and argue for better solutions.

[jonald_fyookball]

There are no clear consensus to Bitcoin scaling problem but whether BU or Segwit will not be implemented for now will not be a problem in Bitcoin cause this currency will still move forward.
The bitcoin network can still handle the volume of transactions in a daily basis with the drawback to pay high fees in order for your transactions to get confirmed faster.
I think this problem will remain for many years if the community continues to debate and argue for betteflr solutions.

If by "not a problem" you mean its ok for Bitcoin to possibly lose opportunities for investment, mainstream adoption, and continued clear dominance as the #1 crypto, then sure, its not a problem.

[Searing]

There are no clear consensus to Bitcoin scaling problem but whether BU or Segwit will not be implemented for now will not be a problem in Bitcoin cause this currency will still move forward.
The bitcoin network can still handle the volume of transactions in a daily basis with the drawback to pay high fees in order for your transactions to get confirmed faster.
I think this problem will remain for many years if the community continues to debate and argue for betteflr solutions.

If by "not a problem" you mean its ok for Bitcoin to possibly lose opportunities for investment, mainstream adoption, and continued clear dominance as the #1 crypto, then sure, its not a problem.

Just seems to me that where the current bitcoin core devs seem to think. Thus gridlock. But more daunting is no one is talking or trying to solve the issue on one or both camps.

Again...frigging stalemate

[Senor.Bla]

There are no clear consensus to Bitcoin scaling problem but whether BU or Segwit will not be implemented for now will not be a problem in Bitcoin cause this currency will still move forward.
The bitcoin network can still handle the volume of transactions in a daily basis with the drawback to pay high fees in order for your transactions to get confirmed faster.
I think this problem will remain for many years if the community continues to debate and argue for betteflr solutions.

If by "not a problem" you mean its ok for Bitcoin to possibly lose opportunities for investment, mainstream adoption, and continued clear dominance as the #1 crypto, then sure, its not a problem.

Just seems to me that where the current bitcoin core devs seem to think. Thus gridlock. But more daunting is no one is talking or trying to solve the issue on one or both camps.

Again...frigging stalemate

High fees are holding Bitcoin back (and i don't mean the price). They make micro payments unattractive/unpractical.
Maybe many are undecided because they rather remain in the status quo than see Bitcoin fuck up.
The agenda of core/blockstream is clear and whether there points are right or wrong, i don't expect them to compromise.
I don't see however the reasons for BU to not compromising. Many of them seem to care about Bitcoin and want a good solution.
The emergent consensus seems to be their biggest hold up. Why are they still pushing for it. Why not just go for a quick increase of blocksize to 2MB? Try it on for size, see how the network acts, which would be valuable information for further increases. It would be a small but immediate and safe relief and it would buy time to test the emergent consensus more or look for different options. I'm sure this would also attract a bunch of developers to this solution. I'd expect also many undecided to jump on that wagon, so why doesn't BU compromise to this? What are there reasons to push fore there solution without compromise?

[hv_]

If neither happens, bitcoin core is just fine with the current block size. They likely
would never have moved to even seg witness yet without the push for bigger blocks

Their viewpoint is 1mb blocks are just dandy, because btc is mainly a store of value
and currency is not relevant as long as price goes up.

Thus this impasse will likely go on for years as long as BTC price rises and continues to
act as bitcoin core assumes, as store of value, that continues to rise steadily.

Impasse/stalemate

So the end game of that scenario is like:

BTC price is e.g. 2Mio $
TX fee e.g. 1000$

With that only big guys will transfer = banks and funds, or better hodl in their core funds.

We see it today, with Vontobel BTC tracker it is cheaper to transfer the tracker using e.g. SWIFT

So we need middle men and can not own BTC any more but have to buy IOU to participate in this store of value.

Do you think thats the future?

[Searing]

If neither happens, bitcoin core is just fine with the current block size. They likely
would never have moved to even seg witness yet without the push for bigger blocks

Their viewpoint is 1mb blocks are just dandy, because btc is mainly a store of value
and currency is not relevant as long as price goes up.

Thus this impasse will likely go on for years as long as BTC price rises and continues to
act as bitcoin core assumes, as store of value, that continues to rise steadily.

Impasse/stalemate

So the end game of that scenario is like:

BTC price is e.g. 2Mio $
TX fee e.g. 1000$

With that only big guys will transfer = banks and funds, or better hodl in their core funds.

We see it today, with Vontobel BTC tracker it is cheaper to transfer the tracker using e.g. SWIFT

So we need middle men and can not own BTC any more but have to buy IOU to participate in this store of value.

Do you think thats the future?

No idea...but for some reason bitcoin core devs feel it is just dandy to sit on hands and have a 1mb block size and look at btc as a store of value

on the other side

they feel it is just dandy to not get seg witness now and fight the up'ing in block size later (past 1mb) with bitcoin core..because they see it as

their only leverage with bitcoin core for any movement

So bitcoin core won't hard fork and those not wanting bitcoin core won't let the btc core developers have the lead and allow a soft fork

it is quite the cluster

 

[AngryDwarf]

Looking at the network topology of the segwit softfork, it looks horrible. The idea that there is a mixture of nodes, some with full network knowledge and some without full knowledge of it if they don't upgrade is asking for complications in my opinion. I wouldn't be surprised if some of franky1's concerns are true, but cannot confirm this as it is way beyond my technical knowledge and expertise in this area.
Perhaps this should have been implemented as a hard fork along with the 2MB block size increase as originally agreed. If the miners and exchanges are behind a hard fork, the old fork is a stuck difficulty chain with coins that cannot be traded.
Even if the future is that the main chain is more of a settlement chain, with lightning style networks providing retail functions, there still needs to be an ability to grow the chain to meet demand. Some alt coins (e.g. Komodo) are now using the bitcoin blockchain, increasing demand. I don't see why some algorithmic block size change can't be implemented. It could look at parameters such as high fee / low fee unconfirmed transactions, past block usage, orphan rates, etc. and slowly adjust, monitor effects and adjust. Then a sensible fee market could develop, rather than this pathetic fee race or drop out due to expense situation we have now due to a fixed block size. A fee market cannot develop on a full block chain, it just limits use when it becomes to expensive to transact.
I'm not surprised the miners are upset with core / blockstream developers for not keeping to their word and implementing segwit as a hard fork along with a much needed and conservative 2MB block size change. So perhaps it is stalemate until we see which economic power goes bust first.

[Carlton Banks]

I wouldn't be surprised if some of franky1's concerns are true, but cannot confirm this as it is way beyond my technical knowledge and expertise in this area.

FYI, franky has been having his "concerns" for 3 years and counting.


Do you know what happened to the issues that Franky used to complain about? He no longer complains. Because they were demonstrated to be unproductive trolling. When he finds they don't work, he simply switches to newer trolling strategies instead.

If you'd believed anything Franky had stated or predicted, Bitcoin would be hugely unsuccessful cryptocurrency with all the users abandoning it in fear and frustration. But it keeps becoming more popular, and more successful.

[franky1]

I wouldn't be surprised if some of franky1's concerns are true, but cannot confirm this as it is way beyond my technical knowledge and expertise in this area.

FYI, franky has been having his "concerns" for 3 years and counting.


Do you know what happened to the issues that Franky used to complain about? He no longer complains. Because they were demonstrated to be unproductive trolling. When he finds they don't work, he simply switches to newer trolling strategies instead.

If you'd believed anything Franky had stated or predicted, Bitcoin would be hugely unsuccessful cryptocurrency with all the users abandoning it in fear and frustration. But it keeps becoming more popular, and more successful.

concerns years ago. blockstream take over.
community wanted onchain scaling with dynamic blocks and compromised down to initially 2mb dynamic in late 2015..

yes carlton too wanted dynamic blocks aswell, funnily enough

no-one credible is saying that, how many times...

Before you say that I was using a straw man argument, I was not. I did not say that you think we should not increase the block size. I know that you support a dynamic limit, and as soon as it is implemented and a mechanism for a fork has been put in place I would most likely support that as well instead of BIP101. At that point we will most likely be on the same side of the fork again.

I would welcome that outcome.

^ one of many examples


blockstream devs LukeJr and Adam back said they will do their part....
spring 2016.. they backtracked and now we are left with their empty gesture that is not even a guaranteed or real expected fixed 2mb. let alone dynamic
and instead an attempt to get their nodes at the top of the network topology (upstream filters)

their 2mb boost wont occur, the other fixes wont occur* and we are still left on the reliance of them spoon feeding out code rather than let the nodes independantly set the limits and use consensus to set the overall rule.
*(needs users to move funds to segwit keys and only use segwit keys to achieve anything, but doesnt fix/prevent the native key users = problems not solved, solutions not achieved)

I don't see however the reasons for BU to not compromising. Many of them seem to care about Bitcoin and want a good solution.
The emergent consensus seems to be their biggest hold up. Why are they still pushing for it. Why not just go for a quick increase of blocksize to 2MB? What are there reasons to push fore there solution without compromise?

thre was a compromise.. the consensus roundtable of late 2015.. the community settled on a 2mb starting point but wanting it dynamic so that we didnt need these "human" meetings and instead could let the nodes decide what node can cope with and then the pools produce blocks within what nodes can tolerate.

but guess what blockstream backtracked and pretended they are not involved that much in core and cant code a solution.
strange thing is that thee late 2015 consensus event should have just invited the blockstreams office janitor instead and that probably would have been more productive

[AngryDwarf]

So if the 2015 consensus event was adhered too, we would have the best of both worlds. A hard fork with dynamic block solution, and a simplified and more effective implementation of segwit allowing for full steam ahead for those wanting to develop lightning networks.
Instead we have sectarianism and deadlock, one which the miners can quite happily sit out.
And in the meantime, bitcoin adoption suffers.

Is this a good summarization of the situation?

[franky1]

So if the 2015 consensus event was adhered too, we would have the best of both worlds. A hard fork with dynamic block solution, and a simplified and more effective implementation of segwit allowing for full steam ahead for those wanting to develop lightning networks.
Instead we have sectarianism and deadlock, one which the miners can quite happily sit out.
And in the meantime, bitcoin adoption suffers.

Is this a good summarization of the situation?

your forgetting that all the complaints to blame miners is also due to blockstream

if it was a full hard consensus (nodes first then pools second) the nodes would upgrade and given confidence to pools to then vote second because the pools would know that node could cope with it.

but blockstream devs envisioned going soft and gave only the pools the vote.. emphasis blockstream devs gave pools the vote.

but the pools are smart to not change anything without nodes being there to accept the change, so the pools are waiting undecided. the only pools voting for segwit are BTCC and slush which are if you research their VC funding BTCC are funded by the same guys as blockstream. so its obvious why BTCC jumped right onboard the segwit train before thinking about the pro's and cons to the network effect or if segwit would actually solve issues for the whole network.
http://dcg.co/network/#b  <- blockstream, BTCC

[Senor.Bla]

...

I don't see however the reasons for BU to not compromising. Many of them seem to care about Bitcoin and want a good solution.
The emergent consensus seems to be their biggest hold up. Why are they still pushing for it. Why not just go for a quick increase of blocksize to 2MB? What are there reasons to push fore there solution without compromise?

thre was a compromise.. the consensus roundtable of late 2015.. the community settled on a 2mb starting point but wanting it dynamic so that we didnt need these "human" meetings and instead could let the nodes decide what node can cope with and then the pools produce blocks within what nodes can tolerate.

but guess what blockstream backtracked and pretended they are not involved that much in core and cant code a solution.
strange thing is that thee late 2015 consensus event should have just invited the blockstreams office janitor instead and that probably would have been more productive

What i could condense from the arguments of core/blockstream is that they are afraid of the dynamic blocksize, because it would give miners to much power. So what do they want now? Set them themselves instead of meetings or a dynamic?
What is the reason for BU to hang on to the dynamic? Is it only because they don't want these meetings too? To avoid to hard fork to often?

[franky1]

What i could condense from the arguments of core/blockstream is that they are afraid of the dynamic blocksize, because it would give miners to much power. So what do they want now? Set them themselves instead of meetings or a dynamic?
What is the reason for BU to hang on to the dynamic? Is it only because they don't want these meetings too? To avoid to hard fork to often?

dynamic blocks DO NOT give pools the power.
node consensus is the power. and pools know that.
pools could produce any blocksize they want but if nodes orphan a block... that block is metaphorically in the trashcan. thus pools wont do things that waste their electric and time.

dynamic scaling works in a 1,2,3 step bases.. the blockstream 'dynamic is doomsday'ers however twist the logic of reality and talk about the 3,1 fake methodology(backwards and skipping a step) which is not how it will play out, but helps them scare the community into thinking that without the blockstream devs spoonfeeding and without king maxwell standing on his mount preaching the rules, bitcoin would break

blockstreams soft fork gave pools the vote so that if it succeeds in activating. blockstream take the glory. if it fails they have the bait and switch to blame it on the pools.
(typical banker economic illogic: if economy rises bankers celebrate their greed saved the economy. if it fails, blame the poor)

[Senor.Bla]

What i could condense from the arguments of core/blockstream is that they are afraid of the dynamic blocksize, because it would give miners to much power. So what do they want now? Set them themselves instead of meetings or a dynamic?
What is the reason for BU to hang on to the dynamic? Is it only because they don't want these meetings too? To avoid to hard fork to often?

dynamic blocks DO NOT give pools the power.
node consensus is the power. and pools know that.
pools could produce any blocksize they want but if nodes orphan a block... that block is metaphorically in the trashcan. thus pools wont do things that waste their electric and time.

dynamic scaling works in a 1,2,3 step bases.. the blockstream 'dynamic is doomsday'ers however twist the logic of reality and talk about the 3,1 fake methodology(backwards and skipping a step) which is not how it will play out, but helps them scare the community into thinking without the blockstream devs spoonfeeding and without king maxwell standing on his mount preaching the rules, bitcoin would break

Here is the part where i'm confused. The argument goes like this. We have dynamic blocks and there is a 2.5MB blocked mined. Node A sees it as invalid and drops it, but node B and C accept it as well as all Miners. Bitcoin will built on this block and Node A will have to accept it or fork. Right?

Now we have the same scenario but Nodes A and B (the majority) rejects the block and only Node C and all miners accept it. Wouldn't this mean we would still built on top of this 2.5MB block and lose 2 nodes? It's an invalid block to the majority of Nods, but they have no miners behind them, so who is going to mine for them? Wouldn't this situation be technically considered as a fork?

[franky1]

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

[Carlton Banks]

So if the 2015 consensus event was adhered too, we would have the best of both worlds. A hard fork with dynamic block solution, and a simplified and more effective implementation of segwit allowing for full steam ahead for those wanting to develop lightning networks.
Instead we have sectarianism and deadlock, one which the miners can quite happily sit out.
And in the meantime, bitcoin adoption suffers.

Is this a good summarization of the situation?

No.

The 2015 agreement said nothing of the sort. The agreement was to implement Segwit first, then expand to 2MB base later. Nothing about dynamic sizing was part of it, that claim has been invented out of thin air.

[Senor.Bla]

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

[franky1]

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

1. if nodes and pools decide 95% of the network is the metric then it requires 5.01% of the network to hold up block growth with 5% possible orphan heaches. if 75% of the network is the metric . the 25.01% of the network is needed to hold back growth with upto 25% orphan headaches if pools tried to exceed limits.

what you need to also take into account is nodes might have 75%-95%.. but pools may also have their own safer metric to reduce orphan risks

EG nodes at 75% where consensus.h 4mb and policy at 2.5mb
EG pools at 95% where consensus.h 2.499mb and policy at 1.01mb

for instance. resulting in pools only making blocks 1mb-2.499mb before seeing issues and pools only moving passed 2.5 if 95% of pools agree and 75% of nodes agree..

2. if an orphan game results in bilateral split(it doesnt).. we would be having several altcoins being created a week for the last 8 years just because of orphans
https://blockchain.info/orphaned-blocks

orphans KILL OFF opposing blocks. to keep to one chain

to avoid orphaning a block. the nodes need to ban the opposition to not see/try syncing to oppositions blockheight and to successfully build their own.

othrwise they end up in orphan hell rejecting their own small network because its lower blockheight, to instead request data from the nodes with higher blockheight... but then rejecting the oppositions because although they have higher blockheight the data (blocksize) breaks the rules when they get that block they request..thus being left unsynced.

so it requires not connecting to that main chain. to avoid seeing it to then happily grow their own chain (as clams2.0)

remember ethereum was not a CONSENSUS fork it was a bilateral split involving banning nodes. hint: "--oppose-dao-fork"