Revocation

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Revocation

Post by biolizard89 »

phelix wrote:Revocation via a special address imho interferes with how the system is supposed to work.

In any case revocation should only allow to set the value to "REVOKED" and nothing else.

What about this:
* Allow renewal with the same value by anybody (no idea how this could be implemented)
* Use multisig for security (I like this suggestion a lot)
Hi phelix,

I'm not sure I understand the objection. What is wrong with allowing a revocation address to exist separately from an owner address? Most cryptosystems do this (including TLS), to my knowledge. Can you explain? I also think setting the value to "REVOKED" is insufficient, as this would allow a name owner to falsely claim that he has revoked his name. A special boolean flag (like "expired" now) would be much better for this usage.

I think allowing renewal with the same value by anybody should be optional if allowed; some users may want their name to expire and they should be allowed to do this.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

virtual_master
Posts: 541
Joined: Mon May 20, 2013 12:03 pm
Contact:

Re: Revocation

Post by virtual_master »

phelix wrote: * Allow renewal with the same value by anybody (no idea how this could be implemented)
This is a very good idea. Why not. If a friend or a fun of you sees that your domain is almost expiring could help you by renewing your domain with the same parameters. In that case no password is needed for renewal.(only the password for the wallet from where the coins are sent - if the wallet is encrypted)
phelix wrote: * Use multisig for security (I like this suggestion a lot)
:) This could be also implemented in the client for transaction which are sending coins.
http://namecoinia.org/
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Revocation

Post by biolizard89 »

virtual_master wrote:
phelix wrote: * Allow renewal with the same value by anybody (no idea how this could be implemented)
This is a very good idea. Why not. If a friend or a fun of you sees that your domain is almost expiring could help you by renewing your domain with the same parameters. In that case no password is needed for renewal.(only the password for the wallet from where the coins are sent - if the wallet is encrypted)
phelix wrote: * Use multisig for security (I like this suggestion a lot)
:) This could be also implemented in the client for transaction which are sending coins.
Yep, I like the anyone-can-renew idea too (it probably would have saved WikiLeaks' and Pirate Bay's asses), but I think it should be optional (probably enabled by default). Some people may want their domain to expire.

And yes, multisig is definitely a good idea.

Neither of these really replace the revocation functionality though.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

khal
Site Admin
Posts: 708
Joined: Mon May 09, 2011 5:09 pm
os: linux

Re: Revocation

Post by khal »

biolizard89 wrote: Yep, I like the anyone-can-renew idea too (it probably would have saved WikiLeaks' and Pirate Bay's asses), but I think it should be optional (probably enabled by default). Some people may want their domain to expire.

And yes, multisig is definitely a good idea.
Anyone-can-renew is a good idea. Having the ability to explicitly make a name expire would be required in that case (via a rpc call, or a flag [where?] to prevent renew).
However, the implementation of this might be crappy...

Several possibilities :
* name owner action required, more clean, involves third parties (good for the market) :
- a bunch of tx with nLockTime that are sent somewhere and anybody can re-transmit them when needed (can be done automatically be several services). Re-transmit is needed because old tx will be dropped from node memory after a moment.
- same thing without nLockTime, tx are stored on some trusted servers/third party
* anybody can renew, can also involves third parties (you pay someone for this service) :
- a hack to validate a name tx without a valid signed input if one output is the same as in the input (crappy powa)
- a script hash (p2sh) that allow this => if possible, best solution, can be used or not by the owner


Multisig would be a way to avoid a stolen key to be sufficient to loose a name.
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).
NamecoinID: id/khal
GPG : 9CC5B92E965D69A9
NMC: N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9
BTC: 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T

Register Namecoin domains with BTC
My bitcoin Identity - Send messages to bitcoin users
Charity Ad - Make a good deed without paying a cent

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Revocation

Post by biolizard89 »

khal wrote:Anyone-can-renew is a good idea. Having the ability to explicitly make a name expire would be required in that case (via a rpc call, or a flag [where?] to prevent renew).
However, the implementation of this might be crappy...

Several possibilities :
* name owner action required, more clean, involves third parties (good for the market) :
- a bunch of tx with nLockTime that are sent somewhere and anybody can re-transmit them when needed (can be done automatically be several services). Re-transmit is needed because old tx will be dropped from node memory after a moment.
- same thing without nLockTime, tx are stored on some trusted servers/third party
* anybody can renew, can also involves third parties (you pay someone for this service) :
- a hack to validate a name tx without a valid signed input if one output is the same as in the input (crappy powa)
- a script hash (p2sh) that allow this => if possible, best solution, can be used or not by the owner


Multisig would be a way to avoid a stolen key to be sufficient to loose a name.
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.

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?
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

khal
Site Admin
Posts: 708
Joined: Mon May 09, 2011 5:09 pm
os: linux

Re: Revocation

Post by khal »

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) ?
NamecoinID: id/khal
GPG : 9CC5B92E965D69A9
NMC: N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9
BTC: 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T

Register Namecoin domains with BTC
My bitcoin Identity - Send messages to bitcoin users
Charity Ad - Make a good deed without paying a cent

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Revocation

Post by biolizard89 »

Ryan is of the opinion that delegation via "import" may be sufficient for revocation; if we have support for an "anyone-can-renew" script. I'll check with the Tor guys when I have a few minutes to see if they think it's sufficient.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

indolering
Posts: 801
Joined: Sun Aug 18, 2013 8:26 pm
os: mac

Re: Revocation

Post by indolering »

Sorry to drag up such an old topic but I wanted to chime in and say that (at least for domain names) the PhishTank would nuke any high-profile cases and obvious scammers.

Of course, the technical solutions above minimize risk and they are the most important component of preventing domain stealing. Indeed, it is already much more difficult to steal .bit domains than ICANN domains. Sex.com was stolen with a fax and it took 5 years to get the courts to transfer the domain back. AFAIK, the owner of Sex.com is still trying to collect on damages he was awarded.
DNS is much more than a key->value datastore.

Post Reply