Namecoin Forum

Here's a spec that I wrote after a conversation with indolering. Feel free to poke holes in it.

---

Spec for trust-free Namecoin registrar services.
Author: Jeremy Rand
Revision 2

Larry owns d/google. Larry wants to ensure that d/google does not expire.

Mark runs a registrar service. Larry wants to contract Mark to ensure that d/google does not expire. Larry does not trust Mark to properly renew the name, nor does Larry trust Mark to not hijack/steal the name, nor does Mark trust Larry to pay fees for a successful renewal.

If Mark successfully renews d/google between Block X and Block Y, Larry wants to pay Mark 1 NMC for his services. However, if Mark (or Larry) renews d/google before Block X, Larry does not owe anything for this transaction. And if Mark fails to renew d/google before Block Y, Mark will forfeit 100 NMC to Larry in compensation.

Larry and Mark create a 2-of-2 multisig address, called ADDR. Larry and Mark create the following transactions:

(1) Setup tx: Larry transfers d/google to ADDR, + Larry transfers 1 NMC to ADDR, + Mark transfers 100 NMC to ADDR.
(2) Cancel tx: ADDR transfers d/google to Larry, + ADDR transfers 1 NMC to Larry, + ADDR transfers 100 NMC to Mark. Input transaction is the Setup tx.
(3) Renew tx: ADDR transfers d/google to Larry, + ADDR transfers 101 NMC to Mark; NLockTime = Block X. Input transaction is the Setup tx.
(4) Compensation 1 tx: ADDR transfers d/google to Larry, + ADDR transfers 101 NMC to Larry; NLockTime = Block Y. Input transaction is the Setup tx.
(5) Compensation 2 tx: ADDR transfers 101 NMC to Larry; NLockTime = Block Y. Input transaction is the Setup tx.

Mark signs the Cancel and Compensation tx's, and sends it to Larry. Larry does not share his signature with Mark, nor does he broadcast it. Larry signs the Renew tx, and send it to Mark. Mark does not share his signature with Larry, nor does he broadcast it. After all other transactions are created, the Setup tx is signed, broadcast to the network, and confirmed.

If Larry at any time decides that he doesn't want Mark's services anymore, he can broadcast the Cancel tx.

