BTC.COM, taproot signal and broken miners
Why is the taproot signaling progress of BTC.COM slowly?
The bad implementation of version rolling in some miner firmwares has brought us huge obstacles. Two different types of poor implementation made the situation worse.
Here is our story.
When we planned to enable taproot signaling, we thought it was only needed to modify a configuration file. Then we done for a part of deployment， and it found a block (#683449) with the signal within 30 minutes. It’s best of luck! Everything looks well. So we ended the daily work with a smile, and looked forward to seeing more taproot signaled blocks.
However, something happened quietly in the night.
The next day, a colleague for data statistics told us that our pool seemed a bit unusual. The number of rejected shares is an order of magnitude more than before.
Detailed analysis shows that these rejected shares come from some specific miners: all the shares submitted by them have the wrong version mask, and the bits that were originally forbidden to be modified have been modified. The problem has caused a serious impact on some users, and 70% hashrate of some users have been invalidation!
A bolt from the blue.
We had to temporarily pause signalling, follow by contacting affected users and seek other technical solutions.
Then after a simple experiment, we quickly found a technical solution: just change the bits that were originally forbidden to be modified of miner submitted version mask from 1 to 0, then the share with these bad miners will pass the verification.
Publish, deploy, enable signaling… Well done! The wrong version mask no longer appears, nor is it converted to the low difficulty error. Users’ profit will no longer be damaged or disappeared due to taproot signaling. Good. It’s time to deploy on a large scale.
Then, the statistics hit us again in the deployment.
Some new problematic miners are coming to us with a brand-new pattern of wrong version mask, and the pattern is beyond our comprehension.
For example. The bits allowed to be modified by the pool are 0x1fffe000, the block version is 0x20000004. For the “old bad miner”, we may receive “0x00c00004” as the share version mask, and then the correct value should be “0x00c00000”. So we only need “0x00c00004 & 0x1fffe000” to eliminate this error.
However, for these “new bad miners” that we found in our large-scale deployment, we received “0x13d9fffc” or “0xd1dbffc” from the version mask field. All problematic version masks end with “ffc”.
We have made some simple transformation attempts, but all failed the verification. So I wrote a piece of code to traverse the entire version space, trying to find the correct solution. Then I found:
For wrong version mask “0x13d9fffc”, the solution that meets the difficulty requirement is “0x13da0004”.
0x13d9fffc = 0b 0001 0011 1101 1001 1111 1111 1111 1100
0x13da0004 = 0b 0001 0011 1101 1010 0000 0000 0000 0100
0x13d9fffc ^ 0x13da0004 = 0x3fff8 = 0b 0011 1111 1111 1111 1000
For wrong version mask “0xd1dbffc”, the solution that meets the difficulty requirement is “0xd1dc004”.
0x0d1dbffc = 0b 0000 1101 0001 1101 1011 1111 1111 1100
0x0d1dc004 = 0b 0000 1101 0001 1101 1100 0000 0000 0100
0x0d1dbffc ^ 0x0d1dc004 = 0x7ff8 = 0b 0000 0111 1111 1111 1000
Different shares contain different bit offsets, which means that some information has been permanently lost and there is no way to correct the submitting from the server.
So, there were two options left:
1. Contact and suggest users upgrade the firmware, and abandon the affected miners if the problem still existed after firmwares upgraded.
2. Write code to empower the server with capability to turn off taproot signaling for these problematic miners only.
We collaborated with some users to proceed with option 1. But the users said that the problem still existed after the firmware had been upgraded with the latest version on the official website.
So, shall we suggest the affected users give up their miners?
As a software engineer, I certainly can’t accept this kind of irresponsibility to users. So, we started to develop solution 2, which is another week.
Then the time comes this week. The option 2 was successfully developed. After a small-scale test, it was finally deployed on all our servers.
Therefore, we should be able to see that almost all blocks from BTC.COM contain the taproot signal from this week and onwards. To be honest, it is also expected to have a very low probability where a few blocks without taproot signal will appear. And we believe this is a new opportunity we reserve for those “sick but not dead” miners.