Bitcoin Forum

If we actually end up with a forked blockchain then we will have "two Bitcoins" (or more depending upon the software being used).

What will this do?

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

Once the exchanges have stopped then the miners can no longer sell their BTC block rewards so that means within a very short time there will be a serious problem in the mining area.

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.

This is what we are facing (so you've got to wonder why Gavin wants to try and push for this).

I don't think there will be a hard fork, slowly people are waking up at the stupidity of hard forking right now and are seeing the tradeoffs, Bitcoin's Core capacity increases will continue and people will learn from this once the drama is over. Of course it can always happen again, apparently XT was not enough so we have to go through Classic now. But every time Bitcoin survives this bullshit it just proves it's resilience and makes it stronger.

I think you are doom thinking a bit too much there.

Hard fork will be announced plenty far before the fork. Exchanges have sufficient time to decide what form they will be trading.

And even if they shut down, the miners can take a hit for a while. They may also trade them off exchange with a bit more trouble.

I am hoping your last sentence is correct, it seems that Bitcoin is resilient to just about anything and stays alive.  I have been trying to read and understand the difference between soft and hard fork and am getting there with my understanding.

People seem to be desperate about the fork, as if miners were poor little creatures that could not be bothered whatsoever... It's just evolution. Growing is painful.

Because I'm not a miner, I wouldn't know about the costs of electricity and operational costs; but I would think that even if they could take a hit "for a while", it wouldn't be for a very long time.  I would think at the absolute most, they could probably last 3 or so weeks; because of the fact that electricity bills usually come in monthly.

Plus, it would be pretty scary to be pointing your miners toward the "old coin" rather than the new fork and have your newly minted "old" bitcoins become essentially worthless.  I would have to think that the devs such as Gavin would have to give people atleast 2 weeks in advance to give heads up for the fork.

Actually if we simplify the situation we can get a better picture of the problem. The main problems are the time of activation and the consensus threshold. As far as things stand and Classic is concerned 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. Even if we disregard the groups behind the current implementation a fork should have:
1) Minimum 95% consensus threshold
2) Scheduled 6 months or longer from now

---

---

A fork in the current scenario would have a negative effect on everything just for a little increase in TPS, which can be achieved with Segwit.

i dont think there will be a hard fork too because there is no good alternative. you need more than 1-2 devs and a plan to make 2MB blocks - that is not enough.

When Classic will get activated, I doubt anyone will stay on the 25% chain. That chain will end up being 0.

You seem to miss the point - it won't be such a clear cut case and the exchanges *will shut down* (they would be stupid to not do so).

So the mining pools will end up with no-one to sell their BTC to.

Do you really think they'll keep on mining?

There you have it. The idea behind Classic is not about upgrading nor helping the existing ecosystem. You are essentially forcing the miners and everyone else to upgrade to a new chain in a time period where losses are already being counted. Why would anyone with good intentions want to do this? Essentially it is a power grab and nothing more.

Exactly. If you take out Gavin and Garzik out of the equation, Classic has nothing.

Which miners do you mean -- the ones on the 25% fork or the ones on the 75% fork?

Why on earth exchanges will stop trading? Most (if not all) of them support Classic btw.

Because they risk a "fiat loss" (i.e. "real money").

So if they have ended up on the wrong side of a fork they will actually go bankrupt.

I doubt any exchange is going to really want to "brave this" (so they will all just shutdown until a resolution happens).

Let's see if the exchanges are really going to publicly state that they will work on a fork (I very much doubt that any of them will do so).

assuming that classing will gather 75% of consensus right? where are the bettings on this?

there are data that show that classic is so far ahead than unlimtied and core?

Explain "fiat loss" How would exchanges holding BTC be any different than you holding BTC?

Apparently you are already "suing me" (from another topic) so can you just keep out of this topic?

(and good luck with your legal suite)

No data yet. Mostly vocal support from a majority of mining pools and the broad industry at this point. That's why Classic has the most chance to get activated.

With my limited understanding, I've come to really like SegWit and some associated options. Is there anything we can do to help - take up mining in a small way for example?

The miners need the exchanges - and the exchanges are not going to risk losing fiat.

So if the exchanges stop exchanging then the miners will stop mining - it is fairly simple.

Bitcoin has had its share of problems (as so any innovation), but even thou not everybody is on the same page sometimes, when push comes to shove, it will be worked out.

Bitstamp and Coinbase already did...

Vocal support is useless. You've stated the same for XT and look what happened. There even was a signed letter announcing its support. What a joke.

This doesn't help the development process though. The easiest thing that you could do and show support is to set up a few full nodes.

Why am I not surprised that this evil is on board with this?

XT lacked miners support from the start. Not Classic.

Did what exactly?

Did they promise to go bankrupt to support a fork?

(somehow I doubt that they did that)

Publicly supported Classic.

https://bitcoinclassic.com/ in case you weren't aware who supports it.

Did they say that they would gladly go bankrupt to support it?

(of course they didn't and you know they didn't)

Just re-read my OP and you'll see that if we end up with such a fork then there is going to be no future for Bitcoin.

Of course they didn't because NO ONE actually think they will go bankrupt for switching to Classic and increase bitcoin's capacity.

Companies: "Bitcoin.com". Is this some kind of joke?  :D You guys seem to be drinking some strong kool-aid. Classic doesn't even have real developers it solely depends on the people who are Core contributors.


The website is a joke. They even listed Marshall Long at one point. Peter Rizun is listed as a developer and Roger Ver listed as an important user.  ::)

It is not about the capacity; are you that deluded? Segwit offers enough capacity for 2016 and will cause no damage at all (where the rushed out fork would).

If the vast majority do not agree then you end up with 2 Bitcoins.

Do you not understand this?

Oh look, another BTC doom theorist. Maybe aliens come and steal Gavin and your wallet.

STOP SPREADING FUD!

Sorry - no FUD here - if you think an exchange is going to risk losing all their fiat on a fork you are sadly mistaken.

