Storing Contracts in the Name Registry

[FrictionlessCoin]

It has occurred to me that Namecoin name registration may allow users to store not only DNS entries, but contracts.

More specifically Ricardian Contracts (see: http://iang.org/papers/ricardian_contract.html )

By registering ricardian contracts, systems may be able to use Namecoin as a means of more complex financial instruments like Bonds, Options etc.

[moa]

Yes. You could easily store the hash of a ricardian contract in a namecoin name (or value) fields.

You could also use the namecoin private-public key pair associated with the storage of the name/hash for the signing of the ricardian contracts who's hash is stored at that name .... many interesting possibilities then arise.

Basically this extends the immutable data to any arbitrary size field, held in an ancillary database e.g., without bloating the blockchain but still having the security anchored in the p2p namecoin blockchain by the hash.

[jdbtracker]

You could do quite a few things with the Blockchain, make a separate namespace for the contracts so that you could download only contracts instead of the whole Blockchain, without sacrificing security of your contracts. Namespaced for easy archiving of Contract Hashes.

[virtual_master]

It has occurred to me that Namecoin name registration may allow users to store not only DNS entries, but contracts.

More specifically Ricardian Contracts (see: http://iang.org/papers/ricardian_contract.html )

By registering ricardian contracts, systems may be able to use Namecoin as a means of more complex financial instruments like Bonds, Options etc.

Yes. This would be an interresting development direction.
Do you have some concrete plans to develop something for contracts ?

[drllau]

The problem I see is that contracts are not a static piece of paper with fixed hash but a living almost social document. For example, when I design licensing agreements, I have the general contract, some boilerplate and then annexes which are amended under some designated notification procedure (eg adding more patents as they issue). Financial instruments are even more complex, governed by master documents with options to insert/select whole chapters and then nominated machinery for the boundary cases. So whilst a simple registration service may suffice (eg notary) it just not suited for a modern contract.

[cassini]

The problem I see is that contracts are not a static piece of paper with fixed hash

This is not a problem but an advantage of Namecoin. You can issue a name_update at any time and change/add/remove registry data.

[drllau]

> change/add/remove registry data.

this shifts the problem from one of content coherence to that of authority ... who has the authority to change the terms of a contract, (perhaps unilaterally without notice as with some SNS terms) and identification of those authorities and processes for transfer of authority (eg power of attorney, death of estate, court seizure). So a technical solution is only a small component in the overall legal contracting model ... think of it more as an evershifting web of relationships and if you have an update cycle of several hours, then not so suited for ... say high frequency trading.

[MWD]

Some thoughts on this, new thread because it's similar, but also different.
http://forum.namecoin.info/viewtopic.php?f=2&t=1593

[khal]

> change/add/remove registry data.

this shifts the problem from one of content coherence to that of authority ... who has the authority to change the terms of a contract, (perhaps unilaterally without notice as with some SNS terms) and identification of those authorities and processes for transfer of authority (eg power of attorney, death of estate, court seizure). So a technical solution is only a small component in the overall legal contracting model ... think of it more as an evershifting web of relationships and if you have an update cycle of several hours, then not so suited for ... say high frequency trading.

A contract must be signed by 2 parts at least, so, each part must sign the contract and store the sign in namecoin.
One can change the contract, sign it, and other contractors can sign it too, or not.
By using the history of the 2 (or more) names, you can find the most recent contract signed by the 2 (or more) contractors.

I agree that it doesn't solve everything, but it still permits interesting ones.
And, for ex, you can also combine this with multisig to address some of the other problems.


ps: namecoin (and all blockchain coins in general) is not conceptually designed for high frequency trading (RT and huge volumes).

[drllau]

A contract must be signed by 2 parts at least, so, each part must sign the contract and store the sign in namecoin.
One can change the contract, sign it, and other contractors can sign it too, or not.
By using the history of the 2 (or more) names, you can find the most recent contract signed by the 2 (or more) contractors.

I agree that it doesn't solve everything, but it still permits interesting ones.
And, for ex, you can also combine this with multisig to address some of the other problems.

the multisig concept has interesting ramifications, for example, in micro-financing, there are group endorsements which basically tacitly keep the borrower on track and under peer purview they don't do stupid things like spend the money on wine, women and song (not that female entrepreneurs are any less capable but in some societies, they have a hard time being under economic thumb of others). So whilst there be be privity of contract between two, there would be multiple witnesses, perhaps even formal guarantor which can enhance the value proposition (remember that lawyers are one of the most conservative bunch of monkies on this planet).