Bitcoin.com almost forks the blockchain with buggy BU

[achow101]

Bitcoin.com's mining pool, running Bitcoin Unlimited, recently accidentally mined a block greater than 1,000,000 bytes. This block is considered invalid under the current consensus rules and was subsequently rejected. This resulted in Bitcoin.com to lose the ~13.2 BTC block reward of that block and waste their miner's time and electricity.

This invalid block also resulted in many BU nodes being banned by other nodes for relaying an invalid block.

Note that this is different from normal block orphaning as this could have resulted in a consensus split, not just a normal small fork with all full nodes switching to follow the longest chain. The longest chain could have been built off of the invalid block due to BU and SPV miners making up nearly half of the network hashrate.

This block could have resulted in an actual hard fork and chain split due to BU miners and SPV miners. Some BU miners would have considered this block valid and thus mined on top of it. SPV miners would have received the block header and mined on top of that without checking the validity of the actual block itself until later. This could have resulted in a blockchain split similar to the July 2015 fork. Fortunately neither of those happened and there was no chain split.

The reason for this block is that BU changed some important code regulating the size of the block. Specifically, they removed something that reserved space for the coinbase transaction and thus once the transactions had been selected and the coinbase transaction were added, the size was too big. This bug appears to have been introduced here which was also committed directly to the source code with a Pull Request, so it is likely that the change was not reviewed.

See also: Reddit discussion

[1715322189]

1715322189

[1715322189]

1715322189

[1715322189]

1715322189

[Quickseller]

I don't think there was any real risk of Bitcoin forking because AFAIK no merchants have indicated they will solely use BU and not core, nor is there any substantial mining capacity running solely on BU.

I believe that Rodger Ver said on r/btc that the Bitcoin.com pool is PPS, so he will bear the full cost of this. Similarly, I think the major pools had learned from the July 2015 fork that they need to fully validate blocks ASAP, even if they SPV mine for a few seconds after receiving a block from a trusted source.

Similar to the July 15 fork, if the miners had continued to mine on this invalid block (effectively changing what they consider valid), then major Bitcoin business would need to decide on the fly if they will accept these changes concensus rules (note: I specifically did not say "nodes"), under the understanding that if these changed concensus rules are not accepted then they would be only accepting Bitcoin from a network with decreased security and increased block times for a long time.

[-ck]

Actually quite a number of pools that use header only mining, btc.com viabtc f2pool btcc and btc.top all were mining on the invalid chain for a while there. I suspect the only reason there wasn't an extended fork was because the next block found was on the valid chain making them reorganise their own chains back to the correct one. Since the pools are not clear on when they switch from invalidated headers to validated blocks, it's hard to know exactly what might have happened.

Here is the log of it hitting my pool's bitcoind and how my (0.13.2 core based) node handled it:

Code:

2017-01-29 06:58:50.871920 ERROR: ContextualCheckBlock(): weight limit failed
2017-01-29 06:58:50.896292 ERROR: AcceptBlock: bad-blk-weight (code 16)
2017-01-29 06:58:50.896352 ERROR: ProcessNewBlock: AcceptBlock FAILED
2017-01-29 06:58:50.896433 Misbehaving: 54.213.163.201 (0 -> 100) BAN THRESHOLD EXCEEDED

resulting in the propagating BU node being banned by my node.

Followed by another node trying to submit the block again

Code:

2017-01-29 07:01:21.701452 ERROR: AcceptBlockHeader: block 000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5 is marked invalid

[achow101]

I don't think there was any real risk of Bitcoin forking because AFAIK no merchants have indicated they will solely use BU and not core, nor is there any substantial mining capacity running solely on BU.

The issue is more of miners mining on top of the invalid block due to SPV mining.

I believe that Rodger Ver said on r/btc that the Bitcoin.com pool is PPS, so he will bear the full cost of this. Similarly, I think the major pools had learned from the July 2015 fork that they need to fully validate blocks ASAP, even if they SPV mine for a few seconds after receiving a block from a trusted source.

While I am sure that many pools learned that they need to fully validate the blocks ASAP, I am fairly certain that many large mining pools still do SPV mining and thus could have accidentally mined a block on top of the invalid one before completing validation of it. It would be similar to the July 2015 fork.

