There is “…you have to wait for another minute to ensure no one else is trying to register your name. “ in step by step instruction.
But where is the option if someone else IS TRYING to register the domain?
Is there some algorithm for this case provided?
Is there documentation or instructions for that?
I’m not quite sure what you’re asking.
The first user to submit a valid register transaction that contains a commitment that’s at least 1 minute (and no more than 24 hours) old gets the domain. The precommitment and the delay exist so that someone seeing you submit your registration transaction can’t frontrun you with their own one.
I’ve asked the same in other forum and had an answer, that
“Whoever gets their 2nd tx in first will get the name. It’s not about the earlier commit but the first reveal.”
So, I am not sure now…
As Ethereum being public ledger, anyone can monitor pending transaction to ENS registrar controller register function and can try to frontrun by trying to call makeCommitment and register with higher gas price. minCommitmentAge interval between commit and register is there to provide some time gap preventing this sort of front run.
@matoken.eth, of course we can.
But my questions are -
How it should be (by design)?
What was the main idea about this “1 minute”?
What is it all for?
For example (just a fantasy) if I’ve made “request to register” and found that someone made it before me to, both request will be canceled.
Another scenario. First request to register (first transaction) will win.
Another scenario. First register (second transaction) will win.
So, I am just asking about this process documentation.
There is no science behind 1 min justification.
It was originally proposed as 10 min but decreased down to 1 min because we thought 10 min is too long. 15 sec (average block confirmation time) would be probably the minimum.
The person who did request to register first can take a position not to reveal unless you introduce another time period to invalidate their request, so this won’t make the process any better (it’s actually worse if we set a rule to invalidate if people don’t commit second transaction within x min).
@matoken.eth, I do not offer anything (10 minutes, or cancel bid, or something else).
I am jus asking.
If my request to register transaction commuted first, I am a winner (if I reveal it during 24 hours).
This is the true scenario?
If you have to wait for 24 hours to figure out whether you reveal or not, why not set the rule that first person who reveal wins (which is the current rule)? That way the second bidder does not wait for 24 hours?
I feel that this conversation isn’t really taking us anywhere as you are kind of asking same question over and over (for the sake of asking), so unless you have specific problem you are asking for help, I will stop answering in this thread to save my time.
The topic is interesting and it was not clear to me. I thought the 1 minute is in place so in case two people request at the same time, an auction between the two (or n) parties is thus established where the highest bidder wins the name.
The main reason of having 1 min is to prevent people actively watching Ethereum to frontrun other people’s registration. The possibility of two people register the same name will be non zero, but in that case, the current system will work to decide who the winner is (the first person to send the second transaction) anyway so no need to introduce another condition just for the minor situation.
(Sorry for two month late answer)
What is the reasoning for the 1 min and not just “immediate” or “1 block”? It seems like there could still be front-running, at least automatic, for common names, especially in times of a congested network.
Your suggestion has no prevention against front-running at all. Even though our current 1 min interval is not perfect, we wanted to provide a solution so that someone who wants to prevent front running can increase the chance of preventing it by increasing their gas price.
That though, is assuming, that the front-runner would not directly start with an extremely high gas-price? Or is the idea, that some gas-price war would solve the conflict?
I don’t think you still understood how it all work. For someone to front run, the second person has to do all of the following while the first person’s second transaction is running.
Due to #3 wait time, the second person never be able to front run as long as the first person finishes his second transaction within 1 min, no matter how high gas (s)he puts on own transaction.
Miners, though unlikely, could delay the reveal-Tx of the first person for a couple of blocks and include their own two Tx (incl. 1min wait time) into the chain before the one’s of the first person. This is also stated by the docs.
I assumed you decreased the waiting time in order to reduce front-running risk, but the higher, the lesser chance of such risk. However, was there no feasible solution barring other addresses from committing the same hash until some period (e.g. 60min)?
Yes, indeed.
Not I can think of.
If we did that, anyone could DoS ENS registrations by front-running commit transactions.
Hi Nick,
If one completes the 1st transaction, but fails the 2nd, how can they complete the register with config once the GUI on the ENS site no longer shows the option?
I committed for the 1st, and then had a bug occur on the 2nd forcing me to restart my browser and metamask. Upon resubmission of the 2nd transaction, it failed.
I now have no way of going back to complete the next steps.
Any insight?
Greatly appreciated!
The first transaction stores a secret number in your local storage in the browser. The browser should save that even if it restarts, but if it is lost then you will have to do step 1 over again.
I’m wondering if Psuedo Randomness triggering timing of future airdrops would allow ENSDAO to announce the prospect and avoid security laws?