The real disastor that could happen (forking Bitcoin)...

[CuntChocula]

So if the chain does fork, how will we know it has happened, and how will we know who has "won".

You won't. Because you don't need to. That's the beauty of Bitcoin

[Jet Cash]

For a start I predict it will cause all exchanges to "stop trading" (as they will not want to risk fiat losses in case they have ended up on the wrong fork).

They are in it for profits so why wouldn't they just allow trading between the two different chains and make lots of fiat money in the process?

I guess the obvious answer to the above question is that most exchanges are inept.

Surely that would not be possible. Won't some transactions appear in both chains, and some old bitcoins be spent in different transactions in each chain. Am I correct in assuming that only the longest chain will survive? What will happen to the shortest chain additions? Will they be deleted and the process start again?

Here is another newbie question? If one chain contains blocks up to 1Mb and the other contains all those blocks plus the 2Mb blocks, won't the 2Mb chain be longer no matter who accepts the proposals?

[Lauda]

Won't some transactions appear in both chains, and some old bitcoins be spent in different transactions in each chain. Am I correct in assuming that only the longest chain will survive? What will happen to the shortest chain additions? Will they be deleted and the process start again?

Chain A splits into Chain A (1 MB) and Chain B (2 MB). If you had coins on Chain A now you will have coins on both chains. The problem with the minority chain is the huge difficulty that the remaining miners will be faced with.

Here is another newbie question? If one chain contains blocks up to 1Mb and the other contains all those blocks plus the 2Mb blocks, won't the 2Mb chain be longer no matter who accepts the proposals?

It will be, but that won't matter in the case of a hard fork if you're stuck on an old version.

[Jet Cash]

Sorry, I'm in trouble understanding the split. If the existing chain is C, and it forks in C1 and C2, there will be miners supporting C1 and others supporting C2. I can see that all coins in C will appear in both chains, but won't the transactions after the fork be mixed between C1 and C2, so some will be duplicated, and some may be lost.

Another thing I don't understand. It obviously takes longer to build a 2Mb block than a 1Mb block, as submission time seems to be important to miners, why would any miner risk losing his slot by building a 2Mb block?

[Lauda]

Sorry, I'm in trouble understanding the split. If the existing chain is C, and it forks in C1 and C2, there will be miners supporting C1 and others supporting C2. I can see that all coins in C will appear in both chains, but won't the transactions after the fork be mixed between C1 and C2, so some will be duplicated, and some may be lost.

A hardfork is a change to the bitcoin protocol that makes previously invalid blocks/transactions valid, and therefore requires all users to upgrade.

You can't transact from chain C2 to C1 or vice versa. C1 chain should not accept C2 transactions.

Another thing I don't understand. It obviously takes longer to build a 2Mb block than a 1Mb block, as submission time seems to be important to miners, why would any miner risk losing his slot by building a 2Mb block?

If the hard fork was done properly it would not cause a split but rather an upgrade, that's how the system evolves. With a high and reachable consensus threshold (e.g. 95%) and a long time period for upgrading, essentially almost everyone would be on the chain and there is a minimum risk of damage. In this scenario miners on the 2 MB chain would not risk anything since everyone else is mining it too (unless some impose soft limits again).

[franky1]

Lauda and Ciyam. are forgetting that Orphans will happen to rejoin any differing chains. thus no long term hard fork.

the only time there would be consistant 2 competing chains that never recombine. is if the implementations hand pick the miners they relay from and ignore the other miners.

EG Core only connects to miners that produce 1mb blocks.. classic only connects to 2mb miners and ignores 1mb miners.
(which is the doomsday scenario lauda and ciyam are pushing.. intensionally)

otherwise if they do get blocks from any random miner.. the orphaning part of the block game will sort out forks and re-align the chain.
also 2mb implementations are able to accept 1mb blocks because the rule is not >1mb <2mb...   its just 0 to 2mb (anything in between)
so dont fall for the crap that 2mb implementations wont see blocks from 1mb miners.

again that would only happen if 2mb implementations naferiously ignored 1mb completely. (which is not the case in a simple 2mb increase clean code)

