Bitcoin Exchanges Unveil Emergency Hard Fork Contingency Plan

[jbreher]

We are:

Bitfinex, Bitstamp, BTCC, Bitso, Bitsquare, Bitonic, Bitbank, Coinfloor, Coincheck, itBit, QuadrigaCX, Bitt, Bittrex, Kraken, Ripio, ShapeShift, The Rock Trading and Zaif

Wow, this is huge.  This means payment systems will still be operating on core? 

Well, what it really says is that all these exchanges plan on listing BU.

Disclaimer: at least two of the signatories have since announced that the text was changed after they assented to signing.

If there was something in the BU protocol that makes a BU transaction not compatible with a blockstream coin transaction, then this would solve the problem.

Yes, but it would also gratuitously make BU 'not Bitcoin'. So it likely will not be implemented by BU. Clients already have all tools necessary for avoiding replay at their disposal. No protocol change needed.

Yes but Brian Armstrong already declared his support for Core and Segwit activation months ago and that presumably is the unofficial statement from Coinbase.

There we have it, the top exchanges declaring their support for Core. Those people must know what is really going on. Behind all the technical argument, there is really politics.

Well, no:

If one chain receives an overwhelming majority of support from miners, users, and exchanges, we reserve the right to alter the name of chains or discontinue support for certain chains in the future. - GDAX (Coinbase)

source: https://blog.gdax.com/https-medium-com-adamlwhite-bitcoinhardfork-3f6ac05ceec6#.9eyge9yg0

Miners don't want BU either.

Over 40% of the last 24 hour's blocks are signaling large block compatibility. 12 hours ago, it was even over half. Seems resistance to BU in the mining community is nowhere near universal. (https://coin.dance/blocks)

If Satoshi is adamantly against BU (and there are reasons to think he is)

I'd like to know what reasons there are to believe that "Satoshi is adamantly against BU".

he could dump it into the ground. ... He might help core by dumping on BU

He just as plausibly might help BU by dumping on core. Not that I think either eventuality is very plausible.

also pools wont just jump straight to 2mb on activation day. pools will try a 1.000250 block and see the orphan risk.

Possible, but I doubt it. Part of the fork dynamics is dependent upon BU delivering greater value. If BU forks at 75%, then the 1MB chain will be about a 40 minute average block time, delivering 25% of its pre-fork throughput. With a corresponding rise in fees due to the rise in blockspace supply. The BU chain will be about 13 minute average block time. If BU stayed near its pre-fork block size, its throughput would be on the order of 76% of its pre-fork throughput. If, however, BU went straight to 2MB, then it would deliver 150% of its pre-fork throughput. With corresponding drop in fees. Blowing through the backlog in relatively short time. Cheaper transactions, more transactions: greater value. Leading to increased incentive for fence-sitters to throw in to the BU side.

Future increases may be more probing, and therefore incremental. But I would expect the 2MB immediately. They'll fall after the backlog is cleared.

Dumping almost 1 million Bitcoin is "temporary price drama"?

Well, yes. That's exactly what it is. It would certainly be dramatic, price would tank, effect would be temporary. Kind of definitional, that.

In a proof of work system, the consensus is made by those providing proof of work.  But ultimately they will take into account those that pay for the joke, that is, the users in the market.  And that's it.

Yes, but you are arguing against religious fundamentalists.

Tell me how nodes impose their will onto miners, if miners come to a consensus.

Um... by retroactively claiming that what the miners have done is exactly what the nodes wanted all along?

[franky1]

also pools wont just jump straight to 2mb on activation day. pools will try a 1.000250 block and see the orphan risk.

Possible, but I doubt it. Part of the fork dynamics is dependent upon BU delivering greater value. If BU forks at 75%, then the 1MB chain will be about a 40 minute average block time, delivering 25% of its pre-fork throughput. With a corresponding rise in fees due to the rise in blockspace supply. The BU chain will be about 13 minute average block time. If BU stayed near its pre-fork block size, its throughput would be on the order of 76% of its pre-fork throughput. If, however, BU went straight to 2MB, then it would deliver 150% of its pre-fork throughput. With corresponding drop in fees. Blowing through the backlog in relatively short time. Cheaper transactions, more transactions: greater value. Leading to increased incentive for fence-sitters to throw in to the BU side.