Similar to the July 15 fork, if the miners had continued to mine on this invalid block (effectively changing what they consider valid), then major Bitcoin business would need to decide on the fly if they will accept these changes concensus rules (note: I specifically did not say "nodes"), under the understanding that if these changed concensus rules are not accepted then they would be only accepting Bitcoin from a network with decreased security and increased block times for a long time.

The major difference here is that the fork would not be known or obvious to those businesses unless they follow media (or Reddit) that have reported a fork. No block explorer has information about the invalid block except for blockcypher. Anyone running software other than BU would not have known that a fork was happening. The only indications that a fork was happening would be that the log files for full nodes would be reporting invalid blocks briefly until those nodes relaying them got themselves banned and that blocks would simply be produced at a slower pace.

[Foxpup]

This is delicious.

Code:

2017-01-29 07:00:22 ERROR: AcceptBlock: bad-blk-length, size limits failed (code 16)
2017-01-29 07:00:22 ERROR: ProcessNewBlock: AcceptBlock FAILED
2017-01-29 07:00:22 Misbehaving: 127.0.0.1:57226 (0 -> 100) BAN THRESHOLD EXCEEDED
2017-01-29 07:00:22 Warning: not banning local peer 127.0.0.1:57226!
2017-01-29 07:00:34 receive version message: /btcwire:0.5.0/btcd:0.12.0(EB4; AD99999)/: version 70012, blocks=450529, us=[scrubbed].onion:8333, peer=1638
2017-01-29 07:00:34 AdvertiseLocal: advertising address [scrubbed].onion:8333
2017-01-29 07:00:36 ERROR: AcceptBlockHeader: block 000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5 is marked invalid
2017-01-29 07:00:36 ERROR: invalid header received
2017-01-29 07:00:36 ProcessMessages(headers, 82 bytes) FAILED peer=1638

I'm archiving this log as a permanent reminder of BU's incompetence.

[franky1]

1. orphans/rejects happen often but you dont see blockstream orgasming when those orphans/rejects are based on bad core code
2. the block got rejected in 3 seconds .. end of drama.. but core nodes were set to ban nodes in such an event (over dramatics)
3. this block rejected, like other orphans/rejects proves that consensus and validation mechanism works
4. this proves that altcoins are not created just due to a slightly larger block
5. this proves that all the core rhetorical and scripted doomsdays are wrong.

people need to realise that within 3 seconds the block got rejected. orphaned off.. thrown away, put in the trash, not used,  gone

2017-01-29 06:59:12 Requesting block 000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5 from  peer=729
2017-01-29 06:59:15 received block 000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5 peer=729
2017-01-29 06:59:15 ERROR: AcceptBlock: bad-blk-length, size limits failed (code 16)

meaning consensus works. bitcoin is still in one piece.

the network will only validate and accept blocks over 1mb when there is a majority.
so this is actually a positive by squashing all the fake doomsdays of altcoins and splits by BU.

WAKE UP PEOPLE

the real funny part is, although bitcoins built in mechanism from 2009 works as it should..
the core blockstream fans fear consensus, soo much they actually manually and automatically banned nodes AFTER bitcoins built in code done what it should, thus now core are the risk of causing an intentional bilateral split.. by avoiding the natural orphan/validation mechanism by ignoring nodes instead of just rejecting blocks.

here is what would happen is they didnt ban nodes and someone passed them the same block

2017-01-29 07:02:10 receive version message: /BitcoinUnlimited:0.12.1(EB16; AD4)/: version 80002, blocks=450529, peer=737
2017-01-29 07:02:10 received: headers (82 bytes) peer=737
2017-01-29 07:02:10 ERROR: AcceptBlockHeader: block 000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5 is marked invalid

meaning its already been marked as dead, so dont handle it. IN THE SAME SECOND
thus no need to block nodes. as bitcoins consensus already pushed it to the side as a non issue within the same second

ha ha ha. im laughing