the only losers will be the miners that jumped the gun and made bigger blocks before consensus was reached. and so their orphaned blocks become unspendable.

easy explanation without waffle..(A and B=1mb miners, C=2mb miners, all implementations read blocks from all miners)


so lauda and ciyam. try your fear mongering again.. but add in the context of orphaning.. to show its not as disastrous as you seem to want to make it appear

[bitlost]

So if the chain does fork, how will we know it has happened, and how will we know who has "won".

You won't. Because you don't need to. That's the beauty of Bitcoin

But what about the prediction of exchanges stopping trades? That would affect every user, since price would take a serious impact, no?

[Lauda]

But what about the prediction of exchanges stopping trades? That would affect every user, since price would take a serious impact, no?

That's speculation; it is a possibility but that would probably be temporary. We've seen exchanges halt trading before, nothing special about it.

[CuntChocula]

But what about the prediction of exchanges stopping trades? That would affect every user, since price would take a serious impact, no?

That's speculation; it is a possibility but that would probably be temporary. We've seen exchanges halt trading before, nothing special about it.

+1. As Lauda pointed out, exchanges can halt trading for no reason at all. I mean, look at Mt.Gox. This is all part and parcel of being on the bleeding edge of disruptive technology known as Bitcoin. I believe it was Ludwig Heinrich Edler von Mises who said "Life is like a box of chocolates. You never know what you're gonna get."

[achow101]

Lauda and Ciyam. are forgetting that Orphans will happen to rejoin any differing chains. thus no long term hard fork.

the only time there would be consistant 2 competing chains that never recombine. is if the implementations hand pick the miners they relay from and ignore the other miners.

EG Core only connects to miners that produce 1mb blocks.. classic only connects to 2mb miners and ignores 1mb miners.
(which is the doomsday scenario lauda and ciyam are pushing.. intensionally)

otherwise if they do get blocks from any random miner.. the orphaning part of the block game will sort out forks and re-align the chain.
also 2mb implementations are able to accept 1mb blocks because the rule is not >1mb <2mb...   its just 0 to 2mb (anything in between)
so dont fall for the crap that 2mb implementations wont see blocks from 1mb miners.

again that would only happen if 2mb implementations naferiously ignored 1mb completely. (which is not the case in a simple 2mb increase clean code)

the only losers will be the miners that jumped the gun and made bigger blocks before consensus was reached. and so their orphaned blocks become unspendable.

easy explanation without waffle..(A and B=1mb miners, C=2mb miners, all implementations read blocks from all miners)


so lauda and ciyam. try your fear mongering again.. but add in the context of orphaning.. to show its not as disastrous as you seem to want to make it appear

Not necessarily. While that could happen if there was a roughly even split of the hash power, if one side of the fork has more than the other e.g. 75% vs. 25%, then that scenario is no likely to happen. The fork with the greater hash power will extend their chain to become longer than the fork with less hash power. Since their blockchain would be longer, it is considered valid over the other blockchain. However, for not upgraded nodes, that longer chain would be invalid since it would contain blocks larger than 1 Mb.

Furthermore, depending on the forking mechanism, this may not be possible at all. If they use the forking mechanism which invalidates older versioned blocks (as is used now with soft forks), then any blocks produced by the old miners will be invalid because their version numbers are too old. If checkpointing is also used, then this scenario is not possible since one fork would have a history that the other fork does not. Due to the checkpoints, the upgraded miners would not be able to go back to the other fork which is what you are saying would happen.

[franky1]

Not necessarily. While that could happen if there was a roughly even split of the hash power, if one side of the fork has more than the other e.g. 75% vs. 25%, then that scenario is no likely to happen. The fork with the greater hash power will extend their chain to become longer than the fork with less hash power. Since their blockchain would be longer, it is considered valid over the other blockchain. However, for not upgraded nodes, that longer chain would be invalid since it would contain blocks larger than 1 Mb.

but then the flip side is that the whole second doomsday scenario lauda and ciyam suggest, which is that bigger blocks take longer to process.
(yep im using their own disaster theories against them)
and so the smaller miners would by default produce more blocks and so they would gain the blockheight, just by having less data to validate.
2mb miners would need to be ALOT more powerful than 1mb to gain the lead if there was not consensus
so as you said its all about the consensus and hashing power. and not a simple "2mb are evil doomsday".

