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 (release pending)
+
TIMELINE
+(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.
+
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.
+
NEW PROTOCOL RULES
+
+ 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.
+