ofcourse gmaxwell instead of highlighting that consensus worked and issue resolved in 3 seconds where that block is automaticaly flagged as invalid if picked up again by another node..is do nothing more within a second.. (meaning he didnt highlight what consensus does). but instead orgasmed at the opportunity that his auto ban settings in core intentionally banned the nodes.. thus making a bilateral split possible due to core ignorance and use of an auto node ban feature.
(desperation i smell in gmaxwells pants)

Every Bitcoin Core node happily banned the BU peers that gave them this invalid block,

he kind of back tracked after to half explain consensus, where he said (not verbatim) 'an SPV would see the block until a new block officially pushes it away'.
although spv clients also rejected it in SECONDS using consensus without having to ban nodes. but maxwell didnt highlight the no need to ban peers aspect..

SPV wallet user who were connected to BU nodes may have seen a false confirmations for 24 minutes until 450530 was mined which decisively overtook the invalid 450529. Fortunately, in this case it doesn't appear that SPV miners exacerbated the invalid block fork though several did follow it briefly.

gmaxwell is desparate to cause an altcoin. he is even celebrating it

You missed a great opportunity for alliteration: Bugged block brings blanket BU bans.

desperate man, afraid of consensus that much he is willing to bilateral split the network.. as shown by earlier evidence of even wanting to bilateral split the network just to force segwit in

If there is some reason when the users of Bitcoin would rather have it activate at 90%  ... then even with the 95% rule the network could choose to activate it at 90% just by orphaning the blocks of the non-supporters until 95%+ of the remaining blocks signaled activation.

summary
CORE can cause a bilateral split by banning BU. not the other way round.
there is and was no need to ban the nodes.. bitcoins validation mechanism took care of the block but core went one stage to far banning nodes..
desperate move blockstream.

[-ck]

For the record, this is nothing like a regular orphan so drawing any comparisons based on that assumption are all misguided at best.

[franky1]

For the record, this is nothing like a regular orphan so drawing any comparisons based on that assumption are all misguided at best.

like your pretending this has not happened before.
blocks over 1mb have been rejected before now. but blockstram fans are over dramatizing it to make it sound like BU could have caused a bilateral split, when infact it was cores heavy hand that went a step too far to possibly cause one. rather then just reject the block and move one

need i bring up sipa's 2013 DB boo boo..where core bugged out when blocks went over 500kb.. oops i better not mention a blockstream paid dev's boo boo's

[achow101]

1. orphans happen often but you dont see blockstream orgasming when those orphans are based on bad core code

This is not an orphan. An orphan is a valid block. This block is invalid, entirely different from an orphan. An orphan can lead to a valid chain which EVERYONE will follow. This block is invalid, and can lead to a chain where SOME NODES (not all nodes) follow.

When has a miner running just Bitcoin Core as their node (and thus not SPV mining) mined an invalid block?

2. the block got rejectct in 3 seconds .. end of drama..

3 seconds in which an SPV miner could have found a block on top of the invalid one and thereby causing a chain split.

but core nodes were set to ban nodes in such an event (over dramatics)

Rejecting a block for being invalid and subsequently banning the node that sent the block is not behavior just limited to Bitcoin Core. It is present in Bitcoin Unlimited as well and any other software derived from Core. Such behavior has been in the code for a very long time.

3. this block reject, like other oprhans proves that consensus and orphans work

Again, this block was invalid and rejected. It is not an orphan. They are two very different things.

4. this proves that altcoins are not created just due to a slightly larger block
5. this proves that all the core rhetorical and scripted doomsdays are wrong.

This just shows that it will not always happen. This does not mean that it can't happen.

[franky1]

and the only knitpick you can find is that i over used the buzzword orphan..
aww you may consider an orphan to be strictly related to a bad parent being taken away leaving the child to be lost in the system and rejected as a consequence, even if the child is a good child..

i consider all rejections where having a parent or not, whether the child is good or bad ends up as the same result.
ends up with the same result
in laymans:
lost and rejected, cast aside. in the dustbin, thrown away, disguarded. bye bye gone!
(and dont even bother replying there is no dustbin in bitcoin.. )

your just going to nd up looking pedantic again

