User avatar
magma
Site Admin
Site Admin
Posts: 53
Joined: Thu Sep 10, 2015 6:57 am

Donate BTC of your choice to 1Magmaqvxx7LpUTYGWw8RNPEJXBQ6iSLVX

Contact: Website

Bitcoin.com's excessive block - Pool analysis

Tue Jan 31, 2017 6:14 am

As you all know, a bug in Bitcoin Unlimited caused Bitcoin.com to mine a block that was 23 bytes larger than allowed. We discovered this right after the block was mined, and took precautions immediately. The immediate action was very simple, set the max generated block size to 0.999Mb via the cli. This is a feature that does not exist in Core, so if this bug arose in Core, a restart of the client would be necessary.

Edit: Some people pointed out that it is indeed possible to lower the maximum block generated by Core, but not through the CLI. It would not need a downgrade, but at least a restart.

First of all, this block was invalid for all Bitcoin Unlimited clients with EB set to 1Mb. Currently, all mining pools running Bitcoin Unlimited have configured their excessive block size to be 1Mb. The block was actually rejected by the same node that mined the block.

Code: Select all

2017-01-29 06:58:48.499177 Processing new block 000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5 from peer myself (0). 2017-01-29 06:58:48.508666 Excessive block: ver:20000000 time:1485673118 size: 1000023 Tx:2290 Sig:4140 :too many bytes
The reason the block was broadcasted was because we have our own network for hi-speed relay of blocks. This network is hosted on several dedicated servers across the world and have two routes from Europe to China, and several routes from California over the pacific that lands in Hong Kong and Beijing. The block was broadcasted internally and some of these nodes have the default setting of 16Mb blocks, so they were broadcasted to the rest of the network. We have now updated these settings to only allow 1Mb blocks.

There has been a lot of misinformation out there, especially from Core developers and Core supporters. Greg Maxwell was claiming that it was a hard fork attempt, and there has been a lot of gloating in general by people trying to leverage the situation for their own gains.

Another problematic lie from the Core camp is the claim that there was a risk of a chain fork due to miners engaging in spy or SPV mining. This false claim is being spread by Blockstream CEO Adam Back, among with other ridiculous claims such as pools not actually running Bitcoin Unlimited.

Image

The truth is that most pools either spy mine (listen directly on the other pools using Stratum), or do headers only mining (some people call this by the incorrect term "spv mining") that only validates headers before starting mining. Even Core/Segwit supporting pools like BTCC (Samson Mow) and Bitclub Network (run by Core supporter James Hilliard) engage in this practice, simply because the reward is greater than the risk.

When Bitcoin.com's excessive block was broadcasted, most of the other pools started mining on top of it for a little while. Here is our log:
  • 06:58:48 Bitcoin.com mines an excessive block at height 450529
    06:58:49 ViaBTC starts mining a block at height 450530
    06:58:49 BTC.TOP starts mining a block at height 450530
    06:58:49 BTC.com starts mining a block at height 450530
    06:58:49 HaoBTC starts mining a block at height 450530
    06:58:49 BTCC starts mining a block at height 450530
    06:58:49 F2pool starts mining a block at height 450530
    06:58:50 BTCC starts mining a block at height 450529
    06:59:03 ViaBTC starts mining a block at height 450529
    06:59:20 BTC.TOP starts mining a block at height 450529
    06:59:30 F2pool starts mining a block at height 450529
    06:59:50 HaoBTC starts mining a block at height 450529
    07:20:19 Bitclub Network finds a 998.2kb block at height 450529
This proves that since the validationless mining debacle a few years ago, the pools have checks and balances in place to make sure they don't build a block on top of an invalid one. The reward of 12.5 BTC clearly outweighs the risk of mining an invalid block for 30-40 seconds. Since it's very uncommon that invalid blocks like these are mined and broadcasted, it's a risk worth taking for the pools. It also means the contingency plan works. The slowest pool in this example, were mining on the invalid block for 61 seconds.

Imagine that all mining pools are doing spy mining and waits 30 seconds for a timeout. With an average block time of 10 minutes, it's a 5% chance of finding an empty block that would get orphaned, but the risk of this happening twice in a row is 0.25%, and three times 0.0125% and so on. The conclusion is that Adam Back's claim is not only wrong, it's fear mongering and a part of the Core camp's ongoing crusade against mining pools in general, and anything SPV related in particular. In this case, there were no risk of causing a BIP66-like fork.

The best way to mitigate the risks for spy / headers only mining is to operate a good block relay network. Bitcoin.com is going to allow anyone to use their network as soon as it's available for public peering. Our network will carry all blocks in and out of China, and carry it to North America and Europe. We are currently working on a new compression technology called uthin blocks, allowing 99% compression and using UDP for maximum transfer speed. Another great way to mitigate the risks is to run Bitcoin Unlimited's xthin blocks with expedited forwarding. Xthin is very fast and will decrease the time your pool is mining without validating transactions.

This was a good learning experience for Bitcoin Unlimited, for Bitcoin.com and for the bitcoin community. It proves that the system worked, that invalid blocks can be mined and relayed without causing much trouble. It also proves that pools are taking responsibility and balancing the risks and rewards properly.


Regards

The Bitcoin.com Mining Pool Team
Magma Hindenburg - Bitcoin wallet developer

User avatar
OgNasty
AMA
AMA
Posts: 290
Joined: Thu Sep 24, 2015 4:26 pm

Donate BTC of your choice to 1NastyFRkeUTmMdbMmzggDVTQA6r3ibUoX

Contact: Website

