Topic: Bitcoin.com almost forks the blockchain with buggy BU - page 3. (Read 2684 times)

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?

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

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.

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

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

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

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

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


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.

This is delicious.


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

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

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.

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.

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:
resulting in the propagating BU node being banned by my node.

Followed by another node trying to submit the block again

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.

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