Furthermore, depending on the forking mechanism, this may not be possible at all. If they use the forking mechanism which invalidates older versioned blocks (as is used now with soft forks), then any blocks produced by the old miners will be invalid because their version numbers are too old. If checkpointing is also used, then this scenario is not possible since one fork would have a history that the other fork does not. Due to the checkpoints, the upgraded miners would not be able to go back to the other fork which is what you are saying would happen.

exactly only in a change to the 'forking mechanism'(your words) to ignore older clients. and where the new 2mb miners have sufficiently more hash power to get ahead of the other miners with less processing time... and enough of the community of nodes not orphaning it. would we see the 2mb blocks win..

so as i said its not a doomsday event as soon as 2mb blocks hit the network. it requires extra things to occur, some nefarious some involving dominance in hashing power and some involving enough node acceptance..

otherwise miners are just wasting more than 10 minutes making blocks that get orphaned if they basically dont get consensus or have enough power to stay ahead of the other miners every time.

i do see exchanges halting their service because orphans can make so called 1confirmed transactions suddenly become unconfirmed again. so they wont want to risk it.. or atleast raise the threshold to a higher number of confirmations before crediting customers with funds.

(sidenote: which is another reason not to trust 0 confirms or 1 confirms if your buying a porsche or a house. the risk of that exact block being an orphan today is about 2%(3 orphans a day(144 blocks) at the moment) the risk of orphans during a blocksize battle could be as much as <insert high number here>)

and lastly.. i think that if we ignore the nefarious miner doomsday scenario's..
and stick with logic and greed, miners wont be making 1.005mb blocks until they know consensus has been reached, to protect their revenues from becoming unspendable. .. which is another factor to take into account that its not a doomsday scenario. but more like paranoid hypothesis of nefarious factors all colluding into one targetted agenda

[achow101]

but then the flip side is that the whole second doomsday scenario lauda and ciyam suggest, which is that bigger blocks take longer to process.
(yep im using their own disaster theories against them)
and so the smaller miners would by default produce more blocks and so they would gain the blockheight, just by having less data to validate.
2mb miners would need to be ALOT more powerful than 1mb to gain the lead if there was not consensus
so as you said its all about the consensus and hashing power. and not a simple "2mb are evil doomsday".

I don't think 2 Mb blocks will require any significant increase in processing time. There will be an increase, but it will probably be negligible. Any ways, most miners are SPV mining so that doesn't affect them at all.

exactly only in a change to the 'forking mechanism'(your words) to ignore older clients. and where the new 2mb miners have sufficiently more hash power to get ahead of the other miners with less processing time... and enough of the community of nodes not orphaning it. would we see the 2mb blocks win..

Well that mechanism (marking all older versioned blocks as invalid) is the current standard way to deploy soft forks. I think it will be the same for hard forks as well.

so as i said its not a doomsday event as soon as 2mb blocks hit the network. it requires extra things to occur, some nefarious some involving dominance in hashing power and some involving enough node acceptance..

Right, but the split is not going to be 50/50. There will be a skew towards one side, and that skew will be enough to cause one fork to grow faster than the other. That is enough to cause a fork to two blockchains. If the big blocks blockchain is longer, then two chains will exist. If the small blocks blockchain is longer, then there may be a blockchain reorg in big blocks nodes that will force them down to the small blocks blockchain, but, for some period of time in between, it is in fact likely that two blockchains will coexist for some time.

otherwise miners are just wasting more than 10 minutes making blocks that get orphaned if they basically dont get consensus or have enough power to stay ahead of the other miners every time.

i do see exchanges halting their service because orphans can make so called 1confirmed transactions suddenly become unconfirmed again. so they wont want to risk it.. or atleast raise the threshold to a higher number of confirmations before crediting customers with funds.

(sidenote: which is another reason not to trust 0 confirms or 1 confirms if your buying a porsche or a house. the risk of that exact block being an orphan today is about 2%(3 orphans a day(144 blocks) at the moment) the risk of orphans during a blocksize battle could be as much as <insert high number here>)

