Segwit2x fork stuck two block before the fork

[chek2fire]

As i say segwti2x nodes after a bug have stuck two blocks before fork block....
This is a reminder to everyone how irresponsible are CEO and startups and especially Coinbase, Bitpay, Blockchain.info, Xapo.
After this stuck someone found that there is and another bug to the code ....

https://twitter.com/jfnewbery/status/931553723532406784

Epic Fail!

[1715699150]

1715699150

[squatz1]

I wouldn't say the companies are the ones that are in fault, I'd have to say the problem here is that the developers really don't know what they're doing -- they're trying to make a quick buck here with this and it's really just not working out -- kinda expected but it's something that was bound to happen in a team ridden with incompetency.

Hope this'll be the time which the whole forking and 'free money' thing ends with. Gotta end now and this should be the time.

[scottykarate]

I wouldn't say the companies are the ones that are in fault, I'd have to say the problem here is that the developers really don't know what they're doing -- they're trying to make a quick buck here with this and it's really just not working out -- kinda expected but it's something that was bound to happen in a team ridden with incompetency.

Hope this'll be the time which the whole forking and 'free money' thing ends with. Gotta end now and this should be the time.

I've got to say this is pretty funny and fitting. Maybe this will slow down all of these hard forks since this and BTG haven't done so well to date.

[fiulpro]

For all those people who were so stern on protecting segwit2x its a major drawback.. there were numerous sentences stating it was fast but not safe entirely..also I think segwit2x support team were all about increasing the block size and thus transaction speed... Forgetting that the creators of the bitcoins did Decided the block size of 1 mb for a reason.. it wasn't random at all !
Our bitcoins is slow but SECURE.. rather than having an upgradation where it becomes fast but unsafe its far better.

[LoudA__]

So we can say that this "hard fork" is not an upgrade nor a development

I think it is a scheme to really bring bitcoin down. They can say an excuse like we did not know or we did not like what happened too, but the thing here is they do not care what happened to bitcoin and all they care is to do this fork that can make a lot of bugs. Way to go.

[EDWARD78]

If I can ask, how would this affect longterm viability of Bitcoin? Or is it a nonissue at the moment?

[Coins and Hardwork]

If I can ask, how would this affect longterm viability of Bitcoin? Or is it a nonissue at the moment?

John Newberry said that :

In case it's not clear: no-one should run btc1 code. It is untested, unreviewed, buggy and can only serve to disrupt and confuse the Bitcoin network.

So if the code runs, it will leave and confuse the whole network and will leave a lot of problem to us users. miners and developers.

[Foxpup]

I knew this would happen.

i fail to understand what the drama is all about.
the fork only needs  1 block to happen, and this one block can be delayed a little bit (a couple of minutes tops) before being mined. then the rest of the blocks building on top of it can be from nearly 0 (empty block with only coinbase tx) to 2 MB.

so where is the problem with that?

There are many problems with that, but the specific problem that caused this particular failure is that the hardfork block was delayed not by "a couple minutes", but by 29 hours, because that's how long it took the miners to realise that the segwit2x client won't actually produce >1MB blocks by default, and hence rejects its own blocks when the fork happens. (Many probably still haven't realised the default is broken as it only took a single miner with custom settings to mine the fork block, and since the issue was closed without changing the default behaviour, it's likely to happen all over again if they try to fork on mainnet. Get your popcorn ready.)