Re-Claim Inflation Bug:
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.
(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
REGISTER. These claims generate new HNS coins as a reward,
but only the final
CLAIM can actually be spent (by the
transaction) keeping the money supply intact. However, the miner fees paid
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
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
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 (
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
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
• 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.