and lastly.. i think that if we ignore the nefarious miner doomsday scenario's..
and stick with logic and greed, miners wont be making 1.005mb blocks until they know consensus has been reached, to protect their revenues from becoming unspendable. .. which is another factor to take into account that its not a doomsday scenario. but more like paranoid hypothesis of nefarious factors all colluding into one targetted agenda

Generally waiting for a few confirmations is a good idea anyways.

[jbreher]

The amount of electricity that miners are paying for is so large that they will most likely shut down their hashing operations if the exchanges have closed down which will reduce the difficulty (in two weeks).

After two weeks if the problem hasn't been worked out then everyone is basically going to walk away and the Bitcoin experiment will be declared a failure.

Did you buy this account? Your recent posts don't strike me as the CIYAM of old.

For one, why do you think 'two weeks' is in any way relevant?

[jonald_fyookball]

Exchanges wont shut down.   very few anyway.  Certainly not all of them.  Will the market be volatile and crazy? Possibly.   But there will always be entrepreneurs looking for opportunities.

[jbreher]

the consensus threshold is 75% and the grace period is 4 weeks (IIRC). This means, that they expect that the whole industry to upgrade in a very short amount of time. This is ridiculous; we can't even get the miners to agree on a single soft fork in that matter of time.

Would it help if I point out that, if the 75% threshold is reached, then 75% of miners (+/-) would have already upgraded?

[achow101]

the consensus threshold is 75% and the grace period is 4 weeks (IIRC). This means, that they expect that the whole industry to upgrade in a very short amount of time. This is ridiculous; we can't even get the miners to agree on a single soft fork in that matter of time.

Would it help if I point out that, if the 75% threshold is reached, then 75% of miners (+/-) would have already upgraded?

The 75% threshold is too low. Why should soft forks deploy with 95% but hard forks deploy with 75%? It is too low and there are too many miners still mining the old chain who would be able to keep that chain alive while the new one kept going. It is not proper deployment of a change in the consensus, which should require consensus (realistically the supermajority) to change.

[jbreher]

Why should soft forks deploy with 95% but hard forks deploy with 75%?

Why do you claim that soft forks deploy with 95%?

[achow101]

Why should soft forks deploy with 95% but hard forks deploy with 75%?

Why do you claim that soft forks deploy with 95%?

Because they do. Just read the BIPs for soft forks under the deployment section. Specifically after 75% the new rules go into effect. At 95% is the point of no return where the fork actually happens because at 95%, any blocks with older version numbers are rejected. With soft forks this is fine since the new rules are backwards compatible so it is fine if there are nodes that don't comply as they will still be fine. The actual forking part is at 95%, and that threshold should be carried over to hard forks as well. With hard forks, changing the rules causes the forks so those rule changes should only go into effect at the time of the fork, and since soft forks use 95% for the fork, hard forks should as well, not just 75%.

BIPs 34 (block v2; https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki#specification), 66 (strict DER; https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki#Deployment), and 65 (OP_CLTV; https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki#deployment) all use the same mechanism of 75% for rule deployment and 95% for fork. BIP 141 for segwit (https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#deployment) will use the exact same mechanism.

[CIYAM]

If the Bitcoin Classic was going to use 95% then I wouldn't have a problem but unfortunately they have stated that they are going to enforce their new rules at 75%.

The reason that this is so dangerous is that for certain there will be an equivalent of NoXT appearing (meaning that they don't actually have 75% of nodes but maybe not even 50%).

So if you have enough resources then you create a few thousand nodes (not too hard to believe possible) then prepare to sell all your BTC on the fork and once you have removed the fiat you "switch back" and then you sell it all again.

[jbreher]

Why should soft forks deploy with 95% but hard forks deploy with 75%?

Why do you claim that soft forks deploy with 95%?

Because they do. Just read the BIPs for soft forks ....

Some specific soft fork proposals are set at 95%. Not endemic to soft forks generally. Got it.

What is the soft fork threshold for the SegWit Omnibus? Anyone?