Hacker News Reader

Comment by cjbprime | Hacker News Reader

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?

View on HN

You register the hash of domain+seed. Second transaction reveals both.

Couldn'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.

What's the chances of simultaneous transactions? (That's a question, not a snarky statement).

There aren't any. That's what the article was about: The order of the transactions in a block.

Sorry 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.

Sure. Register encrypted domain name and a one-time public key. Next block, reveal private key.

This 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.

It 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.

I'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.

Reply on news.ycombinator.com