(exchanges don't actually work for a loss)

Yup, that's why there is a 75% threshold so your scenario won't happen. 75% is more than enough. It means on the worst case, 75% agreed to leave at most 25% behind. I doubt 25% will stick with the old chain anyway.

Whoever pushes the fork has a strong incentive to see its side of the fork be recognized as the only "universal" bitcoin, in the end the other side of the fork is doomed and could only serve some anecdotic purpose in the long run at best. Most likely it will just die fast.

another thing...miners can always sell privately i believe, their electricity bills is far less than their profit

this mean that for the time being they have accumulated a huge margin between profit and consumption and they are not forced to sell any coin to compensate


isn't this a way to kill adoption instead of increasing it? because some merchants will simply abandon the whole bitcoin idea if they don't like the new fork

I guess you didn't closely follow about what happened with NotXT.

I can guarantee you that there will be fake BitcoinClassic nodes created so that it seems that 75% is achieved and then after one day - that 75% will disappear (and this is why all exchanges will simply stop exchanging as they know that this will happen).

The other 25% which are almost 1/3 of the system are being forced to take action. If we end up being a system where the majority can push around the rest, then we are not better than fiat.
The other 25% (of the original sum) is more than 1/3 of the forked system and are being forced to take decide.

Two chains, twice the amount of coins. This is not FUD; this is a fact.

Strong incentive to test out this attack vector on Bitcoin.

Then you don't understand how the actual fiat system works.

btw 25% =/= almost 1/3. It equals 1/4.

Huh?

What on earth are you talking about?

If you are exchanging fiat for BTC and your blockchain ends up being deleted (due to a fork) then you just lost your fiat.

(as you should well know there are now refunds so the criminals are all waiting and hoping for this fork so that they can steal)

Irrelevant. Miners won't mine on faked nodes and mine will be very real. That's all I care.

An idiotic statement.

If the exchanges shut down then miners will stop mining.

How about you answer my question, extortionist (https://bitcointalk.org/index.php?topic=1086875.0;all) :)

Exchanges won't shut down. There is no reason for it.

There was a mistake in my original statement and miscalculation. 25% of the initial network is more than 30% of the forked network. You're the one who doesn't understand the current system that we're living in. Stop trying to make Bitcoin a democracy. It should be trustless, not a battle between chains.

He's right!  Absolutely right!  Except it will be temporary, and in the end him, and all the Core/blosckstream supporter losers will be permanently removed from any future sayso in the community, and their Core Chain will be left dead and writing on the sidelines.

And the reason this must happen.... is because our beloved Bitcoin was kidnapped and is being tortured and crippled and stuffed into a side-chain box under hte control of the evil Zurg!  And we must go rescue her!    ;D

Could you clarify what you mean by "it should be trustless"?
Is it currently trustless, or is there a possibility of malefactors? If it's currently trustless, no bad actor could subvert it because math. You seem to be suggesting it's not so?

Bitcoin is not a democracy, it’s a market driven system aligned with economic incentives. The actual economic incentive tells us to move to 2mb so that’s why businesses and miners are now pushing for it and why Classic have so much support.

They've lost a lot of market share during last year. Losers... All 'Classic' fork cheerleaders are losers!

Right.Bitcoin Classic is just having to known good developers. Without Gavin and Jeff I believe there would be no talk about Classic at all.
The main devs are all supporting core. And in my opinion is the path core is going absolute the right one.

Ugly UGLY Fork War coming.  Let all who are hoping for peace in this matter open their eyes.  Blockstream/Core Supporters are choosing the Scorched Earth path.  They will destroy it all if they can't have it. 

None of this will change the 75% "preactivation" level from being triggered.   But in a month or so afterwards when we approach actual "Activation" of the Fork..... everyone will need to be very patient, steady, prepared, educated.

Really? Core stays the core all the time.
Scorched earth path fans first had XT. Now they have 'classic'. What is next?

XT had support of the industry but not miners. Now Classic have the support of both miners and the industry. What's next? Core being left out.

The "economic incentive" tells you only what you want to hear. From a technical perspective 2 MB blocks make absolute no sense in comparison to Segwit.

Gavin even said something about not wanting to maintain it (IIRC) and Jeff has a different agenda. He believes that we should do a hard fork so that we have experience with doing one and I agree. However, I don't agree with the current proposal at all.

These developers are actually ones that have contributed with various improvements to the infrastructure. What have Classic "developers" created? Nothing.

It has the same support as XT had from Slush. They said they would support it until they didn't.  ::)

“Make the lie big, make it simple, keep saying it, and eventually they will believe it”

“The most brilliant propagandist technique will yield no success unless one fundamental principle is borne in mind constantly it must confine itself to a few points and repeat them over and over”  ~ Joseph Goebbels

“In the primitive simplicity of their minds, they will more easily fall victim to a large lie than a small lie, since they sometimes tell petty lies themselves, but would be ashamed to tell a lie that was too big. They would never consider telling a lie of such magnitude themselves, or knowing that it would require such impudence, they would not consider it possible for it to be told by others. Even after being enlightened and shown that the lie is a lie, they will continue to doubt and waver for a long time and will still believe there must be some truth behind it somewhere, and there must be some other explanation. For this reason, some part of the most bold and brazen lie is sure to stick. This is a fact that all the great liars and liars’ societies (meaning the Jewish press) in this world know only too well and use regularly.” ~ Adolph Hitler
Page 205 Mein Kampf

“If you tell a lie big enough and keep repeating it, people will eventually come to believe it. The lie can be maintained only for such time as the State can shield the people from the political, economic and/or military consequences of the lie. It thus becomes vitally important for the State to use all of its powers to repress dissent, for the truth is the mortal enemy of the lie, and thus by extension, the truth is the greatest enemy of the State.” ~ Joseph Goebbels

^^
http://cdn.meme.am/instances/250x250/24791066.jpg
Thanks for making Mr. Godwin cry :'(

https://twitter.com/JihanWu/status/694080283407069184
https://twitter.com/slush_pool/status/694128642725679104

Vocal support means nothing as previously said. Here's just an example of Classic supporters on twitter:
They have no idea what they're talking about.

2 MB blocks are urgent, Segwit is complicated, Bitcoin will die without it. - Pretty simple lie.

Getting pretty desperate compelling there. Add 2+2=4 to your lie list ploz.

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

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.

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

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?

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.
It will be, but that won't matter in the case of a hard fork if you're stuck on an old version.

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?

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

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

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)
https://i.imgur.com/QZD5Qk5.gif

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

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."

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.

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".


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

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.

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.

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.

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

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?

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.

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.

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.

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.

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?

Following uncomfortable?


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?

Seriously?

Two weeks is just a guess so feel free to interpret that as two months if you prefer (it doesn't really change the issue one way or the other).

Previously I've steered clear of any "politics" on this forum but with all of the misinformation that is being posted on behalf of those wanting a hostile takeover of the project to occur I felt it was time to "make a statement".

It is the same as the other previous soft forks. Try actually reading the post I made because I stated that very clearly with references.

This is just a conspiracy theory, but I think Gavin wants to force a hard fork, to see if the Core team can handle this
scenario. They themselves said, "We do not want to hard-fork, because of a lack of experience" Is this a test, to discredit the Core developers? The Core team avoided a hard fork by all means, and Gavin knows this.

It would definitely test their resolve, if a forced hard-fork are engineered by the Gavinoids.  ::)  

more like, miners do not trade on public exchanges. instead they do private trades (otc style)

for instance VC's hand miners FIAT to pay the electric. and the miners hand bitcoins to the VC as their returns. that way funds dont actually touch public exchanges..

even things like bitpay received 30+million in fiat a couple years ago and they used the fiat to pay customers and gave the bitcoin to VC's, without needing to touch exchanges as often as you would think.

secondly. if miners are losing funds due to VC's not accepting their transactions (due to threat of orphaning.. then miners would downgrade to mitigate the risk of orphans or go offline temporarily to conserve costs.. resulting in a reduction of the difficulty if the stalemate lasts too long.. its not an instant killing off of bitcoin its just a re-organisation of power.

in short miners wont push the boundary of the 1mb limit.. even if they have the setting in their client as a buffer, they wont physically make blocks bigger than 1 block unless they are sure their blocks wont get orphaned or not accepted by the community..

so even if 75% of the community had the 2mb setting as a buffer. miners wont shoot themselves in the foot, they would just plod along at 0.99mb until the time is right.

any miner that went full retard and tried to force a fork, even at 75% would eventually get their attempt orphaned unless they had more hash power than any other miner to ensure they kept beating other miners to win the blockheight race.

in short the 2mb setting is a harmless buffer setting thats never used, unless
1. miners are secure that their attempts to make bigger blocks wont evaporate into orphans
2. they had enough hash power to tip the scales in their favour without loss
3. they had community relaying support to ensure their blocks got relayed.
4. their not mentally retarded to risk more processing time, orphans or going offline which would be 3 slaps in the face, for just being to eager.


instead they would wait it out until the time was right. even if gavins 'few week' predicted timescale elapses, miners just wont move forward until they are sure.

this is also the reason miners dont upgrade their mining software as often. as they like to let the community test out new software before risking using it on a pool.

if you think that accepting more transactions(fees) is more important compared to long term regular income.. you are wrong.
currently fee's average 0.4btc total per block. if you think they are going to let in another 100 transactions (1.05mb instead of 0.99mb) just to get 0.42btc while risking their opportunities for multiple long term earnings of 12.5btc.. well im guessing you prefer the conspiracy theory more than logic theory.

some miners may be mentally impaired and try pushing beyond the 1mb limit prematurely, but they will find their attempts cost them if they dont have all the other factors ready to protect them and the community, and so the are just shooting themselves in the foot and only hurting themselves in the end. and so eventually they will adjust down to start earning again and wait for a better time to adjust up again, or the rest of the community will grow to allow miners to move forward sooner.. or the miner will just go full retard and mine anyway at a loss. for no good reason. and the rest of us just orphan off those attempts

It's very easy to do a hard fork by your self if you just have 1% of total hash power, just compile a different incompatible version of bitcoin and mine a couple of blocks that is accepted by your client but not the rest of the network, once that block entered in your chain, you have done the hard fork

Unfortunately no one but you will be interested in that new chain and you have nowhere to exchange the coins on that fork

It is similar to any other hard fork, if no one is interested in the minority chain after the fork, then the coins on that fork will become worthless, at least much less than any alt-coin

This can be proved by the July 04 hard fork, the major hash power has mined a incompatible chain, those coins on that chain becomes useless and the miners lost 50K dollars on mining that chain

So to make sure the fork does not do any harm, you only need to make sure all the exchanges support only the major fork. And when a fork is really necessary, people will quickly reach consensus. Currently there is no such urgency so there is not enough consensus

Wow! Some really great information here, what a great thread. Can I give a newbie summary as I see it, and please correct me where I am wrong.

There are two main camps.
SegWit who want to extend the functionality of Bitcoin, and as part of this extension, they want to split the transaction for storage in two chains (is this correct?) The important section regarding the amount of the transfer and the history link stay in the existing blockchain, but because of the reduction in information, more transactions can be stored in a block. This solves the size problem in the short term, and still allows for an upgrade to 2Mb blocks when traffic volumes have increased in the future. This could become effective fairly quickly.

Double blocks want to double the size of the blocks as a temporary solution, and then increase them again in the future as traffic continues to increase, They believe that this can be implemented immediately. Whilst the code changes could be incorporated quickly, it seems to me that no miner would produce blocks over 1Mb in case the SegWit fork wins, and they lose their income. Thus the 2Mb change will not be effective until the fork dispute is resolved.

If core includes some of the other enhancements with SegWit, then wouldn't that become the popular choice of nodes? Also, if I have understood the problem, then double blocks don't seem to offer any benefit in the short term.

I think they need only to check if the coins reached on the deposit address on both chains. Then these coins are safe. It doesn't matter then which chain will win since they have the bitcoins on both chains.

Huh?

You are not making sense. An exchange is going to on one fork or the other (not both unless they want to be giving away fiat).

If your exchange decides on Fork A and then Fork B finally wins out then that exchange will go "belly up" (as all the coins it has had deposited would be unsalable).

OP's post is so so shallow, so uninformed and probably malicious.

Fake bitcoin classic nodes would not be able to raise the percent of support since they aren't actual miners. At the end the amount of hashrates are mattering.

And when a fork happens then when support for this new system raises a high value which means everyone will switch then since it is very unlikely that they will drop again then.

Who the fuck is this classic shit? ::)

