tyzbit
updates protocol unworkable
Requiring the user to wait for the timelock to expire in order to update a mapping is unworkable. Let's say that what they've mapped is an email associated with a domain registration. Should they have used a work email and then switch jobs, having the registration point to an address that is no longer accessible until the expiration of the original contract timelock is pessimal. They would be forced to create a contested update, locking up even more bitcoin for a longer period to change the mapping.
I agree, and I appreciate the frank feedback as there are many areas that need attention like updating mappings.
A possible solution would be to have a "revocation" path in the script that can bypass the locktime, but that removes the financial incentive structures to stop namesquatting.
Another possibility I included early on was including a transaction puzzle in the script that finding the collision of two pieces of data with the same SHA1 hash would allow you to recover the funds and thus "revoke" the mapping, but that would create an incentive for those with SHA1 collision-finding powers to just "mine" Numerifides registrations, creating a poor experience.
By contrast, Blockstack's design allows for better handling of data updates since there are no locktimes to deal with. I think Numerifides' strength is requiring users to lock up funds to make registrations valid, as it makes it like Namecoin, but on the base chain and without spurious registrations.
In summary, a good update mechanism needs the following properties:
- Does not require removing locktimes
- Does not require the user to "beat" her own registration
- Differentiate between the "true" owner and someone attempting to usurp the registration
My crypto is lacking, but I think the answer will come from re-using the private and public keys used to create the initial "command" to create an "update" transaction that (without unlocking the original funds) allows the mapping to be changed. Nodes on the network should be able to take the commands and public keys and confirm they used the same private keys, and thus allow the update transaction without any encumberance such as locktime.
I'd love it if you provided feedback on #2 @jwilkins. While I haven't gone all the way down the rabbit hole of the performance implications of organizing all of these mapping updates, I think this is a good first step to a usable system.