So who the hell is still supporting BU?

[Daedra]

I find it really, really frustrating that you have a room full of otherwise hyperintelligent people, who were told in very clear terms by the Chinese miners what those miners want about a year ago (a hardfork increasing the max blocksize limit for the present type of transactions to at least 2 megabytes), and today, you have the same people asking in frustration why Chinese miners are not adopting segwit when those miners said in bright blinking cleartext a year ago what it is they want, and it is not segwit.

Do you think we must be controlled by Chinese miners? I would prefer decentralization

[Xester]

If the CHinese miners were not supporting segwit then possibly they have their own reasons to do so. We cannot force them to use segwit since using BU may be more profitable to them or they may have other reasons behind that. Segwit needs 95% of the total miners population to get a consensus and that is why or that is probably the reason why did not stick to segwit since it is not yet functioning and being used.

[franky1]

I find it really, really frustrating that you have a room full of otherwise hyperintelligent people, who were told in very clear terms by the Chinese miners what those miners want about a year ago (a hardfork increasing the max blocksize limit for the present type of transactions to at least 2 megabytes), and today, you have the same people asking in frustration why Chinese miners are not adopting segwit when those miners said in bright blinking cleartext a year ago what it is they want, and it is not segwit.

Do you think we must be controlled by Chinese miners? I would prefer decentralization

how it works

pools wont change the rules unless they see unanimous or high majority of nodes will accept any change a pool makes.
otherwise a reject occurs and the change was worthless..

pools dont have power because they need node acceptance.

pools wont decide what to do unless they see nodes want and will accept it.
w are not controlled by pools. but blockstream have by-passed a node vote to make it just a pool vote. so that if the election wins devs can take the glory and say their election wins.. or if not. then blockstream devs can play the victim card and shout racial abuse or suggest that pools are bad communists and that blockstream should do a bilateral split and kill the commi's.

this is why i hate people spouting out the racial slurs of people trying to insinuate the pools are colluding and controlling bitcoin.. because its playing blockstream games even if they the racial taunters oppose blockstream.

hense why it should not have been a node-bypassing vote, and devs wanting only pools to vote. because pools are still going to wait for what nodes want to do even if nodes dont get a vote.

any drastic changes that can cause a node to reject or even not validate at all(blind pass-it-on 'backward compatible') should still be a full hard CONSENSUS vote.

also funny that when talking soft or hard. core love to talk about best case scenario soft but worse case hard.  but never the opposite.
pretending that instead of atleast 6 options there are only 2

softfork: consensus - >94% pools no banning/ignoring of minority. result: small 5% orphan drama then one chain. minority unsynced and dead
softfork: controversial - >50% pools no banning/ignoring of minority. result: long big% orphan drama then one chain. minority unsynced and dead
softfork: bilateral - intentionally ignoring/banning opposing rules and not including them. result: 2 chains

hardfork: consensus - >94% nodes, then >94% pools no banning/ignoring of minority. result: 5% orphan drama then one chain. minority unsynced / dead
hardfork: controversial - >50% nodes, then >50% pools no banning/ignoring of minority. result: big% orphan drama then one chain. minority unsynced / dead
hardfork: bilateral - intentionally ignoring/banning opposing rules and not including them. result: 2 chains


here is the blockstream CTO calling out for a soft. yes soft bilateral split(only needs pools to change something). which ends up causing the a hard bilateral split(nodes banning other nodes and data)

What you are describing is what I and others call a bilateral hardfork-- where both sides reject the other.

I tried to convince the authors of BIP101 to make their proposal bilateral by requiring the sign bit be set in the version in their blocks (existing nodes require it to be unset). Sadly, the proposals authors were aggressively against this.

The ethereum hardfork was bilateral, probably the only thing they did right--

lucky pools and all non-cor implementation devs rejected maxwells proposal. and instead laughed at him for even suggesting it.

here he is again suggesting if pools dont vote his way he will soft bilateral split the network to get his way.

If there is some reason when the users of Bitcoin would rather have it activate at 90%  ... then even with the 95% rule the network could choose to activate it at 90% just by orphaning the blocks of the non-supporters until 95%+ of the remaining blocks signaled activation.

yep soft can also cause split too.

what should have always been the case is a full hard CONSENSUS vote vote.

nodes first, get to 95% to give pools confidence. then pools second to activate and also give the remaining 5% of nodes time to upgrade/decide too.

[Invincible]

If the CHinese miners were not supporting segwit then possibly they have their own reasons to do so. We cannot force them to use segwit since using BU may be more profitable to them or they may have other reasons behind that. Segwit needs 95% of the total miners population to get a consensus and that is why or that is probably the reason why did not stick to segwit since it is not yet functioning and being used.

I think, if we wont achieve that threshold, we must lower it for 75 or something. There're always bad people who try to spoil good things, we must take them into consideration. 25% for them I think would be a fair amount  

[franky1]

If the CHinese miners were not supporting segwit then possibly they have their own reasons to do so. We cannot force them to use segwit since using BU may be more profitable to them or they may have other reasons behind that. Segwit needs 95% of the total miners population to get a consensus and that is why or that is probably the reason why did not stick to segwit since it is not yet functioning and being used.