Future increases may be more probing, and therefore incremental. But I would expect the 2MB immediately. They'll fall after the backlog is cleared.

the maths does not work that linearly.

EG if there are 4 pools of equal hash. it does not mean take one away and the time moves to 20 minutes. because the competition may have only been only seconds behind getting their own solution.
bitcoins are not mined based on the combined hashpower of the network. each pool makes their own effort. and the "75%" you mentioned is not 1 pools.

here this image will make it a bit clearer

as you can see 75% of blocks is just HALF the network hashrate in this example,(top half of image) but the block
timings still are reasonable whichever way you play it(bottom half when they have split)

[jbreher]

also pools wont just jump straight to 2mb on activation day. pools will try a 1.000250 block and see the orphan risk.

Possible, but I doubt it. Part of the fork dynamics is dependent upon BU delivering greater value. If BU forks at 75%, then the 1MB chain will be about a 40 minute average block time, delivering 25% of its pre-fork throughput. With a corresponding rise in fees due to the rise in blockspace supply. The BU chain will be about 13 minute average block time. If BU stayed near its pre-fork block size, its throughput would be on the order of 76% of its pre-fork throughput. If, however, BU went straight to 2MB, then it would deliver 150% of its pre-fork throughput. With corresponding drop in fees. Blowing through the backlog in relatively short time. Cheaper transactions, more transactions: greater value. Leading to increased incentive for fence-sitters to throw in to the BU side.

Future increases may be more probing, and therefore incremental. But I would expect the 2MB immediately. They'll fall after the backlog is cleared.

the maths does not work that linearly.

EG if there are 4 pools of equal hash. it does not mean take one away and the time moves to 20 minutes. because the competition may have only been only seconds behind getting their own solution.
bitcoins are not mined based on the combined hashpower of the network. each pool makes their own effort. and the "75%" you mentioned is not 1 pools.

here this image will make it a bit clearer
https://i.imgur.com/tcAFVCH.png
as you can see 75% of blocks is just HALF the network hashrate in this example,(top half of image) but the block
timings still are reasonable whichever way you play it(bottom half when they have split)

Well, no, it does not make it clearer. However, it is peripheral to my point. Which is that it is unlikely that BU miners will creep up initially. They will likely go straight to 2MB. For as long as it takes to clear the transaction backlog. For such would deliver a demonstrably better user experience (faster cheaper transaction processing) relative to the other chain.

Yes, further increases may be likely to be more incremental in nature.

[franky1]

Well, no, it does not make it clearer. However, it is peripheral to my point. Which is that it is unlikely that BU miners will creep up initially. They will likely go straight to 2MB. For as long as it takes to clear the transaction backlog. For such would deliver a demonstrably better user experience (faster cheaper transaction processing) relative to the other chain.

Yes, further increases may be likely to be more incremental in nature.

they would actually creep up in increments, thats the smart thing. (as the 500k berkely locks/levelbdb upgrade drama has taught the community)
they done so in the past.(policy.h v0.7 0.5mb, policy.h v0.8 0.75mb, now 0.999mb)

but here is where your missing a few idea's

moving at say 250byte a block increments, means they can reasonably safely get to 2mb in about a month.
so it wont be 2mb activation day .. and it wont be 2mb by 2020 by being slow about the increments.

250byte per block increments = 4 weeks-ish
500byte per block increments = 2 weeks-ish
1kb per block increments = a week-ish

they may even once say the first few blocks above 1mb havnt caused issues. increment it in 0.25mb increments. taking possibly a day or less to get to 2mb... but one thing is for sure they wont just jump to 2mb straight off. they will see if there are unknown bugs/orphan risks etc

so not that long when you think about it

[Lauda]

These blood letting portends no good experience for the average user, whales stands to buy back at ridiculous low prices, while average joe might have had a chunk of his worth and purchasing power gone with the wind. What to do now Guess the time is ripe for migration while these two elephants make a show of their sizes.

Any 'average user' can do the same as those whales. You just need to sell on time and buy back in at a lower rate.

