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

Indeed. It will be a genuine hard fork / split, which would split off BU into their own altcoin. Something nice I found on reddit:

Agreed. Well, now we know who is actively trying to harm that.

Then they will do a genuine hard fork and two coins.  But in order to REALLY do so, that means, when they will start producing *incompatible blocks* and mine on one another, they have to realize that they will make an altcoin, losing bitcoin's first mover value proposition, which is essentially the only thing that keeps it number one for the moment.   So I wonder whether they will really do that.  In any case, if they do, there will be two bitcoin chains, two coins.

ETH/ETC all over.

I think it would be a "good thing", because then the market can choose.  But I wonder whether they will dare to do so.
Bitcoin's first mover advantage is still too valuable in my opinion.    It would be great if bitcoin could hard fork into two coins.  But I don't think it will.
They might, by total ignorance of the system, thinking that 51% is imposing its will.  But with a hard fork, that is NOT the case, as the two chains are incompatible.  Non-BU miners will reject their "longest chain" as simply invalid, and build on the valid chain with smaller blocks.  That's how the two prongs of the fork will separate.  I have a hard time thinking that this would happen by ignorance.

All that the BTU coin folks require is 51%. After all, they are entirely convinced that having 51% hash rate equals to being Bitcoin, which is on a level of absurdity not seen in a long time. Do you think that it is not possible for them to reach this number?

I think it won't happen.  Immutability and consensus can only be reached over status quo.

As I said elsewhere, the valuable commodity will not be the coins any more, but the room on the chain.

Guys, I'm not legendary unlike most of you in this thread, and I haven't got as much experience with bitcoin as you but I've just got shocked with this BU and SW things earlyer this week, and I'd like to ask for your help to clarify some things.
Before last weekend  I was usually reading the forum and posting things about my ideas in connection with the future of bitcoin and banking industry, etc, At the end of last week I was waiting for a smaller amount of BTC. While I was waiting, I have realized that my little amount was not confirmed for 24 hours or so (0 confirmation). I was lucky and have used an accelerator at 0:01 AM, and this helped my transaction to get confirmed in the morning, at last.
I started to search for the forum about the possible reasons of this delay, and as I was digging deeper and deeper inside the threads, I just found the problem of the full mempool and the pricy confirmations of the urgent transactions.
As I'm not an expert, please forgive me if I ask you questions like newbies, but I'm really curious now:
Does it really the case that some groups from China spams the network with transactions in order to raise the fees of urgent transactions?
As I understood, that blocks has limited capacity (1MB) to include transactions. The transaction that pays more fee gets priorized (and there's no problem with this).
I saw that there are different solutions to raise the capacity of the blocks, but there's no consensus about the preferred way forward.
My question is:
If we find a solution somehow that fits for everyone in the system, and can raise the block limit, would this solve the problem of spamming the network?
E.g.: if we raise the limit to X MB, what is the guarantee that chinese groups won't fill that X MB capacity too, in order to prevent the fees from falling back to normal?
Before last weekend, I was really positive about the future of bitcoin, and now I'm really worried. Thanks for your help in advance!

yep seems blockstreams next plans are wait for it..
soft(pool) BILATERAL SPLIT (bip9 allows this if u didnt know already)
hard(node and pool) BILATERAL SPLIT (new UASF does this. although the buzzword is meant to make it sound easier to stroke the sheep to sleep by pretending its a "soft" fix)

silly thing is they are really desperate to avoid hard(node and pool) consensus. which the community want so that other features can be added to and then just have one big activation event of everything the entire community want in one go)

but they are willing to do anything to get segwit activated without playing at the same level. even though segwit wont do as promised in any shape or form.(hard,soft / consensus,bilateral)  it just wont do what is promised.

its not segwit 'activation' that fixes anything.
its having everyones transactions only using segwit keys that fix the issues they promised, which will never happen.
malicious people will just stick to native keys. its that simple.
but blockstream have yet to come to that realisation as they have not done enough scenario tests. they have only done 'does it break' tests.. not any real 'does it fix' tests.

funny part is they went soft because of the fake rhetoric of hard consensus leads to a split.
but now willing to do a hard bilateral split to avoid hard consensus... (facepalm)

they are getting desperate.

they are doing all they can to avoid doing something the whole network can agree on. but then try pointing the finger in the other direction while they do the exact things they falsely accuse others of doing.

it has become totally ridiculous

Somehow i'm under the impression that if core would have suggested the changes that come with BU, nobody would discuss them and we would have it up and running already.

