consider removing salt from name preordering and registration

[shea256]

Currently the preorder hash is calculated as follows: hash(name + salt + scriptPubKey)

Matt Corallo points out that hash(name + scriptPubKey) is equivalent if the scriptPubKey has never been used before.

This would simplify things AND would save us a bunch of space in the name registration transaction (about 16 bytes, I believe).

The only thing we'd have to do is make it clear that people shouldn't reuse pubkeys (they shouldn't be doing so anyway) unless they want to risk that someone will try to dictionary attack them.

[shea256]

Realized that if we remove the salt, we could simplify the transactions by combining the register operation and the update operation.

The operation would be interpreted as a registration + update (in Namecoin this is called a NAME_FIRSTUPDATE) if the name was unregistered and there was a valid preorder operation. It would be interpreted as a regular update if it was registered AND owned by the scriptPubKey of the sender.

If we made this change, the new transaction formats of the operation types would be as follows:

Preorder

Outputs:

1. nulldata = hash(name, scriptPubKey)
2. name cost
3. change

B. Register + Update

Outputs:

1. nulldata = name, profile data hash
2. change

C. Transfer

Outputs:

1. nulldata = name
2. TO: new name owner
3. TO: new name admin
4. change

D. Renewal

Outputs:

1. nulldata = name
2. name cost
3. change

[muneeb-ali]

The only thing we'd have to do is make it clear that people shouldn't reuse pubkeys (they shouldn't be doing so anyway) unless they want to risk that someone will try to dictionary attack them.

Meaning that they can't send transactions from the same BTC address? What if I want to own multiple names with one private key? Also, it's recommended, but I feel a lot of people would just ignore the recommendation and re-user public keys.

[shea256]

1. Why would they want to own multiple names with a single address? If they want to record a single private key, they can use an hierarchical deterministic private/public key set (the preferred method with wallets today).
2. If they really insist on owning multiple names with the same address, they can register from separate addresses and then transfer the names to the same BTC address. OR they can take the risk of someone scanning them for hashes and trying to front-run them on name registrations. The system doesn't break down here, it just increases risk to determined attackers.
3. Some people might ignore the guidelines if they are manually constructing the name operation transactions, but if they use our command line client or any other reference implementation software it would work like a normal bitcoin wallet, where it'd just generate new private keys each time.

[jcnelson]

This has been addressed by requiring a preorder operation to use the address of an as-of-yet-unused key pair as the salt. The address will be revealed in the register operation, and used as the name's owning address. Any subsequent operations on the name must be sent from this address.

[shea256]

👍