Sad? Why would it be sad? The big blockers are saying that a fork is "healthy" and at some point, to make everyone happy, it is unavoidable. S
-snip-

The fork is everything but healthy.

I know one person, who is a long time Bitcoiner, who has the capability to do something like that. He is also rumored to be the guy who hacked the DAO. He is kind of an eccentric but he is very smart. I am scared to mention his name in public and I do not know if I should. But I would happily give it to you through pm.

Don't do that.

they may even once say the first few blocks above 1mb havnt caused issues. increment it in 0.25mb increments. taking possibly a day or less to get to 2mb... but one thing is for sure they wont just jump to 2mb -straight off. they will see if there are unknown bugs/orphan risks etc
-snip-

Slow increments will not reveal all possible exploits. They will be revealed once someone attempts to use them, at which time damage has already started occuring.

[franky1]

they may even once say the first few blocks above 1mb havnt caused issues. increment it in 0.25mb increments. taking possibly a day or less to get to 2mb... but one thing is for sure they wont just jump to 2mb -straight off. they will see if there are unknown bugs/orphan risks etc
-snip-

Slow increments will not reveal all possible exploits. They will be revealed once someone attempts to use them, at which time damage has already started occuring.

lets say there was another Leveldb 2013 episode, but this time at 1.2mb
the pools dont know its 1.2 yet though

now would pools jump to 2mb where there might be hit by that bug AND say 5 other propagation issues aswell all in one swoop of mega F*ck-ups and then have to tear up and remake a 1mb block with half as many tx's to try again..
or wrongly guess that it must be an issue at 2mb so try 1.9mb and have that block too throwing a tantrum in the orphanage, then try 1.8 and so on all creating orphan tantrums trying to find a new 'sweetspot' that is acceptable(to potential knitpicker: yes i know bitcoin doesnt have an actual 'orphanage' place, im just entertaining wordplay of 'orphan drama' to entertain the imaginations of people with short attention span)
or logically

start in small increments. and when hitting 1.200250mb.. the block causes orphans. so they just take 1tx (250bytes) out of their list and try again. knowing to not pass 1.2mb while things get sorted.
then later when sorted they go again. safely knowing at most its only going to cause minimal disruption... rather then several orphans of going straight to 2mb and haviing to work its way down trying to find a sweet spot. without instantly knowing whats a good or bad size to run with(apart from 1mb again)

[BitDane]

This thing might have been answered several times but still I cannot understand why do we need a hardfork when softfork is available,  aside from that, is  it really necessary that a hardfork is needed In order to upgrade bitcoin features?  Sorry for being so noob about this but I do believe that there is a strong reason why these exchanges are so against the hardfork.

[Lauda]

now would pools jump to 2mb where there might be hit by that bug AND say 5 other propagation issues aswell all in one swoop of mega F*ck-ups and then have to tear up and remake a 1mb block with half as many tx's to try again..
or wrongly guess that it must be an issue at 2mb so try 1.9mb and have that block too throwing a tantrum in the orphanage, then try 1.8 and so on all creating orphan tantrums trying to find a new 'sweetspot' that is acceptable(to potential knitpicker: yes i know bitcoin doesnt have an actual 'orphanage' place, im just entertaining wordplay of 'orphan drama' to entertain the imaginations of people with short attention span)

Are you saying that the network participants should put *trust* into the miners in hopes that they don't centralize in order to reduce orphans, but rather produce smaller blocks?

This thing might have been answered several times but still I cannot understand why do we need a hardfork when softfork is available, 

We don't.

aside from that, is  it really necessary that a hardfork is needed In order to upgrade bitcoin features? 

No. Well, some things can't be done with a soft fork but there aren't any planned hard forks that 'upgrade' existing or add new features.

[franky1]

This thing might have been answered several times but still I cannot understand why do we need a hardfork when softfork is available,  aside from that, is  it really necessary that a hardfork is needed In order to upgrade bitcoin features?  Sorry for being so noob about this but I do believe that there is a strong reason why these exchanges are so against the hardfork.

though soft methods are available. where by the pools get to vote.
nodes matter. if there are not a good amount of nodes validating the data diversely than data could be corrupted by one party saying "follow me" and non validators blindly accept them. this is a risk