I think, if we wont achieve that threshold, we must lower it for 75 or something. There're always bad people who try to spoil good things, we must take them into consideration. 25% for them I think would be a fair amount  

though i said it above ill say again. even though nods dont get a vote, pools wont decide unless they see nodes will accept and be able to FULLY VALIDATE the changes

the 95% consensus is not about worry of bilateral split.. its the worry of orphan drama and double spend risk while the orphan drama occures.

the 5% orphan drama (95% acceptance) is similar to the old addage "wait upto 6 confirms before trusting funds are safe".
where as 25% orphan drama (75% acceptance) would end up in more orphan drama of 'wait upto 36 confirms before trusting funds are safe"

[Invincible]

I see that we are not going to easily achieve this consensus and what should we do? What can you suggest?

[BillyBobZorton]

If the CHinese miners were not supporting segwit then possibly they have their own reasons to do so. We cannot force them to use segwit since using BU may be more profitable to them or they may have other reasons behind that. Segwit needs 95% of the total miners population to get a consensus and that is why or that is probably the reason why did not stick to segwit since it is not yet functioning and being used.

Chinese miners and miners in general just want as much profits as possible, so they think that raising the blocksize in any way (including segwit) will deliver less gains in fees, so I think we are stuck with 1mb as long as miners choose to.

I would like segwit to be activated, but miners are too greedy. Oh and forget about a blocksize increase without segwit, will never happen.

[Carlton Banks]

I see that we are not going to easily achieve this consensus and what should we do? What can you suggest?

Why not look at real life, instead of just what 1 person says?


Bitcoin has had dozens of soft-forks, some of which took longer to activate. That's what's happened in the past soft-forks, all programmed with 95% acceptance thresholds. What makes you think this fork will be different?

[franky1]

I see that we are not going to easily achieve this consensus and what should we do? What can you suggest?

seing as there is  a "brand name" civil war of trust.

every implementation should have multiple releases
eg

core 0.13.2 - segwit only
core 0.13.2b - segwit and dynamic blocks
core 0.13.2c - dynamic block only

other implementation - dynamic block only
other implementationb - dynamic block and segwit
other implementationc - segwit only

thus its no longer about "i trust team x" because all teams offer the same choices. it just becomes about what 'feature' people want.

and then
do a proper full hard CONSENSUS vote (node first, pool second)

ultimately the real desire is that instead of needing to down load a full favourite client. people download a .ini file which includes settings changes (as a patch) where by it makes it easier to choose an option without having to resync. due to not needing to download a new client each time.

or even better users can have an options panel and change the settings themselves

[hv_]

I find it really, really frustrating that you have a room full of otherwise hyperintelligent people, who were told in very clear terms by the Chinese miners what those miners want about a year ago (a hardfork increasing the max blocksize limit for the present type of transactions to at least 2 megabytes), and today, you have the same people asking in frustration why Chinese miners are not adopting segwit when those miners said in bright blinking cleartext a year ago what it is they want, and it is not segwit.

Do you think we must be controlled by Chinese miners? I would prefer decentralization

....

pools dont have power because they need node acceptance.

....

I always wonder about this. Running some xxx nodes should be a fraction of costs for pools. If so it should still be easier for pools to achieve majority for some change.

Further I guess pools might fear LN cause here they only get a fraction of the fees.

Could they start blocking those LN-tx ?

[franky1]

I find it really, really frustrating that you have a room full of otherwise hyperintelligent people, who were told in very clear terms by the Chinese miners what those miners want about a year ago (a hardfork increasing the max blocksize limit for the present type of transactions to at least 2 megabytes), and today, you have the same people asking in frustration why Chinese miners are not adopting segwit when those miners said in bright blinking cleartext a year ago what it is they want, and it is not segwit.

Do you think we must be controlled by Chinese miners? I would prefer decentralization

....

pools dont have power because they need node acceptance.

....

I always wonder about this. Running some xxx nodes should be a fraction of costs for pools. If so it should still be easier for pools to achieve majority for some change.

Further I guess pools might fear LN cause here they only get a fraction of the fees.

Could they start blocking those LN-tx ?

yep
nothing stops a pool from just not adding a tx.
like they are not forced to add a tx already. (empty blocks)

instead of being biased about 'zero fee' or bloated tx. they can be biased about multisigs. or sigs with CLTV or CSV included.

funny thing is though. nodes can also be biased. by not relaying such tx's. nodes already wont relay a tx if it doesnt have enough priority or is spending less than a certain amount of satoshis.

this is why core already changed the topology of the network via 'fibre' to counter the node risk of people not relaying tx's to a pool.

[Invincible]

I see that we are not going to easily achieve this consensus and what should we do? What can you suggest?

Why not look at real life, instead of just what 1 person says?


Bitcoin has had dozens of soft-forks, some of which took longer to activate. That's what's happened in the past soft-forks, all programmed with 95% acceptance thresholds. What makes you think this fork will be different?

