theoreticalbts
commented
7 years ago @mvandeberg asks,
How do we prevent collisions that use the same token name but different nonces?
We can't. We could forgo the nonce, but that would allow the name to be extracted by brute-force search (the name itself is quite low entropy, all ~26^6 possible names can be checked in seconds with a simple CPU implementation).
Even if we have a way for partners to reserve their names in advance with this mechanism, if it become first come first served on the reveal, then there is still a race to see who can reveal first.
Re-read the OP carefully (particularly the last sentence or two). It's first-come first-served for commitments not reveals. The "race" is between commitments. Once the commitment is made, the order of reveals doesn't matter. Effectively we FIFO queue commitments in the order they're submitted, and then process the commitments as we're able to resolve them (either by a user-submitted reveal, or by expiration time arriving).
If a user hasn't revealed their commitment (i.e. they've dropped out), they will effectively block all later users in the FIFO from receiving their names. This is why we have an expiration, it forces a resolution of the queue item at a defined point in time. So from individual user Alice's point of view, as long as she reveals before her commitment's expiration, in the best case (Alice is first in the queue when she reveals) she will get her name immediately upon revealing it, in the worst case (Eve committed to a name before Alice in the same block and then dropped out) Alice will get her name at the expiration time.
Note, the FIFO logic's correctness relies on an assumption about expiration times. Namely, if Alice makes a commitment before Bob, then Alice's expiration time must be less than or equal to Bob's expiration time.
mvandeberg
realnedscott
WARNING: DO NOT USE THIS NAME RESERVATION MECHANISM ON THE MAIN NETWORK UNTIL CODE FOR A CLI_WALLET IMPLEMENTATION OF THIS FEATURE LANDS IN A NUMBERED RELEASE IN THE MASTER BRANCH OF STEEMD.
Earlier today @nedsteem raised the following problem:
After some discussion, @mvandeberg and I actually think the problem may be more precisely stated as follows:
This restatement of the problem suggests a potential solution: Alter the design to allow a mechanism to reserve names before the hardfork occurs. Then the situation becomes:
So what would be the requirements and implementation details of this pre-registration of names mechanism?
From these requirements we have the following consequences:
Requirements (1) and (2) imply we cannot use a custom operation, we need to re-purpose some existing operation capable of sending STEEM / SBD to the null account. The transfer operation is the obvious choice, but we might also be able to make it work with some other operation (e.g. escrow operation).
Requirements (1) and (3) imply we cannot use STEEM, because we have no way to reject a transfer that's too small. Potential solutions are either (3s1) fix the amount of STEEM fee and hope the price of STEEM does not fluctuate too much between now and 0.21, or (3s2) require the fee to be paid in SBD.
Requirement (5) suggests a cryptographic commit/reveal scheme. Basically you pay the fee and say "I want to register a token name," but you only publish a cryptographic commitment, not the name itself. The cryptographic commitment expires a few days after hardfork 0.21 takes effect. After you reveal the name matching your commitment, your registration can't become effective until all prior commitments by all other users have either been revealed or expired (because one of those users might have happened to create a commitment the same name, and in this case, we want to give the commitment to the earlier registration even if it revealed later).