ENS Improvement Proposal: Auto revealing of sealed bids #704
Conversation
alexvandesande
changed the title
While this is a very clever solution to the problem, I would like to start at the basics and see a much stronger argument that any of this is necessary vs just moving to a non-blind bidding system (or perhaps optionally blind). The above quote from the PR implies that the whole purpose for this is to protect bidders from themselves. I would argue that its not ENS's job to protect users from their own irrationality and instead allow rational actors to participate rationally (bid what they think its worth) and irrational actors can waste resources if they want. I believe there are additional arguments as to why Blind Vickrey Auctions have better results, but they don't appear to be clearly included in this PR. I feel there is a strong need for a more compelling argument for them than this one sentence. Especially when keeping them while maintaining usability and also addressing the major UX pain points of the current system requires so much added complexity. At the moment, given just the justifications in this PR, I'm very unconvinced that this complexity is worth it and recommend instead the system just move to non-blind bids. |
There was a problem hiding this comment.
This seems too vague to be an EIP as-is; an EIP needs to specify a detailed mechanism that could be implemented by someone. Perhaps it makes sense to take this to the issues section as a discussion until something is nailed down?
I'm also concerned about the probabalistic nature of the PoW system; in an auction with many bids, we would expect 3/5 of them to be revealed before bidding ends, compromising the integrity of the vickery auction.
Users are also faced with an unknowable probability that their bid won't be revealed at all. Personally, I'd be more in favor of a protocol that allows users to trust a third-party with their bid, and provides economic mechanisms to punish them if they reveal early or not at all.
EIPS/EnsIP01.md
Outdated
| @@ -0,0 +1,63 @@ | |||
| This is the first of a series of ENS Improvements inspired by the ENS workshop in London, august 2017. | |||
There was a problem hiding this comment.
This probably shouldn't be in the EIP itself.
|
|
||
| 5) **Rewards** Rewards are given to the first person to reveal the key, so anyone bruteforcing it should reveal theirs as soon as they find one, or they might lose the chance of a reward. If no one has found any key after 48h, then the reward should increase exponentially, until a maximum period of 120 hours. After that period, it can only be revealed by the owner, and if the auction has been won by someone else, the bid will be declared invalid. If a large amount of bids go unrevealed, then the rewards should also adjust automatically. | ||
|
|
||
| 6) **Minimum deposits** The current system has a minimum deposit hard coded to 0.01. This was never considered a final solution because of the floating value of ether and demand for ENS names. In this method the minimum deposit would be proportional to the revealer's fees. A value of twice the reveal fee would be suggested. |
There was a problem hiding this comment.
Shouldn't this system be built on top of the existing system? If so, it won't have any input into base-layer parameters like minimum deposit. Personally, I'm a fan of Vlad's proposal to charge rent, and eliminate the minimum fee.
There was a problem hiding this comment.
I already wrote a proposal about rent and will be publishing it tomorrow
|
|
||
| 6) **Minimum deposits** The current system has a minimum deposit hard coded to 0.01. This was never considered a final solution because of the floating value of ether and demand for ENS names. In this method the minimum deposit would be proportional to the revealer's fees. A value of twice the reveal fee would be suggested. | ||
|
|
||
| 7) **Invalid bids** one extra factor would go into checking if a bid was valid: if the bid was revealed and the private key was larger than the size they had revealed, then the bid is declared invalid. Users are free to pick keys larger than the difficulty if they want to reveal it themselves, but they must be honest on the minimum size, so that revealers can choose to ignore bids that would take longer than 24 hours. |
There was a problem hiding this comment.
What if they're not honest? There's no mechanism here to either prove that a key is bruteforceable, or to punish those who make the miners do useless work.
There was a problem hiding this comment.
I think a minimum requirement should be a way to prove the length of the private key. This provides an upper bound for difficulty. This might be as simple as providing the public key and signing a message (to prove that there actually is a key).
|
|
||
| 3) **Unlocking** anyone is able to "reveal" the bid by revealing the private key. It can be done by the bidder themselves or by other machines by bruteforcing them. Since the owner has revealed the size of the key, machines can decide not to try to unlock a message if they believe it will not be able to do so | ||
|
|
||
| 4) **difficulty adjustments** If a key is found in less than 48 hours, the **difficulty** factor is slightly increased, in order to target a median of 48 hours. And in the same manner, whenever a bid is revealed after 48h the difficulty should also decrease ever so slightly |
There was a problem hiding this comment.
How do you tell the difference between keys found by brute force effort and keys revealed by their creators to game the difficulty?
There was a problem hiding this comment.
Only bids with a length smaller than the difficulty would be valid for adjustments. Someone holding a private key and revealing it at a specific time can only increase the difficulty, never decrease it, because the keys can be found before by someone else. I don't see how increasing the difficulty can be good for anyone but it's indeed an attack vector
I do not disagree with you. We will begin testing of traditional auctions with the domain reselling project by @wealdtech so this is mostly a discussion about "this is the kind of stuff we would want to do if we were to keep blind auctions, is it worth it?" |
I see your point and I considered the options. I don't think this EIP is intended to be merged and approved, but discussed. In the end I decided to go with this format as it allows threaded discussions and even closing smaller debates by fixing one or two points (as I've done with a comment from you already) |
| EIP: <to be assigned> | ||
| Title: EnsIP: Auto Reveal | ||
| Author: Alex Van de Sande (avsa@ethereum.org) | ||
| Type: Ens Improvement Proposal |
|
|
||
| ### Why keep Vickrey Auctions at all? | ||
|
|
||
| One way to deal with the situation would be to remove Vickrey Auctions alltogether. For example the [Domain Sale contract](https://github.com/wealdtech/domainsale/blob/master/contracts/DomainSale.sol) created by Jim McDonald (with some inputs by myself) uses a standard auctions system that expires after 24h after the last bid was made. This means that if a domain goes undisputed, the buyer needs only to make a single transaction and wait. Standard auctions are known to create inflated prices, specially if bidders get into emotional bidding wars, which might be good for the seller, but since there isn't a concept of original seller in ENS, this isn't necessarily a good thing. Ideally we want users to pay rational utility price for domains. |
There was a problem hiding this comment.
alltogether should be altogether.
|
|
||
| One way to deal with the situation would be to remove Vickrey Auctions alltogether. For example the [Domain Sale contract](https://github.com/wealdtech/domainsale/blob/master/contracts/DomainSale.sol) created by Jim McDonald (with some inputs by myself) uses a standard auctions system that expires after 24h after the last bid was made. This means that if a domain goes undisputed, the buyer needs only to make a single transaction and wait. Standard auctions are known to create inflated prices, specially if bidders get into emotional bidding wars, which might be good for the seller, but since there isn't a concept of original seller in ENS, this isn't necessarily a good thing. Ideally we want users to pay rational utility price for domains. | ||
|
|
||
| Also, not necessarily the initial allocations needs to be the most common way to acquire a domain: if a system like Jim's becomes very popular for secondary markets, then we might be able to see a competition betweeen multiple models, which is good in the long run. |
| ## Possible issues | ||
|
|
||
| * The process of bruteforcing keys could be considered a waste of electricity and a step back to the environment just as ethereum moves to a less resource intensive consensus engine. | ||
| * There is a non-trivial coordination issue when miners are deciding which bids to work on. If it takes 48h of constant bruteforcing to find a key, then all is wasted if another miners finds the same key before you. Miners could coordinate to attempt to bruteforce different bids, but this could create an unfair competition among parties that trust themselves not to lie. |
There was a problem hiding this comment.
"another miners finds" should be "another miner finds".
| ## Acknowledgements | ||
|
|
||
| I'd like to thank Nick Johnson for organizing the ENS workshop in London and all those who have attended for the very useful debates | ||
|
|
There was a problem hiding this comment.
Please waive the copyright, like in https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1.md#copyright
|
|
||
| 2) **Bidding** the bidder then makes a transaction to the chain with an amount of ether equal to or larger than their secret price. The contract doesn't need to store the full message, only a hash of it, the rest of the message can either be given off-chain to "miners" or it can be logged into an event on-chain to ensure it's available for everyone. The bidder also must reveal the size of the key they picked. | ||
|
|
||
| 3) **Unlocking** anyone is able to "reveal" the bid by revealing the private key. It can be done by the bidder themselves or by other machines by bruteforcing them. Since the owner has revealed the size of the key, machines can decide not to try to unlock a message if they believe it will not be able to do so |
There was a problem hiding this comment.
Is this "revealing" supposed to happen onchain?
There was a problem hiding this comment.
Will the revealing period remain? Or, can the revealing happen while the bidding phase?
|
|
||
| 3) **Unlocking** anyone is able to "reveal" the bid by revealing the private key. It can be done by the bidder themselves or by other machines by bruteforcing them. Since the owner has revealed the size of the key, machines can decide not to try to unlock a message if they believe it will not be able to do so | ||
|
|
||
| 4) **difficulty adjustments** If a key is found in less than 48 hours, the **difficulty** factor is slightly increased, in order to target a median of 48 hours. And in the same manner, whenever a bid is revealed after 48h the difficulty should also decrease ever so slightly |
There was a problem hiding this comment.
Is the difficulty factor local to an auction, or is it shared across all auctions?
|
|
||
| 1) **Encoding the bid** The potential bidder decides a name and then creates a random private key, with a small amount of bytes according to a **difficulty factor** given by the contract. Then it uses this small key to encrypt a message containing the name it wants and the amount it is willing to pay for it. | ||
|
|
||
| 2) **Bidding** the bidder then makes a transaction to the chain with an amount of ether equal to or larger than their secret price. The contract doesn't need to store the full message, only a hash of it, the rest of the message can either be given off-chain to "miners" or it can be logged into an event on-chain to ensure it's available for everyone. The bidder also must reveal the size of the key they picked. |
There was a problem hiding this comment.
Can a bidding happen even after some bids are revealed?
|
|
||
| 4) **difficulty adjustments** If a key is found in less than 48 hours, the **difficulty** factor is slightly increased, in order to target a median of 48 hours. And in the same manner, whenever a bid is revealed after 48h the difficulty should also decrease ever so slightly | ||
|
|
||
| 5) **Rewards** Rewards are given to the first person to reveal the key, so anyone bruteforcing it should reveal theirs as soon as they find one, or they might lose the chance of a reward. If no one has found any key after 48h, then the reward should increase exponentially, until a maximum period of 120 hours. After that period, it can only be revealed by the owner, and if the auction has been won by someone else, the bid will be declared invalid. If a large amount of bids go unrevealed, then the rewards should also adjust automatically. |
There was a problem hiding this comment.
Are rewards given even when the bid is revealed by the original bidder?
There was a problem hiding this comment.
Please specify the amounts of rewards.
| 7) **Invalid bids** one extra factor would go into checking if a bid was valid: if the bid was revealed and the private key was larger than the size they had revealed, then the bid is declared invalid. Users are free to pick keys larger than the difficulty if they want to reveal it themselves, but they must be honest on the minimum size, so that revealers can choose to ignore bids that would take longer than 24 hours. | ||
|
|
||
| 7) **Rewards origin** the system can pay itself, not only by requiring deposit fees but also by removing the **burning** of fees that occur in the current system. If a bid is revealed in 48h or less, then the reveal fee is paid directly from the bidder's deposit. The larger reveal fees, paid when a bid isn't revealed after 48h are taken from the larger fee pile, because it's not necessarily the bidder's fault. Bids encrypted with a larger key than the suggested difficulty pay no revealer's fee. | ||
|
|
There was a problem hiding this comment.
When does the auction end?
When the auction ends, do the bidders get their deposits back?
|
This is a courtesy notice to let you know that the format for EIPs has been modified slightly. If you want your draft merged, you will need to make some small changes to how your EIP is formatted:
If your PR is editing an existing EIP rather than creating a new one, this has already been done for you, and you need only rebase your PR. In addition, a continuous build has been setup, which will check your PR against the rules for EIP formatting automatically once you update your PR. This build ensures all required headers are present, as well as performing a number of other checks. Please rebase your PR against the latest master, and edit your PR to use the above format for frontmatter. For convenience, here's a sample header you can copy and adapt: |
This is the first of a series of ENS Improvements inspired by the ENS workshop in London, august 2017.
I'd like to thank @Arachnid, @vladzamfir, @kvhnuke and everyone else who participated on these discussions