nodes are important. and we should not aimlessly let the node count be turned into a TIER network of one brand setting the rules and other brands playing pass the parcel of data its not checking.

some soft methods are acceptable because its not changing anything fundamental and still allows the PEER network to check the data and strike off blocks it doesnt approve of.

however in a TIER network some nodes are nothing more then unreliable data stores. so worthless as a security measure and thus no point being a node.

when something rule changing occurs its always best to have good node acceptability first for security purposes of avoiding corruption and to give pools confidence that what pools build will be accepted with full validation.

core however bypassed letting full nodes have a vote on what should be valid. by implying a TIER network where core implementations validate the block that core set new rules to. and then core will strip that block and twist the data to blindly pass other nodes.. not as valid or invalid.. just out of scope of other nodes tests would pass or fail, so blindly kept not due to being fully validated but by not triggering certain old alerts.

this is dangerous.
also by making it easier to do soft patches. is a network security risk because thats where trojan horse attacks can happen even more easily..
by simply not triggering the rules due to finding the hole in the defence to continue unnoticed

core think its good because it allows them an easier life.. but it makes it an easier life for attackers too

[Xester]

also pools wont just jump straight to 2mb on activation day. pools will try a 1.000250 block and see the orphan risk.

Possible, but I doubt it. Part of the fork dynamics is dependent upon BU delivering greater value. If BU forks at 75%, then the 1MB chain will be about a 40 minute average block time, delivering 25% of its pre-fork throughput. With a corresponding rise in fees due to the rise in blockspace supply. The BU chain will be about 13 minute average block time. If BU stayed near its pre-fork block size, its throughput would be on the order of 76% of its pre-fork throughput. If, however, BU went straight to 2MB, then it would deliver 150% of its pre-fork throughput. With corresponding drop in fees. Blowing through the backlog in relatively short time. Cheaper transactions, more transactions: greater value. Leading to increased incentive for fence-sitters to throw in to the BU side.

Future increases may be more probing, and therefore incremental. But I would expect the 2MB immediately. They'll fall after the backlog is cleared.

the maths does not work that linearly.

EG if there are 4 pools of equal hash. it does not mean take one away and the time moves to 20 minutes. because the competition may have only been only seconds behind getting their own solution.
bitcoins are not mined based on the combined hashpower of the network. each pool makes their own effort. and the "75%" you mentioned is not 1 pools.

here this image will make it a bit clearer
https://i.imgur.com/tcAFVCH.png
as you can see 75% of blocks is just HALF the network hashrate in this example,(top half of image) but the block
timings still are reasonable whichever way you play it(bottom half when they have split)

Well, no, it does not make it clearer. However, it is peripheral to my point. Which is that it is unlikely that BU miners will creep up initially. They will likely go straight to 2MB. For as long as it takes to clear the transaction backlog. For such would deliver a demonstrably better user experience (faster cheaper transaction processing) relative to the other chain.

Yes, further increases may be likely to be more incremental in nature.

There is no clear statement as to BU miners will adopt 2MB blocksize. But we can expect some major changes and changing of sides when the time comes. There is a high possibility that some BU miners will go to the side of the core developers and will support segwit in the last moment. Or perhaps some supporter of the core developers will transfer to bitcoin unlimited. It is not impossible but let us wait in the final moment to see what will happen.

[dinofelis]

Are you saying that the network participants should put *trust* into the miners in hopes that they don't centralize in order to reduce orphans, but rather produce smaller blocks?

They already did that when they joined a PoW consensus rule system.  (the putting their trust, I mean, not their hopes: hopes are whatever you want them to be).

[franky1]

now would pools jump to 2mb where there might be hit by that bug AND say 5 other propagation issues aswell all in one swoop of mega F*ck-ups and then have to tear up and remake a 1mb block with half as many tx's to try again..
or wrongly guess that it must be an issue at 2mb so try 1.9mb and have that block too throwing a tantrum in the orphanage, then try 1.8 and so on all creating orphan tantrums trying to find a new 'sweetspot' that is acceptable(to potential knitpicker: yes i know bitcoin doesnt have an actual 'orphanage' place, im just entertaining wordplay of 'orphan drama' to entertain the imaginations of people with short attention span)