orphans/rejects do not cause altcoins. orphans/rejects sort themselves out in the end.
what causes altcoins is when nodes are triggered to ban other nodes to not see a orphan/reject. which then leads to two nodes seeing or not seeing the same data.

When has a miner running just Bitcoin Core as their node (and thus not SPV mining) mined an invalid block?

happens more often then you think
https://blockchain.info/orphaned-blocks

[DannyHamilton]

Note that this is different from normal block orphaning

Only because this block was invalid.  It is identical to what happens (and is supposed to happen) any time a node receives an invalid block.

as this would have resulted in a consensus split

Absolute nonsense.  Unless you are saying that a significant majority of all mining nodes are willing to accept a block larger than 1 megabyte (in which case it is Core that is trying to create a consensus split by refusing to accept the longest chain). No. In this case, a minority of miners would be willing to accept such a block.  As a result the valid chain would quickly grow longer.  Only those nodes foolish enough to accept and mine on top of an invalid block (such as so-called SPV miners) would be affected, and any miner dumb enough to accept an invalid block deserves to waste hash power on a dead chain.

This block could have resulted in an actual hard fork and chain split due to BU miners and SPV miners.

No. Not in any real way, it couldn't.  That's a whole lot of FUD and nonsense.  If I didn't know better, I'd think you were just another sig ad spammer.

Some BU miners would have considered this block valid and thus mined on top of it.

Let them.  Thats what they get for running code that will mine on top of invalid blocks.  They'll lose some revenue and learn an important lesson.

SPV miners would have received the block header and mined on top of that without checking the validity of the actual block itself until later.

Then they deserve to waste their hashpower and resources on an invalid block.

This is not an orphan. An orphan is a valid block. This block is invalid, entirely different from an orphan. An orphan can lead to a valid chain which EVERYONE will follow. This block is invalid,

Exactly.  If bitcoin can't handle some nodes receiving invalid blocks occasionally, then it has already failed and we should all abandon the whole experiment.  Those dumb enough to mine on top of an invalid block deserve what they get (which entertainingly enough is literally "nothing").

and can lead to a chain where SOME NODES (not all nodes) follow.

Only nodes that are willing to risk wasting time and money on a useless endeavor.

Rejecting a block for being invalid and subsequently banning the node that sent the block is not behavior just limited to Bitcoin Core. It is present in Bitcoin Unlimited as well and any other software derived from Core. Such behavior has been in the code for a very long time.

Which is why this is nothing more than people blowing a lot of smoke and then trying to claim there is a fire.

Again, this block was invalid and rejected. It is not an orphan. They are two very different things.

And yet you continue to act like it was somehow a valid block that could have "forked the network!"  Nonsense.

This just shows that it will not always happen. This does not mean that it can't happen.

Like I said, if it can then bitcoin is already a failed experiment and we should all abandon the entire concept immediately.  There is nothing more to see here than fools seeing rain and believing that the sky is collapsing on them.

[franky1]

i completely agree with danny hamilton. including the hard/expensive lesson for BU to learn.

but technically.. they never actually got the funds in the first place. so its just like all blocks... there is only one winner, and BU simply didnt win

[DannyHamilton]

but technically.. they never actually got the funds in the first place.

The point is that they waste time and money running equipment generating hashes that will never be part of the blockchain.  That's the expensive lesson.

[Warg]

This resulted in Bitcoin.com to lose the ~13.2 BTC block reward of that block and waste their miner's time and electricity.

May be they run out of money eventually, and people start to abandon them. And they go bankrupt. I think everyone get tired of obstinate bastards

[aarturka]

Right. I think the BU issue is solved now for good. If these morons may allow such mistakes, Who will trust them implement their hardfork? 

[aarturka]

I believe that Rodger Ver said on r/btc that the Bitcoin.com pool is PPS, so he will bear the full cost of this.

When he breaks Bitcoin with his hardfork and millions of people lose their money, he's going to compensate them too?

[jacaf01]

Right. I think the BU issue is solved now for good. If these morons may allow such mistakes, Who will trust them implement their hardfork? 

This is my concern with BU, they don't have what is takes to implement a successful hard fork they are advocating for. That is why they embark on divided and rule strategy between the miners and core team