Mark must broadcast the Renew tx between Blocks X and Y. If he fails to do this, Larry can broadcast the Compensation 1 tx. If Larry fails to broadcast the Compensation 1 tx before the name expires, Larry can broadcast the Compensation 2 tx (which doesn't spend the now-unspendable name output).

This can be extended to multiple renewals by creating multiple iterations of the Cancel/Renew/Compensation transactions, which use the previous iteration as input. Like this:

(1) Setup tx: Larry transfers d/google to ADDR, + Larry transfers 2 NMC to ADDR, + Mark transfers 100 NMC to ADDR.

(2) Cancel A tx: ADDR transfers d/google to Larry, + ADDR transfers 2 NMC to Larry, + ADDR transfers 100 NMC to Mark. Input transaction is the Setup tx.
(3) Renew A tx: ADDR transfers d/google to ADDR, + ADDR transfers 1 NMC to Mark; NLockTime = Block XA. Input transaction is the Setup tx.
(4) Compensation 1 A tx: ADDR transfers d/google to Larry, + ADDR transfers 102 NMC to Larry; NLockTime = Block YA. Input transaction is the Setup tx.
(5) Compensation 2 A tx: ADDR transfers 102 NMC to Larry; NLockTime = Block Y. Input transaction is the Setup tx.

(6) Cancel B tx: ADDR transfers d/google to Larry, + ADDR transfers 1 NMC to Larry, + ADDR transfers 100 NMC to Mark. Input transaction is the Renew A tx.
(7) Renew B tx: ADDR transfers d/google to Larry, + ADDR transfers 101 NMC to Mark; NLockTime = Block XB. Input transaction is the Renew A tx.
(8) Compensation 1 B tx: ADDR transfers d/google to Larry, + ADDR transfers 101 NMC to Larry; NLockTime = Block YB. Input transaction is the Renew A tx.
(9) Compensation 2 B tx: ADDR transfers 101 NMC to Larry; NLockTime = Block YB. Input transaction is the Renew A tx.

If Larry wants to update the value of d/google, he will have to either use the Cancel tx (after which he can renegotiate the contract), or he will have to form a new transaction with the consent of Mark (along with new Cancel/Renew/Compensation transactions).

If Larry wants emergency insurance to prevent a name expiring because Mark was negligent, then Larry can contract another registrar Bill, like this:

ADDR becomes a 3-of-3 multisig.

(1) Setup tx: Larry transfers d/google to ADDR, + Larry transfers 1 NMC to ADDR, + Mark transfers 100 NMC to ADDR, + Bill transfers 100 NMC to ADDR.
(2) Cancel tx: ADDR transfers d/google to Larry, + ADDR transfers 1 NMC to Larry, + ADDR transfers 100 NMC to Mark, + ADDR transfers 100 NMC to Bill. Input transaction is the Setup tx.
(3) Renew tx: ADDR transfers d/google to Larry, + ADDR transfers 101 NMC to Mark, + ADDR transfers 100 NMC to Bill; NLockTime = Block X. Input transaction is the Setup tx.
(4) Insurance tx: ADDR transfers d/google to Larry, + ADDR transfers 100 NMC to Larry, + ADDR transfers 101 NMC to Bill; NLockTime = Block Y. Input transaction is the Setup tx.
(5) Compensation 1 tx: ADDR transfers d/google to Larry, + ADDR transfers 201 NMC to Larry; NLockTime = Block Z. Input transaction is the Setup tx.
(6) Compensation 2 tx: ADDR transfers 201 NMC to Larry; NLockTime = Block Z. Input transaction is the Setup tx.

Larry signs the Cancel tx last as before. Mark signs the Renew tx last as before. Bill signs the Insurance tx last. If Mark fails to broadcast the Renew tx before Block Y, Bill has until Block Z to broadcast the Insurance tx. If Bill also fails to broadcast the Insurance tx before Block Z, then Larry can broadcast a Compensation tx as before.

Adding N single-use insurance providers over R renewals adds O(N*R) transactions that must be signed.

Adding N R-use insurance providers over R renewals causes the transaction count to increase exponentially with R, and therefore will not scale. Insurance providers therefore must notify the client in the event that the Insurance tx is triggered, to make sure that the client can arrange a new registrar before the name expires 36k blocks later.

It is expected that the price of registrar services, insurance services, and the corresponding compensation will be decided by the market.

Not thought through every detail, but it sounds very interesting and seems to work as advertised from a quick glance. Nice work!

.

signup292 wrote:I don't mean to ignore the 'how' aspect, but after reading it, I'm not 100% on the high level purpose/advantage.

I imagine that the only reason I would pseudo-entrust another person to renew my NMC registration, is so that I wouldn't have to worry about running a client, creating transaction, checking stuff.

If by using this method, I would still need to run a client, send transactions, and check to see if the registrar actually renewed the domain, wouldn't I rather just do the renewal myself? I'm not sure I know how this takes worry/work out of renewal.

Wasn't there a proposal for the client to optionally renew automatically?

The use case here is if Larry owns a name, wants it to be renewed automatically, and doesn't want to rely on leaving his client open all the time. If Larry is running a Namecoin client 24/7, then automatic renewal in the client would be an alternative, but that's not necessarily the case. A lot of people have lost names because they forgot to run their client.

Furthermore, this method allows the keys to be kept in cold storage; just approve a few transactions in advance, and you never have to take keys out of cold storage again as long as the contract is in effect.

If you don't run a client locally, then you don't own the keys, and therefore you don't own a name to begin with (you're just renting someone else's name, which they can revoke at any time). Needless to say, that's a shitty idea that no one should ever be doing. This spec keeps the keys in the hands of the name owner.

No, you don't have to send transactions after it's initially set up. That's the whole point. The transactions are constructed in advance; once you've paid your money into the multisig address, you don't have to do anything for the duration of the contract.

If you assume that the registrar doesn't want to lose money, then you don't have to check whether the registrar renewed the name. If you're concerned about this, then use N registrars with insurance, as I demonstrated.

.

Hmmm.
It's an interesting logical construction but I am not sure if I understood what practical use could it have.
It is no question that the actual short name expiration is very nerving but why to complicate and deposit the renewal fee to a registrar (even if it is decentralized) if it could be easier(if implemented) a longer expiration time for a higher fee.
What advantage would it have over a direct longer name validity for the same coin amount what is deposited to a renewing registrar ?