4 ms·
Nice article! Here's another type of failure with its solution: * You want to register a domain name on the blockchain and associate it with your address, so
by cjbprime 9y ago
Nice article! Here's another type of failure with its solution:
* You want to register a domain name on the blockchain and associate it with your address, so you submit "register foo".
* The miner sees it, and inserts an earlier transaction registering foo to them instead.
Solution:
* You register the hash of foo, which registers the plaintext encoded by that hash, then wait until the transaction is accepted publicly and submit a second transaction that reveals to everyone the plaintext of the hash that you registered.
The miner could still try to guess at which name you're registering based on the hash (by having a long list of potential names to hash just in time), but I can't think of a way to do better than that. Anyone else?
- bdr 9y agoYou register the hash of domain+seed. Second transaction reveals both.
- SimonPStevens 9y agoCouldn't someone else then simultaneously register the hash of the same domain with a different seed? Neither of you would know of the duplicate until you revealed your seeds.
- pbhjpbhj 9y agoWhat's the chances of simultaneous transactions? (That's a question, not a snarky statement).
- Tepix 9y agoThere aren't any. That's what the article was about: The order of the transactions in a block.
- pbhjpbhj 9y agoSorry I shouldn't perhaps have said transactions - the parent asks what to do with simultaneous requests for to reserve a unique unduplicable good, it was the simultaneity of identical requests I was asking about rather than the impossible simultaneity of processing the blockchain transactions.
- theoh 9y agoThis is similar to the rainbow table attack on password hashes. The defense against that is to use a (public) salt when computing the hash. Maybe something similar will work here, though I'm not clear about the details of your notion of "just in time" hashing. The salt just prevents precomputation of hashes.
- fyi1183 9y agoIt would be better for the salt to be private (and revealed at the same time as the name), otherwise a miner could still try to guess at the name being reserved. Having a public salt only eliminates the possibility of precomputing many hashes, i.e. rainbow tables.
- theoh 9y agoI'm not sure about the idea that a miner could guess -- the point of a cryptographic hash is to make that impractical. We're not talking about CRC32 here. If there was discussion out there about protocols that involve keeping salts private I could be persuaded that it's a valid idea.
- drtr 9y agoSure. Register encrypted domain name and a one-time public key. Next block, reveal private key.