![]() ![]() ![]() (Double-spending a name that you still own doesn’t really confer any benefit.) Since the vast majority of names have not been transferred in the last 12 blocks, if we can prevent hijacking attacks, we can accept the risk of double-spend attacks, since the latter can easily be mitigated by waiting 12 blocks from receiving a name transfer before using that name for critical purposes.Ĭan we do this? Ryan Castellucci proposed many years ago that we could verify the scriptSigs of recent name updates, chaining them back to a previous name update that has sufficient DMMS confirmation (i.e. In practice, while any name could be targeted by a hijacking attack, only names that have recently been transferred to a new owner can be targeted by a double-spend attack. In contrast, double-spend attacks occur when a malicious name owner signs two different name updates with the same input, which (if accepted) would allow one of those name updates to be accepted even though only the other update is part of the longest blockchain. Hijacking attacks occur when a malicious miner mines a Namecoin block with an invalid scriptSig, which (if accepted) would allow them to hijack an arbitrary name without any participation from the name owner. ![]() When evaluating security of name transactions, there are two different attacks that we need to consider: it means that TLS revocations are unnecessarily delayed). Unfortunately, waiting 2 hours (on average) for a name update to take effect is not great UX, and also introduces its own security issues (e.g. Some of these changes have recently been implemented: Verifying Unconfirmed Transactionsįor security reasons, Electrum-NMC has historically required 12 confirmations before it accepts a name transaction. In my 36C3 presentation (seems so long ago…), I mentioned some future changes I wanted to make to the Electrum-NMC protocol. Changes to name_show in Electrum-NMC Protocol v1.4.3 ![]()
0 Comments
Leave a Reply. |