Re-Claim Inflation Bug:
Full Disclosure


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


(All times UTC)

March 24, 2021 16:00
Matthew Zipkin discovers the protocol flaw and sends an encrypted email to Christopher Jeffrey (JJ) with a description of the issue and a test demonstrating an attack. JJ confirms the flaw and connects with Zipkin to discuss a solution. Zipkin runs this script to confirm that the flaw has not yet been exploited on the blockchain.

March 24, 2021 18:00
Joseph Poon is informed of the issue to help establish a code fix and deployment plan. JJ starts writing patches for hsd and sharing them with Zipkin as the solution and deployment plan evolve.

March 25, 2021 07:00
JJ shares a new version of the patch based on discussion with the team, including covert soft-fork signaling suggested by Zipkin.

March 25, 2021 18:00
F2Pool is contacted and informed of the issue.

March 28, 2021 01:00
JJ sends Zipkin final patch for review and testing. Extra chain-reorganization protection is included in case of a chain split during deployment.

March 28, 2021 03:00
F2Pool and Poolin are contacted, sent the patch and begin upgrading. Covert signals appear in blocks 61038 and 61039. DX Pool is contacted.

March 29, 2021 08:00
DX Pool upgrades. Covert signaling approaches 70%.

March 29, 2021 23:00
Urkel Pool contacted.

March 30, 2021 13:00
ViaBTC and Huobi contacted. Patch sent to Urkel Pool and ViaBTC, both upgrade.

March 31, 2021 00:00
Signaling approaches 80%. Bob Wallet is contacted.

March 31, 2021 02:00
Huobi gets the patch and upgrades.

April 1, 2021 22:00
Signaling approaches 90%. Namebase and Bob Wallet are contacted again and alerted to the deployment plan.

April 2, 2021 16:00
Patch is released as hsd v2.4.0 along with Bob Wallet v0.7.0, full disclosure is published.


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.


A CLAIM must commit to a mainnet block hash. By default, all claims commit to block #1. The existing rules already require that subsequent re-claims commit to higher block heights. This makes it easy to determine in the software when a claim is being re-submitted (commitHeight > 1). The following new rules are enforced by the soft-fork code:

• An initial CLAIM MUST commit to block #1.
• An initial CLAIM MUST pay a fee less than 1,000 HNS.
• A re-claim MUST pay the exact same fee as the initial CLAIM.
• The fees from any re-claim MUST NOT be collected by the miner: they are "burned" or, more accurately, already exist in a previous block.
• A re-claim can not be mined until 288 blocks have passed since the last CLAIM or re-claim.