Are you saying that the network participants should put *trust* into the miners in hopes that they don't centralize in order to reduce orphans, but rather produce smaller blocks?

what are you even on about "centralize"
the pools earn more by competing.
1. jumping to 2mb instantly makes propagation delays and loses the competitive advantage. so pools will move in small increments to keep their competitive advantage
2. no point jumping to 2mb because there may be several bugs and if going to 2mb then down hoping to find a sweet spot can cost them multiple blocks of wasted time.. can cause many orphans.. due to bugs and propagation.
3. going up from 1mb in small amounts reduces orphan risks and keeps a good grasp of acceptable propagation times.

oh and if you think that going from 1mb to 2mb in small increments of 250bytes would take years.. and thats your real argument im betting.
your wrong. it can take a month of safe testing the water with least orphan risks and least cost to pools and their competitive edge.
increments of 1kb can get to 2mb in a week and increments of 0.25mb can get to 2mb in under an hour

so relax. its best to be safe.. rather then have been waiting years just to get a chance and then try to rush things in 1 block or 1 hour.
1 extra month of good practice safe increments isnt gonna kill bitcoin. but jumping straight to 2mb could cause another 2013 event.
pools are smart enough to know this

[LeGaulois]

I am starting to feel sad for Bitcoin and loosing my optimist side about it. I guess Bitcoin is on the road to know its dark days. I am not surprised to see some trying to takr control over the newtork but wtf.

[BitDane]

This thing might have been answered several times but still I cannot understand why do we need a hardfork when softfork is available,  aside from that, is  it really necessary that a hardfork is needed In order to upgrade bitcoin features?  Sorry for being so noob about this but I do believe that there is a strong reason why these exchanges are so against the hardfork.

though soft methods are available. where by the pools get to vote.
nodes matter. if there are not a good amount of nodes validating the data diversely than data could be corrupted by one party saying "follow me" and non validators blindly accept them. this is a risk

nodes are important. and we should not aimlessly let the node count be turned into a TIER network of one brand setting the rules and other brands playing pass the parcel of data its not checking.

Since you said that nodes matter, I do think Bitcoin Core had been fair here by bypassing node voting since as far as I can see majority of nodes support/uses Bitcoin Core features.  If they use it (letting node vote than miners) the possibility of Segwit being implemented is bigger than letting the miners to vote for the implementation.  (That is if I understand it right)

aside from that, is  it really necessary that a hardfork is needed In order to upgrade bitcoin features?  

No. Well, some things can't be done with a soft fork but there aren't any planned hard forks that 'upgrade' existing or add new features.

I get  this as Bitcoin Core believe that hardfork is not needed for the added update / upgrade for the Bitcoin features regarding scaling issue of Bitcoin.  I also read that even with implementation of Segwit the onchain spam won't be solved is that true?

[centralbanksequalsbombs]

Since you said that nodes matter, I do think Bitcoin Core had been fair here by bypassing node voting since as far as I can see majority of nodes support/uses Bitcoin Core features.  If they use it (letting node vote than miners) the possibility of Segwit being implemented is bigger than letting the miners to vote for the implementation.  (That is if I understand it right)

I get  this as Bitcoin Core believe that hardfork is not needed for the added update / upgrade for the Bitcoin features regarding scaling issue of Bitcoin.  I also read that even with implementation of Segwit the onchain spam won't be solved is that true?

Yes, currently miners have every incentive to keep integrity to the bitcoin network - if bitcoin is attacked or changed, bitcoin price would plummet, bitcoin would not only lose uniqueness to other altcoins, but would also quickly turn those miners' business into bankruptcy.

Blocksize at 1mb keeps things secure and helps limit the onchain spam.

For anyone new or simply wanting to expand a bit more about bitcoin, I try to touch on a few of these points (and others) on post titled
"Hacks & puppets & forks - how to destroy bitcoin" https://bitcointalk.org/index.php?topic=1834310.0

[mayax]

in the end, money talks.   

[Carlton Banks]

in the end, money talks.   

and the bullshit will walk

[mayax]

in the end, money talks.   

and the bullshit will walk

maybe...you know better