Yeah don't you find it ironic that experts had started screaming 'we will run out of IP address space soon, increase it NAOO" since 20 years ago, and today internet is still chugging along on IPV4 just fine?

Wonder if you can recall anything before there was Safari, Mozilla and Chrome.

That one player M$ did try very hard to screw up all sorts of standards by being "innovative" and more "user friendly" aka breaking compatibility.

Document.all, marquee, ActiveX, VBScript... say these words to a senior web developer once and he will want to punch you in the face.

Perhaps the most important reason that Mozilla won web developers to Firefox was to stick to the web standards(which they did not create), rather than creating their own. It's exactly because browser developers learnt a lesson from IE6 and thus make sticking to web standards a super political correctness, that we could have a uniform browsing experience regardless which browser we are using today.

Needless to say, there are countless network protocols which leaves no room for maneuvering when it comes to implementation, you ever heard of anyone coming up with their own version of SSL/TLS protocol?

Nah, you guys need to give a break to the poor dude Toomim, he was ditched as soon as they found him to be of no more value. https://bitcoinclassic.com

FYI, Eric, iCEBREAKER is not a core dev.

It was not said by Peter Todd, but Pieter Wuille in his original Segwit presentation: http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/  he was talking about the possibility of a new kind of node between SPV and full node, and it has nothing to do with the full node security during a hard fork. Cypherdoc misrepresented it as " and since one of the stated benefits of SWSF was that it shifts the security assumptions away from miner collusion and non-Sybiling to that of "non censored partially validating SPV node connections" via as yet uninvented/coded fraud proofs in an attempt to scale nodes, this just compounds the problem given that we now know that the p2p network in a SWSF can be parititioned. we can't tell if SWSF is safe."

Your full node would not be downgraded to a "fraud-proof" node in the scenario of a SWSF, AFAIK the code for fraud proof has not even been written(he did mention that, but apparently contradicting himself), it's until now a mere theoretical construction.

That's why they are not the same problem....but I am sure you know that.

I edited my original post, sorry.

Now let's say, the scammer sent a payment to someone, which gets confirmed on the new chain, but the old nodes cannot see the larger blocks, so to them the coins do not move at all, either because the new transaction is included in the 'extra space' part of a 2mb block so it is not included in the old chain due to size limit, or because, well, the only miner left in the world that still mines the old chain is the attacker himself. Now the attacker could take as much time as there is in the world, in theory, to wait for, or mine a new block on the old chain, that includes his transaction which spends these same bitcoins already spent on the main chain, then the buyer/merchant will give him fiats/goods for bitcoins that do not exist on the chain 'at large', because he sees the transaction paying him being confirmed on a block relayed by the old node he connects to,  and he still wouldn't get these coins after upgrading. Makes sense?

Not really just business, say, you are buying bitcoins yourself. In fact, in which case, the smaller the hashrate remains on the old chain, the more dangerous it became for those left behind. The coins would not be lost, they would just have been already spent on the new chain, because old nodes cannot recognize the larger blocks, they would not see that.


A merchant using USD certainly should not be expected to keep up with Fed's monetary policy, waiting for x confirmations is as much due diligence as should be expected from him, when using Bitcoin.

Assuming the information is equally accessible to all corners of the world, this economy is way larger than we think.

But anyway, I know I am not going to convince you, I am just saying not all anti-Classic people have evil agendas, that's all.

Again, we cannot just speculate and pray.

Also, I think the important point is: let's just not say if your 'grace period' is too short, what if you see 5% of nodes hanging out there and have not upgraded? 15%, 25%? What if they still haven't upgraded after the fork because, well their admins could just go on vacation or something? What would happen to all the SPV clients connecting to them? Are you going to back down in this hypothetical situation?

I don't think we should wilfully allow someone to lose money through none of their own fault, not even one, but from my experience I cannot convince Classic supporters to accept that, but I guess, we can at least agree, that not everyone opposing to the hard fork has an evil agenda, they could just legitimately have moral concerns?

Nah, merchants using old full nodes, who would accept transactions on the old chain, would possibly get scammed through no fault of their own.

You cannot just fork and pray that the best will happen, in a security-critical system.

In the 2013 accidental fork, which lasted for 6 hours, someone managed to successfully double spend Okpay, this time an attacker would have months of time ahead to prepare for one.

Anyone running a node that retrieves a full copy of blockchain, so all of them except SPV clients.

No, network consensus, i.e., almost all the nodes on the network are ready to accept a new version of blocks.

If you would like to use TLSNotary to prove that your screenshot is genuine, PM me. 

Toomim acknowledged it in an interview with Guy Corem that it was Olivier Janssen and Marshall Long who got him to be the lead dev of Classic, a position Gavin and Jeff repeatedly refused to take over despite repeated requests, get you facts straight.


Because why should a Chinese Bitcoin users be supposed to keep up with whatever happening on Reddit and Github(websites probably blocked in China)? How are they supposed to know if something is going on, and the view points of all sides?  Those in whatever ways closer to the devs naturally get more information and don't forget, Toomim & Co also haven't really clarified on lots of things, e.g., what they meant by Miner's vote, how do they count these votes? Who are eligible? Anyone with a miner counts? Are Butterfly Jalapenos included? If so, what about CPUs?


Core has no power to have the network upgrading, and could not do so in a timely manner, much of which is still using badly vulnerable client, which Core repeatedly urged to abandon, I have personally spoken to people who told me he wouldn't change anything until the first >1MB block drops, dude, have you ran a full node ever?

You really don't get the point do you? Luke-jr's patch would not be accepted by Core, and even if it did, it would not be accepted by the wider community(which doesn't take their orders),  and all I have heard is that they are oh so unpopular, you failure to grasp this is probably the origin of all your disagreements and misunderstandings.


I did test it, but I was more pointing out the fact that so called "economic majority" was merely a fiction, like, do you even hold a referendum for that?


You have to, the network wouldn't magically upgrade overnight even if you do a hard fork.

I wonder why you are trusting the code they write, even if you switch to Classic.

How are companies, most of them centralized services, even supposed to be in this argument bewilders me. They have no place in Bitcoin's original design, and they don't add anything to the democratic value of the whole hard fork campaign, I hope you don't think their support are nearly as good as a real referendum being held? Heck we don't even have any idea how much they account for all the Bitcoin business activities!

I think what would be the correct thing to do is: let the network decides. I.e., you put out you 2MB-supporting client, wait for everyone to convert, and if you have almost everyone on board before you deadline, activate it, otherwise, call off the plan, as of now, Wang Chun's proposal in bitcoin-core-dev channel, which seems to be liked by Matt Corallo, is closest to that.

One of my biggest problems with Bitcoin Classic is they want to go full throttle ahead as long as they have 75% of miners support, no matter what.

I am not in agreement/disagreement with Core devs on everything/anything. But I was trying to ask your opinion, to see if we can find any agreement.

Then, I guess, perhaps we could agree that, hard fork the network with the support of just 6 pool operators, and one month "grace period", while completely disregarding the response of the network of full nodes at the time, like what the Bitcoin Classic people are very clear about what they are trying to do, is very undemocratic and should not be supported?

You do understand an alt-client is completely different from a fork, and  to change the network consensus is not Core dev's job?


FWIW I am still waiting for a referendum to organize around this issue, if you really want to be democratic certainly somebody should get us all to vote?


No disagreement here, it's almost like they want to be hated on this.

Misattributing one dev as a Blockstream employee is understandable, but two at the same time, is probably too coincidental.