Is sounds to me like some bad commercial!

Hashers can throw their power behind a classic miner then later withdraw their hashing power.


As I've stated I don't think we are just dealing with sensible people making sensible decisions.

If Bitcoin Classic were to stick to the way that soft forks have so been done (95% before activation of the new feature) then all of this controversy would go away.

If the vast majority of people do want 2MB blocks then I don't see that 95% should be a problem (and for the record I don't really care if the blocks are 1MB or 2MB).

25% are exactly 1/4 of the system and not almost 1/3.

And what do you mean with a system where the majority can push around the rest? I guess you never heard of how democracy is actually the best way of ruling a country. I wonder what you would prefer, i guess no dictatorship.

The majority says what will be done which is simply a democratic principle.


We only would have split all coins when all the same coins are on different addresses on each chain. If they are on the same then these coins are safe and for them it would be as if no fork was happening.


So then is the segwit softfork an attack vector too or is this different because... it's what i think has to happen?

Will miners actually create 2Mb blocks if they risk them being orphaned if SegWit wins?

Bitcoin is not a democracy (have you not even read Satoshi's paper?).

Satoshi said 1 vote per CPU (not 1 vote per person) so surely you can understand that one person can have more than one CPU?

I do not believe a hard fork will occur, there is not enough approval for it to occur.
Just the name for the current bitcoin, I suppose?

Still it means 3 times more hashpower on the new chain.

And bitcoin no democracy... then there should nothing at all happen. Though the facts are that all forks are a form of democracy. I wonder how you imagine how things should be solved otherwise. We will never reach a consensus after this long time so the solution would be to do nothing? Or simply doing what you want?

I don't see why it is fine for you to run a softfork that activates after 75% of the hashpower is using it or a hard fork that goes life after similar thresholds. Double standards? It would still show that the majority supports something.

Really, i wonder what you are against for.

All soft forks so far have only been enforced after a 95% threshold (and this will apply with SegWit as well).

The only people trying to push for a 75% hard-fork are Bitcoin Classic, Bitcoin Unlimited and Bitcoin XT (the latter being now defunct).

I, for one, appreciate it. The propaganda from the XT Classic camp is relentless.

Actually you only misunderstood him. He meant that a transaction will receive confirmations faster, blocks won't be found faster then. But a transaction will most probably be implemented in the next block. So his sentence is fine.

Doesn't this apply to SegWit as well?

If you mean that the tx capacity should increase by around twofold then yes.

what is with this new obsession with "democracy?" did gavin write a new blog about how bitcoin is supposed to be a "democracy" or something?

it's an hard fork for the 2mb capacity incrase nothing else

we have two side here, those that want to hard fork no matter what and those that want a soft fork

but the result is basically the same, capacity must increase all the other shit does not matter

You are right, they will chose one chain. But that doesn't say that they can check incoming deposits against the deposit on the other chain. When they received the bitcoins not only on their chosen chain but on the fork too then they can accept that deposit because it is riskless.

Why should they not monitor the other chain and instead close down completely? That makes no sense businesswise.

You are talking nonsense (again) - if you accept coins that end up being on a failed fork then you cannot spend them. Got it?

So if I am exchange A and I accept coins on Fork A and am giving someone fiat for those coins then I've already spent the fiat and end up becoming a bag-holder of a useless alt.

Now tell me why any business is going to take on such a risk?

of course it does. that's what this is all about. whether capacity can increase before the system is more scalable. i am reminded of children in the back seat screaming "ARE WE THERE YET?!??!?!?!"

decentralization > increased capacity. always.

otherwise wtf is it all for? if bandwidth bottlenecks continue crippling node health as block size increases -- and we know this happens because that is the historical trend -- how much is too much? eventually, your transactions are censorable.

so yes, all the other shit matters. the fact that SegWit offers a capacity increase in the interim while weak blocks/IBLTs are worked on (which will reduce peak bandwidth requirements by 90%+ for full nodes)... makes this a no-brainer.

then we can talk about increasing block size limit -- when bandwidth loads for nodes are more sustainable.

What would be the sense of doing so? You can't send a reasonable amount of hashingpower to fake nodes just to try raising the hashrate, you would need to put real power into it. And you would only do this when you are sure that the fork wins. You can't fake hashrate like you seem to suggest. At the end it comes to the blocks that are found. And when a classic node miner has XX TH and spreads this hashpower around 10 fake nodes then on that chain there still would only be XX TH from that miner.

I think you mix the kind of vote the XT fans tried with actual votes by hashpower. It's not the same and the number of nodes decides nothing.


It might be that the problem is that one can foresee that there will always be more then 5% miners that categorically would block such a change. Which would make it impossible. On the other hand 75% is a strong sign of the will of the community, well miners aren't actually the community but comes near to it. And it's better to let the majority decide instead staying undecided.

At the end it doesn't matter. Sigwit might get taken over by the net realitively without problems, ln doesn't need a fork but i doubt it will be used very much. And at one point in time it is inevitable anyway to raise the blocksize. It's grinding some time, that's all.

You can't just watch as you are risking the loss of your fiat - so any sensible business is going to put up a sign like this:

"Sorry - no fiat withdrawals until the fork situation has been resolved."

I am not talking about "faking hashrate" I am talking about a planned attack with real hashrate.

The motivation for such an attack would be financial (i.e. spend your BTC twice or convert it to fiat twice if exchanges end up on different forks).

I did this before I read your post. :)

