Re-Claim Inflation Bug:
Full Disclosure

BRIEF

Users' HNS coins, names, and HNS root zone data are not at risk. A flaw was discovered in the Handshake protocol that could unintentionally increase the total HNS coin supply beyond its designed limits. A user with a reserved name claim could have have accidentally generated small amounts of extra HNS by modifying their wallet. In the worst-case scenario, a malicious miner could generate nearly unlimited extra HNS in every block. The bug was never exploited and is now fixed.

Miners and mining pools MUST upgrade their full nodes as soon as possible.
All other users SHOULD upgrade as soon as possible:
• hsd v2.4.0
• Bob Wallet v0.7.0

DETAILS

The Handshake protocol allows owners of certain domain names in the legacy DNS to claim their name on the Handshake blockchain. The claim requires a DNSSEC proof and is submitted to the network in a special type of transaction. This means malicious activity in the legacy DNS could potentially disrupt the Handshake system. In this issue, JJ discusses a solution to the "what if GoDaddy gets hacked" problem. The solution adds a 30-day lockout to name claims before they can be registered, and enables legacy name owners to re-submit a claim to the network any time before they REGISTER. These claims generate new HNS coins as a reward, but only the final CLAIM can actually be spent (by the REGISTER transaction) keeping the money supply intact. However, the miner fees paid by each CLAIM were not protected in the same way. This means that if a user re-submitted a CLAIM, they would pay an additional miner fee that would not be accounted for by the protocol design, inflating the money supply. Since fees are chosen by the user who submits the CLAIM, the flaw could be exploited intentionally to generate unlimited HNS.

Luckily, the hsd wallet does not currently allow users to re-claim (but it should, and it will soon). However, a curious user might be able to edit the wallet code and force it to submit a new CLAIM to the network, accidentally exploiting the bug. If, for example, a user lost the keys they used to generate their initial CLAIM (meaning the actual TXT record used in the proof) they may try to generate a new one with another wallet, and submit a re-claim. Note that the extra-generated coins are given to a miner as a fee and are not spendable by the claimer. A malicious miner could have collaborated with a legacy name holder or obtained a reserved legacy name, and submitted a new CLAIM with each block they mine, potentially paying themselves 100% of the name's reward as a fee.

This flaw is not just an implementation bug that could be fixed with a software patch. It is a problem with the design of the Handshake protocol and so it affects every user and all hsd full nodes. The only way to fix this kind of issue is with a soft fork, which adds new rules to the protocol and is enforced by miners. Specifically, the miners run new code that prevents the re-claims from inflating the money supply. Due to the severity of the flaw and the low difficulty of execution, the issue had to be disclosed to limited parties, and very carefully. The team contacted F2Pool and Poolin initially because together they make up over 50% of the network hashrate. Once 51% of the hashrate was patched there existed a potential outcome where a minority miner might unknowingly mine a block that is invalid under the new rules. That block would be forked off the chain by the majority miners. This is why as soon as 51% of the hashrate was upgraded, the minority mining pools were informed as quickly as possible. Finally, the patch had to be deployed to all users who run full nodes. This process reflected the priorities and trade-offs for deployment:
1. Protect users from inflation attacks (upgrade a majority of the hashrate).
2. Protect miners from each other (upgrade the remainder of the hashrate).
3. Protect users from the miners (deploy the patch as widely as possible).

Normally soft forks are widely advertised and deployment is obvious, but this was a sensitive matter: the flaw could not be disclosed until the new protocol rules were in place and enforced by as much hashrate as possible. Therefore, the patch included a covert signaling mechanism so the team could monitor its deployment. The code inserted two marker bytes (0xf0ba) into the second witness item in each coinbase transaction (a field normally filled with 8 random bytes). When the deployment reached 90% the team decided it was safe enough to disclose the patch publicly.