Has anyone heard anything about a plan b on how core is going to address the blocksize problem in case SegWit is going to fail / not activated?

Franky is correct.

Basically, sybil attacks are thwarted in Bitcoin because of Proof of Work.
Honest nodes need to control a majority of the hashing power.  That's never changed
and won't change under BU.

An idea worth considering.

you brought up the question of 'malicious actors gaming the system, by running lots of nodes with restrictive settings?'
so im just assuming you mean sybil attack.. and assuming you mean restrictive settings.. where by i gave an example of 500kb..

which is just as likely to happen even now or at anytime in the past it was as likely to have happened.

..
malicious actors gaming the system, by running lots of nodes with restrictive settings is no more or less a threat no different than the last 8 years.
there are many ways to mitigate these threats. EG recognising a jump in node count of nodes using things like amazon servers. and not including them in the tally. that way REAL decentralised nodes decide what the settings are, by simply not caring about amazon server capabilities.

that way the network sticks to what rational/true nodes are ok with

..
most sybil attacks are where people run LITE nodes(not full nodes) but tweak the useragent to look like its a full node to then spam out bad requests.

a simple way to know if a node is a full node could be:
take 3 numbers from 1to 450000...

say 234567, 321234, 432111(randomly chosen at each handshake)
my node could send that. and want a reply. EG the other node has to grab the block hashes of those 3 block through its own blockchain.. sha256 them together and send me the result. which if correct they get whitelisted
(imagine it like a 'are you human' captcha 'select the image of a roadsign....... but an 'are you fullnode' sha the hashes of these 3 blocks' )

it could go one step further.. by asking for tx number 27(randomly chosen at each handshake) of those blocks to sha together the TXID's

most sybil nodes malicious attackers wont shell out $$$ buying thousands of amazon accounts with 100gb data allowance each
so they wont have the blockdata to reply.

however real nodes will have the data. so its as an example just one way to check nodes are actually full nodes.

You mean by compiling a node with a lower block size limit and starting them all over the network?

your talking about the same threat as what could have happened over the last 8 years by sybil attacking the network with lots of 500kb limit nodes

How would BU prevent malicious actors gaming the system, by running lots of nodes with restrictive settings? It would be a node race trying to set the consensus.

many dynamic blocks are envisioning including a 'speedtest' algo that tests their effectiveness to notice a new block download it, validate it and relay it out and set a score of start to end.
then use that to help flag the upper limit. they will accept which becomes consensus.h
where by they then have the lower limit policy.h has the prefered size as acceptable safety which can automaticaly grow at need BELOW the ultimate limit

this using the network consensus by x% flagging big no no to Xmb pools wont then make Xmb. thus not killing off nodes. and where nodes abilities as technology and telecommunications improve over the years allows the network t grow at an acceptable natural and progressive amount

(EG raspberryPi3 even behind the china firewall can handle 8mb blocks.. so a 8mb consensus.h and a 2mb policy.h to begin with which can increase naturally upto 8mb without having to manually do anything)
meaning pools would then go from 1mb.. and try 1.001mb to test the water and increment to say 1.99mb before worrying about orphans. and then the automated moving of the policy.h can occur. all while blocks are way below 8mb

do not be fooled by the "visa by midnight" "gigabyte by midnight" "servers by midnight" rhetoric that blockstreamers are spewing out when they exaggerate satoshis words to fit a fake narative that bitcoin needs to commercialise and centralise to survive

Here is one idea of scalability and transaction rate. It's quite old:

https://bitcointalksearch.org/topic/m.6306

For it to work though, I don't think we can allow blockchains demand to exceed capacity, or for mempools to forget transactions for bitcoin service providers, or for nodes to be selective on the transactions they relay.

using gmaxwells words(not verbatim)
'BU is just a core 0.12 copy and paste job with a few minimal changes...'

well thats just proof that offering more capacity doesnt require a total game changing re-write of the entire thing, doesnt require "upstream filters" doesnt require new keys, doesnt require users moving funds to new keys just to see a feature, doesnt require intentionally banning nodes.

 

So chilled with laudbankbraking words:

BU is much more Satoshi consensus like than anything else (= hacked agenda stuff ) we ve seen before?

 

what your quoting of my quote of a quote.. is:
1. breaking the "backward compatible" promise - yea i laughed reading they will literally want to ban blocks because they are not segwit branded even if the data was valid

2. causes a split in the network. yep i laughed that even going soft can cause a bilateral split. breaking the promise that going soft avoids such drama