OK, so I'm only buying Satoshis, and I'm only a small node operator, but there must be many others who are starting to think like this.

Yes, in this sense it is not a democracy... maybe a technocrazy... cpu's are voting... :D So at the end the wealthy has more power. Was inevitable. But still it is some kind of decision finding. And the strongest wins because he can.

Uhhh, shouldn't the best code win?

Perhaps then, we should leave development as it should be -- meritocratic. Not based on a Reddit/Twitter political campaign.

You better hope miners don't support the mob rule Classic approach....because if this tiny minority of developers is to replace Core....it will be very dark days ahead for bitcoin.

Yeah, though the chances are not fair if you think about it. 75% is the majority of hashpower for sure. That's the first point. Then they can do it.

The otherside will make segwit come with higher threshold and lightning network without decision finding.

The problem is that the core developers block the raising of the blocklimit and they can enforce it. So in fact they force all the rest of the community to follow the way they want it to be. I think they can not complain about classic doing a similar thing. Classic at least would know the majority behind themself at that point. Coredevs don't really care about such decision.

In order to allow a decision there is no other way than to present an alternative. So at the end coredevs complain about the possibility to vote. They decided for themselves and for all to not raise the blocksizelimit. Everyone had to follow. Force. Now a way to find the opinion of the community was found and they complain about that happening since they already did their decision for us all.

