Topic: What happens if BU fails VS What happens if SegWit fails - page 6. (Read 6407 times)

If you don't want to drop from consensus due to too small a block size limit and you don't want to update your node, then you can set your "excessive block gate" to something like 12 or so (this is actually the default setting).  This means that your node will try to reject blocks larger than your block size limit setting, but give up and follow the mining majority if the network as a whole decides to accept larger blocks.

Here is an article that describes how this optional feature works:  

https://medium.com/@peter_r/the-excessive-block-gate-how-a-bitcoin-unlimited-node-deals-with-large-blocks-22a4a5c322d4

Jap, i think maybe we should stop to talk about that crap (BU) and not respond to the trolls anymore (frany1).

BU is not an option and never will be.  

We should work towards bringing more power to the users, not to the miners, they are getting their fucking blockreward and should be fine with that. Nothing more and especially no ultmate decision power.
So UASF is maybe a way to go. The reaction from Mr. Jihan shows its a at least an option.


No franky im not interested in what you have to say, just STFU.

do your research. stop reading the 20 second reddit scripts. your getting obvious

read code
learn consensus
understand bitcoin
stop defending humans

1. jihan isnt the mining king that wil own bitcoin.. please research stats not social media
2. pools are not the boss never have or will be. they are the secretaries.. nodes are the bosses and devs need to be reminded that devs are just workers
3. implementations that are not blockstream are not the ones wanting to be kings.
4. its actually blockstream that gave ONLY pools the vote over segwit.. yet a hard consensus is about NODES st the rules pools follow

Talking about BU any further it's useless. BU will never work, the model is flawed, it leads to destruction, miners would be total bosses, more than now and now it's bad enough already. Jihan Wu would rule Bitcoin under the BU model, which is why he pushes it. Very sad..

there are many solutions. you just dont hear about them due to the censorship and hoops you have to jump through just to get a core dev to even class it as a bip on "their" bip wall.

and the social media trolling drowning out other methods of promoting one because "its not been reviewed by the blockstream gods"

recently gmaxwell handed the Bip reins over to luke jr but gmaxwell still moderates the technical discussion boards of this forum and works along side theymos in the reddit forum. and also admins the mailing lists. and has co-horts moderating the IRC.

so goodluck to anyone not ass kissing blockstream for coming up with anything new that actually gets passed the blockstream wall, and into the communities general acceptance

Here is a thought. Perhaps a good percentage of these undecided are not really undecided but just don't like the options available to them, so are happy to keep the status quo until a better solution is found, or perhaps that one of the solutions is better implemented?

If this is how BU works, I don't think I like the idea of running a node and constantly have to check whether my synchronization has stopped because I have dropped out of the bottom consensus and then having to change configuration.
Also, there is a need for blocksize to shrink to stop the fee market tending back to zero when there is no or little block reward when volume drops. If BU doesn't do this then I don't think it is the right answer either.
It all needs to be a lot more automatic for me.

Let's see BU fork and let's see how they manage themselves without leeching off Core devs. But they are too scared to fork so they will keep using their shitty tactics. Jihan Wu is a disaster for bitcoin, I wish his stupid monolopy ended, but im not sure about UASF fixing anything in the long run.

1. I assume we could also downscale. If nodes lower their limit for whatever reasons (or new nodes with low limits get added to the network). The pools would adopt and make smaller blocks if the orphan rate would be to high.
2. I thought the difference between an orphan and an invalid block would be that an invalid block doesn't meat the parameters of the consensus. Whereas an orphan is a valid block that is just propagated at the same time with another and it is not sure which one will result in the longer chain. So invalid = fork and orphan =/= fork.

edit: just read your edit and this makes it clear clear for me. Thank you.

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"

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.

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

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?

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)

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?

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

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?

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
^ 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)


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

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.