I've been thinking about ripple, bitcoin scripts, p2p stock and currency markets, etc. I want to propose a generic protocol so that it can be shared for all those systems. The communication mechanism is out of the protocol like in Open transactions.
Vocabulary
Asset: a message with an amount transferred from one public key (PuK) to another.
Transaction: a message that proves that one or more assets are moved.
Promise: an incomplete transaction. It needs more signatures (and often more content too) to become a valid transaction.
Script: a scripting language similar to bitcoin's. Not Turing-complete to avoid infinite loops on verifications.
----------
Roles
Minter: Its signature it's required for creating new assets. It's responsible for the "backing" of those assets.
Accounter: A minter trust it for signing the movements of its issued assets. It's responsible for preventing double-spending. It's supposed to be always online. A minter can also act as its own accounter.
Timestamper: The actors of a transaction trust one of them or a minimum number of them from a list to provide atomicity to transactions in which several assets are moved. They're not mandatory but prevent DoS attacks. They are equivalent to
registries in the
decentralized ripple protocol draft.
Authenticator: Provides digital certificates and a legal base to the assets by linking a certain public key to a legal contract. Here must be specified if the asset is an IOU, a bond, a stock share, there's an interest rate, etc. They're not mandatory and the protocol can still be used informally.
Market: Receives and stores promises. It is queried by other actors and markets. Its nature is mostly public. For transitive transactions (like ripple's), it
search for paths.
Client: The actual users trading the assets.
Proof of work chain: a bitcoin-like system. Acts simultaneously as a Minter, Accounter and timestamper for certain assets.
A chain where anyone can be a minter could be created too.
Examples of assets: currencies backed by fiat by, bonds and stock shares, rippleIOUs, access keys for smart property...
Use cases:
-Trade assets directly for bitcoins using the chain as timestamper. Examples:
-Trade assets instantly with a timestamp server.
-Decentralized Ripple
-Transitive transactions (I have nmc and you accept btc. I sell nmc for mtgoxUSD, mtgoxUSD for btc and I pay you all within the same transaction)
-Circular trades (like the above but I get another asset from you instead of a receipt).
EDIT: I have to rewrite the following design: it's flawed.
-----------
Messages (protocol buffers)
message BlockChain {
required string nombre = 1;
required bytes genesis_block_hash = 2;
optional int32 checkpoint_block_number = 3;
optional bytes checkpoint_block_hash = 4;
}
Identifies a proof of work chain like bitcoin or namecoin.
message Minter{
optional PublicKey/hash? minter = 1;
optional BlockChain block_chain = 1;
}
A minter can be either a block chain or a regular node.
message Asset{
optional Minter minter = 1;
optional PublicKey/hash? accounter = 2;
required double amount = 3;
optional PublicKey/hash? receiver = 4;
optional PublicKey/hash? sender = 5;
}
For an asset to be valid, it also needs a proof containing at least the signatures of the the accounter and the sender.
If the accounter or the sender are not specified, the minter takes its duties and have to sign for them. Unless an asset says they will specified later (specifies a variable rather than an actual public key).
Not all the participants of the transaction know every asset, only the ones that are relevant to them.
message Script {
repeated byte assets_hashes = 1;
repeated string?bytes? commands = 2;
}
The whole Script message is what the OP_CHECKSIG in the script need to sign. The second field contains the actual commands of the script.
message Proof {
required Script script = 1;
repeated bytes signatures_hashes_secrets = 2;
}
The second field contains the signatures, hashes and secrets, etc. Whatever is needed for the script to return true.
message Transaction {
repeated Proof proofs = 1;
}
To be valid, all the proofs must be valid. Timestampers don't need to read the assets, they just need to sign the Scripts.
The script language should have an OP_CHECKTIMESTAMP operation with two parameters, the signature and the expiry time.
Since proof of work chains can act as timestampers, a similar operation is needed for them. The expiries are expressed as block numbers and the chains must be identified. A hash of the genesis block or that and the hash of a given checkpoint block should be enough.
If a chain is designated as a timestamper, there must be an asset without minter affected by the timestamp and a transaction corresponding to that asset must appear in the chain.
------------
Use cases:
A) Trade assets directly for bitcoins using the chain as timestamper. Examples:
minter and accounter: mtgoxUSD
market: something of the the sort of Dark exchange or just a regular server
A puts a promise (incomplete transaction) that contains the following (10 btc for 60 mtgoxUSD):
asset1 = {minter = mtgoxUSD_PuK, amount = 60, sender = A1_PuK, receiver = $asset1.receiver}
asset2 = {minter = bitcoin, amount = 10, sender = $asset1.receiver, receiver = A2_PuK}
script1 = {
assets_hashes = {hash(asset1), hash(asset2)},
commands = {OP_CHECKSIG A1_PuK, OP_CHECKSIG $asset1.receiver, OP_CHECKSIG mtgoxUSD_PuK, OP_CHECKTIMESTAMP bitcoin 170000}
}
proof1 = {
script = script1,
signatures_hashes_secrets = {A_PuK1_signature}
}
transaction1 = {
proofs = {proof1}
}
B sees the transaction in the market and wants the 60 mtgoxUSD
He fills $asset1.receiver = B1_PuK. Signs the transaction and sends is to mtgox to sign.
When he receives it back, he builds a bitcoin transaction with source = B1_PuK, destination = A2_PuK and broadcasts it.
When the transaction is confirmed in the bitcoin chain transaction1 becomes valid.
This example could also be applied to bonds, stock shares or other assets instead of mtgoxUSD.
----
B) Trade assets instantly with a timestamp server.
minters and accounters: mtgoxUSD, tradehillBTC
market: something of the the sort of Dark exchange or just a regular server
asset1 = {minter = mtgoxUSD_PuK, amount = 60, sender = A1_PuK, receiver = $asset1.receiver}
asset2 = {minter = tradehillBTC_PuK, amount = 10, sender = $asset1.receiver, receiver = A2_PuK}
script1 = {
assets_hashes = {hash(asset1), hash(asset2)},
commands = {OP_CHECKSIG A1_PuK, OP_CHECKSIG $asset1.receiver, OP_CHECKSIG mtgoxUSD_PuK, OP_CHECKSIG tradehillBTC_PuK, OP_CHECKTIMESTAMP timestamper_PuK "22/01/2012 00:00:00"}
}
Both A and B must trust the timestamper. They can query the timestamper to see the state of the transaction.
----
C) Trades with not binding advertisements
In the two previous cases, A pre-signed the transaction and was binded to the promise, but the promise could lack its signature and be added later without the need of variables.
By the way, I'm not very confident about how variables are used here. Maybe they're not compatible with protocol buffers as I've used them in the previous examples.
----
D) Decentralized Ripple
With a chain as timestamper (paying a fee and with someone paying to himself) or a timestamp server.
Each ripple node is a minter.
accounters: ripplepay, villages...
markets: something of the the sort of Dark exchange (with the payer client also behaving as a market for searching the path), ripplepay, villages...
Consider the ripple transaction A -> B -> C -> D
Markets also calculate paths.
For example, A queries ripplepay_market "10 d's from A to D". The market looks in its database and answer with promises:
b's for a's at 1:1
c's for b's at 2:1
d's for c's at 1:4
so that 10 d's are 20 a's
There's no need to include the denomination, only the exchange rates are important.
Only the sender, receiver and accounter of each asset must know what it contains and the other participants can still see the hash of the asset and their signatures.
The payer of the ripple transaction, since he creates it, will know all assets involved in the transaction.
Binding promises (assets with variables) must be public for all participants in the transaction so that they can verify that the variables are being used properly.
E) Using secrets and bitcoin scripts to make contracts I haven't thought.
It seems a good idea to me, but maybe there's a fundamental flaw that I don't see. Any constructive criticism is welcomed.
What do you think?
What is missing or not needed?