Re: Bitcoin.com's excessive block - Pool analysis

Tue Jan 31, 2017 7:58 am

It could have led to an interesting situation had there not been safeguards in place to prevent forks like this.
Image

johnyj
Nickel Bitcoiner
Nickel Bitcoiner
Posts: 26
Joined: Thu Feb 04, 2016 8:01 pm

Re: Bitcoin.com's excessive block - Pool analysis

Tue Jan 31, 2017 10:49 am

It could have led to an interesting situation had there not been safeguards in place to prevent forks like this.
Even if it extends, it will be no more interesting than the previous two forks caused by core

Seccour
Posts: 1
Joined: Tue Jan 31, 2017 11:13 pm

Re: Bitcoin.com's excessive block - Pool analysis

Tue Jan 31, 2017 11:14 pm

It could have led to an interesting situation had there not been safeguards in place to prevent forks like this.
Even if it extends, it will be no more interesting than the previous two forks caused by core
Bitcoin Core didn't exist at that time.

Steffenpp
Posts: 3
Joined: Wed Jun 08, 2016 2:06 pm

Re: Bitcoin.com's excessive block - Pool analysis

Thu Feb 02, 2017 3:47 am

there has been a lot of gloating in general by people trying to leverage the situation for their own gains.
But this is what you do most of this post. You used it to attack Core. When in reality they have nothing to do with the situation. You fucked up.

User avatar
Fremont
Site Admin
Site Admin
Posts: 475
Joined: Tue Nov 17, 2015 11:52 am

Donate BTC of your choice to 18tQ7D9RufgEZ9dSGLytm4Sgk8g2M5NzNZ

Contact: Website

Re: Bitcoin.com's excessive block - Pool analysis

Thu Feb 02, 2017 4:11 am

there has been a lot of gloating in general by people trying to leverage the situation for their own gains.
But this is what you do most of this post. You used it to attack Core. When in reality they have nothing to do with the situation. You fucked up.
I'm not sure how you came to that conclusion but magma was not attacking Core, he was simply presenting facts; I'm happy to explain this in a little more detail to help clear up any confusion. For instance:
The immediate action was very simple, set the max generated block size to 0.999Mb via the cli. This is a feature that does not exist in Core, so if this bug arose in Core, a restart of the client would be necessary.
This is quite clearly a simple statement of fact that setting the max block size to 0.999Mb via the command line interface is possible in Bitcoin Unlimited without restarting, and not possible in Bitcoin Core. The statement was used to demonstrate one of the differences between Unlimited and Core - that if a similar bug were to arise in Core, a restart of the client would be necessary. A statement of fact =/= an attack.
There has been a lot of misinformation out there, especially from Core developers and Core supporters. Greg Maxwell was claiming that it was a hard fork attempt, and there has been a lot of gloating in general by people trying to leverage the situation for their own gains.
This is a simple statement of fact that misinformation has been put out, that some people are misusing the situation in order to try further their own agendas and acts as a preamble to the image containing a discussion which comes below it.
The conclusion is that Adam Back's claim is not only wrong, it's fear mongering and a part of the Core camp's ongoing crusade against mining pools in general, and anything SPV related in particular.
This is a simple statement of fact that the claim put forth by Adam Back in the discussion mentioned above is wrong, amounts to fear mongering and is factually incorrect; it is also being used in furtherance of Core's (with Adam, naturally, by association) crusade against mining pools and anything SPV related. The most latter part of that sentence re: a 'crusade' may well be an opinion, but the former - i.e. the statement that Adam's claim is simply wrong, an assertion which is backed up by the information given throughout magma's post - is a statement of fact.

Fremont

User avatar
LiteCoinGuy
Gold Bitcoiner
Gold Bitcoiner
Posts: 2505
Joined: Mon Sep 21, 2015 9:00 am

Donate BTC of your choice to 1Dbo5TtxG9cWoyw49GM8vbD7HgQhr1KVi6

Re: Bitcoin.com's excessive block - Pool analysis

Thu Feb 02, 2017 5:31 pm

well, i will stay with Core here - it is better to be safe when you must handle a 14 billion market cap.
********************************************
More informations about Bitcoin and scaling BTC on

bitcoin.org/en/

https://bitcoincore.org/en/2015/12/23/c ... reases-faq

&
reddit.com/r/Bitcoin/

Rmcdermott927
Bronze Bitcoiner
Bronze Bitcoiner
Posts: 590
Joined: Tue Sep 20, 2016 7:32 pm

Re: Bitcoin.com's excessive block - Pool analysis

Fri Feb 03, 2017 2:32 pm

well, i will stay with Core here - it is better to be safe when you must handle a 14 billion market cap.

Agreed. I'm running 3 core nodes currently. Hopefully segwit will activate in my lifetime.
Image

User avatar
Decoded
Global Moderator
Global Moderator
Posts: 417
Joined: Sat Oct 15, 2016 11:28 am

Donate BTC of your choice to 1fdFgrw59gczh96esrpJST6MVHyQm4VJK

Re: Bitcoin.com's excessive block - Pool analysis

Wed Feb 08, 2017 8:44 pm

well, i will stay with Core here - it is better to be safe when you must handle a 14 billion market cap.
But can Bitcoin handle a much higher market cap? Say maybe 30 billion? I doubt it. Small blocks will restrict the network and currently act as a bottleneck. We need a solution ASAP. I'm not saying to move to Unlimited, but we just need a change.
theres a snake in my boot

Return to “Mining”

Who is online

Users browsing this forum: No registered users and 4 guests