biolizard89 wrote:I assume P2SH is capable of implementing anyone-can-renew, but I'm not 100% sure on this. That would indeed be a good way to implement anyone-can-renew.
Here is a short explain how bitcoin/namecoin works (correct me if I'm wrong, I've some difficulties with scripts & p2sh :p) :
- every tx output is sent to a script
- the standard script says : send the coins to this bitcoin address
- and the script also says : if you can make a signature from this address (you own the private key), you can spend the coins
With p2sh :
- the p2sh script says : send the coins to this hash (a p2sh address starting with '3' in bitcoin)
- and the script also says :
* if you can provide me a script whose hash is the same as the one included in my script
* and the script is valid, which means all criteria are verified (a multisig script for ex)
* and you can make a signature from the p2sh (you own the private key), you can spend the coins
With a multisig script, bitcoin needs to generate :
- a private/public key pair from a list of standard address + a number (like in the beginning of this doc:
https://gist.github.com/gavinandresen/3966071) and a p2sh address starting with '3'
- a "redeemScript" needed to spend the coins sent to the p2sh address
The requirements to apply this to anyone-can-renew are :
- name must be sent to the same address => the p2sh address
- the whole script of the name txOut must not change => same name_op, name_name, name_value
- the amount of the name txOut (locked coins) must not change (or not decrease at least)
- the person who renew the name must know the redeemScript matching the p2sh address
So, instead of this for a name_update :
Code: Select all
OP_NAME_UPDATE <my_name> <my_value> OP_2DROP OP_DROP OP_DUP OP_HASH160 <namecoin_address_hashed> OP_EQUALVERIFY OP_CHECKSIG
You would have something like this (this script does not fulfill the previous requirements, it is just an example) :
Code: Select all
OP_NAME_UPDATE <my_name> <my_value> OP_2DROP OP_DROP OP_HASH160 <p2sh_address_hased> OP_EQUAL
biolizard89 wrote:I don't think multisig as exists in Bitcoin meets the same variety of use cases that a dedicated revocation address gives. If my keys are compromised, and I'm running critical infrastructure and don't have any intention of selling my name, I want the ability to nuke the name. My understanding of what the Tor guy told me is that the lack of revocation is a serious issue that is an obstacle to Tor adopting Namecoin (there are other obstacles, but those are all already being worked on).
khal wrote:Revocation via a special address imho interferes with how the system is supposed to work.
Because it breaks the rule
once a name is renewed/sent to an address, you own it.
With revocation, trading of names will need to trust the other side, which will not be required we atomic trading (a same tx signed by both sides).
So, I think there's still a way of doing trust-free trades. All transactions that contain or are derived from a name transfer that has a revocation period should be flagged by the client as "pending." Then have a rule that if the name is revoked, the entire transaction transferring the name, and all transactions derived from it, are considered to be reversed. If an atomic transaction is performed to swap a name for some currency, and the name is then revoked, the currency transfer is reversed. Users who want to quickly have their name sales confirm will use short revocation periods (or 0 periods). Users who aren't planning to sell their name will use longer periods. This seems workable to me. Have I missed something?
If I translated the feelings of phelix with the right rule, I guess we are ok.
Do you have an idea how it would be implemented ("reversing" several txOut [one for a name and one for payment at least] already in the blockchain, defining/storing the revocation period) ?