Because so far I don't see how are we going to overcome BU mining hash power if we dont lower treshold

[franky1]

Because so far I don't see how are we going to overcome BU mining hash power if we dont lower treshold

bu hash power is meaningless.

its the other 60% undecided (due to them intelligently waiting to see what the nodes do first, even if nodes dont get a vote)

i laugh when the banker paid devs. by pass the community. but then blame the lower percentile.

its like the greedy bankers wanting control of the economy but then blame the 1% of citizens for the bankers greed.

the bait and switch and point fingers at the wrong people is a major failure of r/bitcoin/core/blockstream.. they think they are the elite, when they are infact the sheep following the wolf

[Invincible]

I see that we are not going to easily achieve this consensus and what should we do? What can you suggest?

seing as there is  a "brand name" civil war of trust.

every implementation should have multiple releases
eg

core 0.13.2 - segwit only
core 0.13.2b - segwit and dynamic blocks
core 0.13.2c - dynamic block only

other implementation - dynamic block only
other implementationb - dynamic block and segwit
other implementationc - segwit only

And how and when are you going to realise this plan? And what if you can't achieve that?

[franky1]

And how and when are you going to realise this plan? And what if you can't achieve that?

um hello, wakey wakey

core need to release it
other implementations need to release it.

but that involves core dropping their crown and being part of concensus, on an equal playing field with the other implementations

[pereira4]

And you don't see a problem with that? Isn't bitcoin supposed to be more open than that?

Don't get it twisted, what im saying with Core calling the shoots means that they are still the number 1 coders doing all the hard work.

Most BU people are trolls and the software is not as good in any case.

I'm sad to say that I now support and run BU. Core doesn't call the shots anymore because their last few releases aren't being adopted.

Core IS the number one dev team by miles, but they are stubbornly clinging to the poorly supported, overcomplicated, and likely failed Segwit solution, and they are not listening to the miners or the critics. Running BU is the only way to communicate to them that Segwit needs to go away. Meantime, Ver and his team will gain more steam with BU because Core has buried their heads in the sand. Likely we'll be at a deadlock for 6 months+. I think when BU passes Segwit hashrate we might see some debate or compromise proposals. I've already heard talk of merging Segwit with larger block support.

Miners currently benefit from small blocks because fees keep climbing. Anyone who has waited 2 days for their transaction to confirm knows the horrible feeling that is ironically similar to getting your Paypal account banned.  At some point when BTC fees are too high and/or transaction times are unacceptably high, more people will switch to an altcoin like Monero, which has better anonimity than Bitcoin anyway. Bitcoin is running on inertia with name recognition, exchange support, and Wall Street money.

I would be truly saddened if Bitcoin faded into obscurity due to this conflict.

So you think Andreas Antonopulos is wrong? (someone who is always neutral and is learning about bitcoin stuff 24/7)

Get real, the only thing not tested here and proven to fail is BU. If BU gets anywhere notably we are fucked. Segwit is safe compared to BU. BU depends on Core's hard work, if Core stopped updating their software, BU wouldn't have anywhere to rip off and copy and paste code from, it would be the end.

Here is Andreas explaining why segwit is the way to go:


https://medium.com/segwit-co/segregated-witness-and-aligning-economic-incentives-with-resource-costs-7d987b135c00#.yrq6jipqg

[franky1]

Get real, the only thing not tested here and proven to fail is BU.

xt, classic, knots, BU and others are already running on mainnet and have been for months/years.

funny part is. core based pools have a 1% reject/orphan risk everyday..
BU caused one once in a year.

but social drama made a mountain out of a mole hill about a non event.

its a non event because rejects/orphans are a natural thing. its what protects the network

rejecting a block is a good thing. it shows consensus works. it was not a fail event. it was something that happens daily (more so by core pools) and should be applauded that rejects occur. because it shows the network is secure.

[mezzomix]

I see that we are not going to easily achieve this consensus and what should we do? What can you suggest?

Those who want BU fork unconditionally and create a BU Coin. The rest continues with Bitcoin.

[shapeshiftscam]

BU is very unreliable, to implement BU needs a hardfork, hardfork will be extremely negative, after hardfork, bitcoin is not decentralized any more, not reliable or immutable blockchain either. You can see ETHER's price, you will know how much hazard of hardfork will bring to bitcoin.

[franky1]

seems some have no clue.
sound like the usual r/bitcoin script reader. wanting core to centralise and control bitcoin.

I see that we are not going to easily achieve this consensus and what should we do? What can you suggest?

Those who want BU fork unconditionally and create a BU Coin. The rest continues with Bitcoin.

learn consensus, learn diversity, learn decentralisation, learn zero-trust

BU is very unreliable, to implement BU needs a hardfork, hardfork will be extremely negative, after hardfork, bitcoin is not decentralized any more, not reliable or immutable blockchain either. You can see ETHER's price, you will know how much hazard of hardfork will bring to bitcoin.

learn consensus learn bilateral split

learn the difference between the two
spoiler: yep even soft votes can have bilateral splits too