No, i think the worse enforcer are the core devs. Deciding for everyone without giving a choice and when someone creates a choice then he wants to break everything in their eyes.

Yes i think so. Though Lauda wrote like the author of that sentence was so stupid to think that the confirmation time (the 10 minutes) will be lower. At least i interpreted it so since the sentence otherwise would be fine.

It isn't up to the core devs at all (remember it is about CPUs or more specifically ASICS voting?).

Quite likely the core devs will decide to simply accept 2MB if the fork risk is looking very likely (as they are not the ones trying to wreck things here) but I would pretty much guarantee that with in a month or two after that Gavin will be back with something that has 4MB (with another hard-fork threat).

You write as if this exchange wouldn't own the same address on the other chain then too. But they would ideally. Well, probably depends on the way their wallet creates addresses. Core might be not good if i remember correctly.

But let's assume they own the same deposit address on both chains. Then it would not matter if they receive the coins on both chains and the chain they used on their exchange suddenly dies. They still would have the coins on the other chain. Nothing would be lost.

I hope you got now what i meant. :)

No - you can't do this - the person who is sending you (being the exchange) has the private key for those UTXOs (not you the exchange).

So it is within their potential ability to "double-spend" (not you the exchange).

Clear yet?

(why do I get the feeling you don't even know what UTXOs are)

This doesn't apply to anything and is a ignorant statement. The average confirmation time for normal transactions stays the same regardless of remaining capacity in the block. The blocks right now are rarely full and the only transactions that don't get confirmed are those that don't have a proper fee. The situation would be the same at 2 MB with occasionally full blocks.

If people weren't ignorant and playing politics around here it would be that way. Look at all the developments that Core developers have made, now look at the Classic developers and tell me what they've created? Nothing. Toomin's plan is to copy things from Core.

Forgive my ignorance, but I thought a transaction was not final until it was included in a block that was accepted in the blockchain. I assumed that if there weren't any slots for the transaction, then its finalisation would be delayed.

If blocks are submitted half empty at the moment, why do we need to increase the blocksize to create more empty space/unused capacity?

It is good to ask. I was referring to the person that you've quoted. Your thinking is correct; until the transaction gets included in a single block (1 confirmation) it is marked as a zero-conf transaction and is not final.
It's possible to reverse a transaction with 1 confirmation but that is quite hard and becomes much harder the more confirmations that it has; these are things that you do not need to concern yourself with though. Your assumption is also correct, but mostly for transactions that have an inadequate fee. You could "take" someone else's "slot" by including a fee that is a bit higher.

There is no need for this right now. The fork is an political attempt at taking over the development of the main implementation. Segwit offers an adequate increase in transaction capacity (along with other benefits) and should ensure enough space for 2016 (it will grow with adoption).

Worse still 25% of the initial network is 100% of the other forked network!

100% of small blockers! This is patently unfair, the 100% not being allowed to* carry on mining small blocks.


(*by not being allowed to, I mean "being allowed to but it's just not fair")

Depending on the time that the fork would occur (between difficulty adjustments) you could say that they aren't allowed to. The chain becomes rendered useless for a longer time because of the other majority. It is clear that we can't get everyone on board on a single proposal (and thus 100% consensus is impossible), but nobody sane would recommend a split. Essentially the people behind the fork do not care much about the whole industry and especially not about the users, they just want to take over.

If the majority do not adopt it, then it would be a useless movement and there would be no takeover of anything. Hold your horses, people! It's not such a doom.

I.e. "not rational actors pursuing enlightened self-interest, the possibility of which Bitcoin failed to take into account."

There's no telling what might happen right now and this does cause some concern for investors. If the proposal only had a required consensus threshold that is higher than 75% there would be less risk with whichever path this goes down.

75% is generous, normally you need 67% to change constitution laws in most countries. It is always tradeoff how big minority you want give the right to veto majority will. If you think 5% or 10% can veto 90% majoriy, your probably part of this minority and want more power than you actually have.

What about if we need 90% support for not increasing to 2MB, otherwise we increase to 2MB. You see, just 10% could veto such change even if almost 90% would disagree. It is not right to give such small minority much veto power in eighter case in my opinion, 67% mostly used has reasons behind, and 75% is very generous imo if 26% still can be allowed to veto 74% will

Bitcoin is not a political thing (so trying to compare it to such things is just plain silly) - it is the fact that Gavin is trying to treat it that way now that is the issue.

Miners do not want to face risks of not being able to turn their BTC into "fiat" because it actually costs them a lot in electricity bills to keep mining (which secures the network).

If we end up with too much doubt as to what is going to occur then exchanges will stop allowing fiat to be exchanged and miners will be forced to start shutting down mines (due to the expense of running them).

I see your point but... exchanges might chose to remain open in one fork or another instead of just closing operations. They lose money if they remain closed and if there is a hardfork, I guess it would be better to have some than nothing.

If you are an exchange and you decide to "remain open" then you are gambling (i.e. if you end up on the wrong fork and you have paid out fiat to people then you have just lost that fiat and gained nothing of any value).

I don't think that exchanges are going to be so brave as to want to gamble.

It is obviously in everyones interest to make sure this does not happen.  there is noway that miners and exchanges are going to make radical changes that could cause a blockchain fork.  and definatly not one that they keep mining.

Is Bitcoin a country; a democracy? You're comparing apples and oranges here. Bitcoin is a consensus driven protocol. Participants that started using it have agreed on a set of rules.

Wrong. If 2 MB blocks are "urgent", "needed right now", "wanted by everyone" there won't be a 5% to oppose it, not to mention 10%. If there is, then those 3 are invalidated. 75% is not generous, it is harmful to the network and all the participants. A hard fork should be an upgrade of the existing chain, not a split into 3/4 and 1/4 pieces.

If you mean Bitcoin is for privileged group who decide, and not users who have right to vote with the hashing power needed to secure the network, then you just describe totalitarian system which hardly anyone signed up when joining Bitcoin. And your free to follow old rules if you preffer, the same way Im free to follow new rules.

Exchanges can decide what to do, but the big ones showed support for 2MB, so you see problem where there is none.

Yes. Seriously. Did you buy this account?


There is a cuase and effect issue here regarding the two weeks:


Frankly, I think your entire premise is nonsense, but wanted to start with the above. After thinking about the last quote, would you care to put a better number on 'two weeks'?

So you are saying that The SegWit Omnibus protocol changeset is defined entirely in a BIP, and that BIP lays out a 95% soft fork threshold? Great! That is news I had not yet assimilated.

At start, Satoshi choose 32MB as consensus rule, then changed it to 1 MB consensus rule, now it can be changed to 2 MB if majority chooses. If you dont want, your free to use 1 MB the same way people were free to choose continue using 32 MB before, none force you anywhere, but you force me to keep using 1 MB. Do you see the difference between dictatorship verus libertatian here ?

While this is 'kind of true', it elides some vital detail. The fact of the matter is that any node that wishes to operate in a trustless manner must still validate the signature information. IOW for trustless nodes, there is no data reduction.


Well, no. Only for non-fully-validating nodes. All nodes that ignore the signature chain will need to trust other -- fully-validating nodes (which get no capacity boost) -- to do the validation for them.

No. Stop with the "majority" nonsense when talking about 75%. For an upgrade of the network we need 'almost everyone' (obviously you can't achieve 100% but can come close to it) on board else you break consensus. You are essentially forcing the 1/4 of the current network (and this is a lot of people, hashpower and possibly even more merchants) to join the fork or be left on a slow and dying chain. This is not freedom.

It does for those who upgrade; those that don't upgrade never needed the increase in capacity.

We don't "need" almost everyone for any change. That's what the minority would like to think but no, if 75% agrees to kick out 25% away. Then 75% have come to a consensus to get rid of the armful 25%. End of story. There is nothing the 25% can do to stop the 75% to do whatever they want.

Why 75% then? Your argument makes no sense from this perspective: 51% resembles the majority as well and you could time the hard fork with a difficulty adjustment (this wouldn't be a problem). Then the 51% would have come at consensus and got rid of the armful 49%, right?

Could you link me to the source of boldface above? I keep searching https://bitcoin.org/bitcoin.pdf, and getting zero hits.
Perhaps alternative spelling?
Or are you simply making stuff up/using air quotes?

Would you like me to create a signed message using the 1ciyam address to prove it?

(and if that isn't enough then perhaps use my GPG sig as well?)

I used 75% as per Classic threshold but you are right, any % can make it for a split. Consensus is all about compromise. If one group is unwilling to do ANY compromise then the only thing they should expect is a letter of divorce from the other group, regardless of how much % they represent.

This, plus there are altcoin lovers who dont mind hurting Bitcoin a bit or have different reasons for capping onchain useability. You cant get almost everyone agree becase there are bad actors who dont have best Bitcoin interest in mind. Thats why you cant give too much veto power to small minority.

These is no group that is unwilling to compromise aside from the forkers. Your support a harmful split of the network; unfortunately we can't banish bad actors from an decentralized platform. I will not respond to further input from a party who is willing to damage the whole ecosystem in order to get their own way.

Start by reading the mailing list from day one. You're welcome.

Neither is 10 nor 5% small in the Bitcoin ecosystem. Nobody is capping the onchain usability either.

Give me a break, big blockers have been compromising down to 2 mb. That's how you get consensus. How much small blockists have been willing to raise the limit to achieve consensus?



0

Provide source or I'll have to assume you're simply lying.

In and of the fact that politics is nothing more or less than the adjudication of who wields power in a group dynamic, this particular part of Bitcoin is indeed 100% political.

One group (small blockers) want one thing, and another group (big blockers) want another. What outcome wins? It will be decided by those who amass political power. Period.

Sure, it all has to operate within the constraints of what technology allows, but it is still political. All your pollyanna posturing can't change that fundamental truth.

Indeed. Consensus does not come from code and math but from people agreeing to run the same code. Convincing people to run the same code as yours is political.  

Nonsense. Any rational exchange, seeing the threshold nearing, will implement trading for both chains independently. With tools to allocate to such chain funds that are being spent from the common trunk as desired by the nominal 'owner' of such funds. Any exchange that does not is incompetent, and deserves to be put out of business.

I note that even SegWitters are starting to recognize the possibility of chain splitting due to the SegWit fork, anyways.

I can't tell what is subject and what is object in your reply. But if I have your words parsed properly, than I believe you are making a false statement. Let me try again.

For any given node:
- In order to operate in a trustless manner, a node must fully validate
- In order to fully validate, a node must have access to signature data
- SegWit partitions transaction data into two chains - the operational data and the signature data
- the 'capacity increase' that SegWit claims is entirely due to the fact that they don't tabulate the signature data as being part of the block size accounting

Ergo, any node wishing to operate in a trustless manner does not get any 'block size increase'

You may reply 'but fraud proofs'. But this is yet another mechanism entirely dependent upon outsourcing validation to other nodes. IOW, not trustless. Insecure.

No need. I'll interpret this merely as you replying 'No'.

It is just that I remember interactions in years past whereby I thought you typically provided solid reasoning. Your posts of the last month or so don't seem so to me. More along the lines of axioms stated as proven fact followed by conclusions with no intervening reasoning. Sorry - just calling it as I see it.

My post is valid. In Segwit transacting between upgraded clients becomes more efficient; there is no increase in capacity for nodes that have not upgraded (or non-Segwit nodes). They are able to receive the data but are unable to validate it. If it is able to validate it then the client it is a segwit node. Not sure if this was changed in any way since the last time I've read about it (there's also a proposal in regards to it by Peter Todd which I've yet to fully read).

(bold not in original)

Please define what you mean by 'upgraded client'.

If such a client is getting a 'capacity boost', the only way this can be accomplished is by that node ignoring signature data. Ignoring signature data in and of itself makes that node dependent upon others to perform validation. Accordingly, such a node cannot operate in a trustless manner. It is insecure.

A client that supports Segwit after the activation occurs. Those clients can download and validate the data.

I never said that old nodes would be secure, did I?

If you are really interested in why 75% is not enough, the definitive answer is found here:

http://organofcorti.blogspot.com/2015/08/bip101-implementation-flaws.html (http://organofcorti.blogspot.com/2015/08/bip101-implementation-flaws.html)

Yes, they can. And they must process more than 1MB of data in order to validate what they are calling a 1MB block. The difference in quantity of data, of course, being the amount of data in the signatures.

So tell me again why this does requirement for more data not lead to node centralization, when many SegWit boosters (perhaps not yourself - I can't keep track) rely upon 'increasing block size to 2MB will lead to node centralization' as one of their strongest arguments? Or at least as their only argument for their claim that a simple block size increase is unsafe?

Because the stated 75% criteria produces a negligible yet discernible chance that we get a false trigger at an actual 67% adoption rate due to variance? Yawn. Troll harder.

That was what I initially said. This depends on the exact quantity of data though, just how much more are we talking about here?
I don't rely on that argument but I have surely used it a number of times (can't recall all the discussions). I'm just not aware of an estimated factor of increase and have chosen to ignore this information until I have one. Has someone done the math?

Uhm, no.  He shows pretty conclusively that


Emphasis is mine.  If you want to present math that disproves OrganofCorti's, feel free.  Calling me a troll for pointing out OrganOfCorti's excellent blog post is just childish.

In Wuillie's presentation at Scaling Bitcoin Hong Kong, I believe* he stated that by looking at recent transactions, the current scaling factor would seem to be about 1.75x. Or that signature data is slightly less than half the block data.

*my memory is at times faulty. But I'll stick to a claim that some prominent Core dev stated that analysis of recent blocks led to this figure.

Others I have seen use a 4x figure - totally dependent upon an assumption that multisig become a much larger portion of the transaction volume.

For this little branch of the discussion, the salient point is that any node that performs validation (i.e. any node operating in a trustless manner) must process not the claimed 1MB block size worth of data, but an amount of data that reflects the signature data as well - 1MB multiplied by this (instantaneous) scaling factor, be it 1.75x, 4x, or whatever else represents the proportion of signature data associated with the transactions included in that block.

It is not so much the math, but interpreting what it means in real terms. OrganOfCorti's post seems to focus upon mathematics, yours seems to focus upon hysteria. Shall we analyze this together?

The damning part of the analysis is specific to BIP 101, and assumes 'vote spoofing' upon the part of nefarious actors. Such is fine, and important in regards to analyzing the BIP 101 situation. However, you present it as if it is  universally-applicable to any 75% proposal. 'Flaw #3' is inapplicable to any situation where the tabulation of 75% is strictly based upon hash power.

So yes, it seems to me that you are trolling.

Even so, there is an admitted latent issue with the order of magnitude in the comments, unaddressed for months.


Or more importantly, the amount of time for variance to result in a false trigger is important. The other analysis in the quoted comment above puts the chance as "TL;DR: At anything less than 70% of steady hashrate, triggering a fork would take at least 6 years, and gets exponentially less likely as miner share decreases."

Even the bulk of Core devs are seeming to claim that it will be necessary in the not-too-distant future to increase the block size. Just not now. For some unstated reason. If variance results in a trigger after Core would have already increased the block size anyhow, then the trigger is a non-event. No chain fork results. So what?

Dude, I posted a link.  Who's the hysterical one here again?

A link, coupled with a statement implying that the material in the link was applicable to the particular 75% fork threshold being discussed, and that it necessarily indicated a 'problem':

And imbues my focus with hysteria?   uhm, ok  ::)

You obviously are not interested in any kind of a conversation here, so I will just leave you to what you were doing...

Meanwhile, anyone who actually gives a damn about understanding the issue will still have access to the link I posted.

I will add to this a real Bank run to the exchanges and cloud wallet like Coinbase and blockchain.info. The media will be real happy to describe that their corrupt fiat world has the same effects and to future system like bitcoin.
After that bank run drama i am very sure that the media again will told to all the global citizen the reason why we must keep the banking system and a central control governance..
some points more and what will happen if this fork is near.

1. Bank run from Cloud wallets and exchanges
2. Collapse of mining for a small or big period of time
3. collapse of Bitcoin value
4. After this disaster i am very sure the core developers will leave the project and Bitcoin will remain to the hand of a small developer group.
5. Core developer will trasnform the old bitcoin to a new mining bitcoin system without asic
6. After that will we have two bitcoin version with each 21 millions coin without any value at all or with a penny value of each of them especially for the first months
7. The node will transform in few data centers because no one will want to keep running a blockchain system with so much huge space
8. Collapse of the decentralized Bitcoin system and beginning of central control digital money.

In my opinion developers like Gavin Andresen is great minds to create code but crap minds to understand how works complex economical systems.
Is in our hand guys if we destroy the first social global experiment..

Many understands the statistic thats why conservative value of 75% is choosen so you cant claim the change is tiggered by minority, or to be exact, there is real chance of this happening by variance.

I can only assume you didn't read the link to OrganOfCorti's blog I posted, since he demonstrates quite rigorously how that can, in fact, happen.

http://organofcorti.blogspot.com/2015/08/bip101-implementation-flaws.html (http://organofcorti.blogspot.com/2015/08/bip101-implementation-flaws.html)

ok alot of people are discussing the consensus, the debate about separate chains and not many seem to be using logic.

so here goes
https://i.imgur.com/oFXeK7S.jpg

A.
this scenario is where just one miner with the most hash power compared to any other single miner.
although it appear the miner has 27% of hash power, effectively because it is adding more transactions the processing time is longer so the 'feel' of the hashing speed is more like 24%, thus its not going to be racing ahead making longer chains and only has 1 turn on average every 4 blocks to win.
thus with 90% consensus against it.. that 1 block out of 4 would get orphaned because the other 90% would ignore it and the next block they add wont have the over1mb block in its chain.

so there are 2 defenses, not enough hashpower to race ahead with over 1mb blockheights, and not enough peer consensus (nodes running same implementation).

B.
this is where there is a hashrate power of over 75%. but even in this case there is only 40% peer consensus, and so with all 10 miners connecting together to show each other a solved block. 6 out of 10 would orphan off that over1mb block. a bit more complicated to explain, but basically the end result is that eventually there is still just 1 chain of the under 1mb blocks, once the miners communicate and sort out the orphans.

C.
this is where there is 75% of peer consensus where the hashrate is over 90%. in this case the majority wins on both counts and the minority (under1mb) gets left behind with a chain that does not sync up.

remember. 2mb rule allows both under 1mb blocks and over1mb blocks.. so even if a 2mb consensus has not been reached the 2mb implementations would still happily accept the valid under1mb rules.. there would not be any hard forks as orphaning will rejoin any disputing blocks.

however old 1mb implementations, if they lose dominance in both counts. will end up with:
1. having a chain that doesnt sync up because it rejects the majority of blocks
2. the amount of peer nodes with an altnative chain would be limited.
3. miners who continue to mine in the minority wont be able to spend the efforts as its rejected.
4. would have to upgrade to regain sync ability and earning potential.

but as i say. this is only a concern for those that dont upgrade to a 2mb implementation. and only then if scenario C came into play.

so there is no issue in users having a 2mb implementation, where the setting just sits there as a buffer, doing nothing until scenario C comes about.
what is more disasterous. is that bitcoin-core refuses to code a 2mb implementation which means if a scenario C came about.. the entire community would be left behind with unsync-able nodes.

so just as a line of safety for the possibility of something happening in the next 3 years, its far better to allow users to have the setting there, just as a buffer.. than to refuse to give people the buffer and scream that the disaster is someone elses fault.

as i said having the setting for users, is not a call to arms. its not a red nuclear button. its just a setting that sits there as a buffer.. just like the 1mb limit was just a buffer while miners were making only 0-500k blocks in 2009-2013.

miners logic and psychology shows and proves that they wont risk adding more transactions (increasing processing time) if they think there blocks will get orphaned. and so they are not going to jump the gun. its not in their financial interest to do so unless the community is ready to accept their blocks, so they can atleast spend their rewards.
and anyone trying to imply nefarious intent of some miners.. ill refer you to scenario A, and possibly B(if collusion and naferious intent are combined). but in general long term reward earnings outweight possibility of short term nefarious intent. so relax

now onto bitcoin-core
we all know, bitcoin-core is a full node client. anyone interested in being a full node in april will need to upgrade to remain full node status, due to segwit. otherwise they are automatically causing their non-upgraded clients to become "compatible" nodes. not full validation nodes.

so knowing full nodes will be upgrading just to stay full node status. i think the April update should also include the 2mb setting buffer. that way even 3 years later or 6 months.. whenever the miners feel comfortable to be scenario C.. it wont impact the community because the community is already prepared.

remember the 2mb rule is not a rule that says "you have to accept blocks over 1mb". its not a nuclear launchcode of bloat.
its a buffer setting of "anything from 0b to 2mb" which includes normal blocks as they stand today.
again just like the 1mb was a buffer while miners were happy below 500k a few years back

so while miners stick safely to their 1mb rule the community can happily be prepared for 2mb possibilities of the future.
if bitcoin-core refuses to prepare the community before miners act.. then it would be bitcoin-cores fault for users not being able to sync once consensus has been reached.

ill just leave this image here for Lauda
https://i.imgur.com/fUlFwXS.jpg

As compared to you attempting to ridicule me for pointing out that this particular analysis is inapplicable to the topic under discussion? Certainly.


Except, of course, that the linked material is irrelevant to 'the issue'.

eta:

I can only assume you did not read it in entirety, as the comments therein have OrganOfCorti admitting that his analysis is off in its conclusions. By roughly two orders of magnitude. And contains an unfulfilled statement that it will be updated to fix this error.

I can only assume you did not read the followon info, which shows that it would take at least six years for any discernible chance that the 75% fork would false trigger at any less than 70% actual.

But by all means, keep repeating the same inapplicable statement.

My understanding is that the Chinese miners are now not going to back Classic so it is thankfully REKT and therefore I feel no need to continue this (now thankfully unnecessary) topic.

I am going to go back to focusing on working in this field rather than trying to herd cats.