[iCEBREAKER]

Here is the log of it hitting my pool's bitcoind and how my (0.13.2 core based) node handled it:

Code:

2017-01-29 06:58:50.871920 ERROR: ContextualCheckBlock(): weight limit failed
2017-01-29 06:58:50.896292 ERROR: AcceptBlock: bad-blk-weight (code 16)
2017-01-29 06:58:50.896352 ERROR: ProcessNewBlock: AcceptBlock FAILED
2017-01-29 06:58:50.896433 Misbehaving: 54.213.163.201 (0 -> 100) BAN THRESHOLD EXCEEDED

resulting in the propagating BU node being banned by my node.

Banhammered at the protocol level.  That is glorious.

Time to make an "BitcoinUnlimite Officially #REKT" thread.  

Working title:

BU Builds Broken Block, Blundering Bigblocker Buffoons BTFO


TIL Roger Ver, franky1, Quickseller, and DannyHamilton have very weak, incomplete, and/or just plain old wrong (mis)understandings of Bitcoin's specialized definitions for Orphan, Chain Fork, and Consensus Critical.

For years, these people have stubbornly insisted on telling us how Bitcoin is supposed to work.  Now we have confirmation they don't understand the basic concepts.

"but but orphans happen all the time"

BWAHAHAHA.  

"but but there was no danger of the fork persisting"

BWAHAHAHA.   

"but but the pool didn't really lose money"

BWAHAHAHA.   

[aarturka]

TIL Roger Ver, franky1, Quickseller, and DannyHamilton have very weak, incomplete, and/or just plain old wrong (mis)understandings of Bitcoin's specialized definitions for Orphan, Chain Fork, and Consensus Critical.

For years, these people have stubbornly insisted on telling us how Bitcoin is supposed to work.  Now we have confirmation they don't understand the basic concepts.

"but but orphans happen all the time"

BWAHAHAHA.   

"but but there was no danger of the fork persisting"

BWAHAHAHA.   

I earnestly suggest to franky1 to learn something elementary, research harder, run some code, begin with 'hello world' then research, research research, just not to look like complete oaf,
but he prefer not to wake up, to act like Ver constantly takes care of him, continue dreaming in his imaginary world... 

[franky1]

..

i understand the terms. i just dont go batshit crazy when talking generally.

take for instance achowe himself.. deeming a 3 second reject as a fork..
that is achowe doing a grammar boo boo missuse of buzzwording.

infact achowe went sooo deep he wanted to take a zero drama non-event such as a 3second reject. to make it into some 'BU caused a bilateral fork'. that he forgot that core closed the connections to make it bilateral rather than leave the connections open to stick with consensus

but it is good to see the only argument left to sustain this non event, is the grammar nazi argument.

so i find it funny that you think that this non event deserves its own r3cked topic all because you are a grammar nazi, as your only ammo to defend your corporate pals.

gmaxwll hates it when i dont
call his confidential payment codes, 'confidential Pedersen commitment'
call an intentional split, 'bilateral split'

so forgetting blockstreams buzzword anal desires. and instead thinking real world scenario use of words so common people can get the general context without having to decypher buzzwords

an orphan is not just where the parent is killed and the good child ends up being sidelined and alone, forgotton about.
an orphan is where the parent themselves choose to giveup the child, dont put their names on the birth certificate and instead choose to adopt another child.

so the child in both circumstances is an orphan. because it has no ties to a parent. and doesnt continue the family tree legacy.

a child can be an orphan whether the parent is alive or dead

noun
2.
a young animal that has been deserted by or has lost its mother.
3.
a person or thing that is without protective affiliation, sponsorship, etc.:
The committee is an orphan of the previous administration.


adjective
7.
not authorized, supported, or funded; not part of a system; isolated; abandoned:
an orphan research project.

i fully understand the terms. i just choose to translate the nazi buzzword's into common tongue.
for instance if i decided to become a medical doctor. i would refuse to tell a patient they had a 'acute myocardial infarction' to sound smart. i would instead say their heart stopped for 30 seconds. because its better to tell the person what actually happened rather than sound like a smart ass

oh well enjoy your social campaigns