Thank you. Your comments give me hope.
Yes, I should write a prototype to see if the protocol needs more things and such.
But I wanted to post the draft here first in case someone tell me I was doing something terribly wrong or I wasn't considering something important.
I plan to add things in this order:
1) Implement regular trades and ripple trades (with multiple assets being moved)
2) Implement "binding promises"
3) Add support for bitcoin (and namecoin...)
4) Add support for blinded assets
Since I want to leave the communication layer of the scope, I'm not sure how should I implement the passing of messages. Maybe a dummy network interface.
Topic: A generic protocol for cryptographic assets - page 2. (Read 4719 times)
This work is very interesting. I think there's definitely potential in combining Ripple-like debt graph calculations with Bitcoin and atomic chain trades.
Generalizing this as you are doing is potentially also valuable, but I feel like the exact forms and protocols needed will become clearer after some of these applications are actually written.
Merging some of the ideas in Ripple with Bitcoin to create a distributed exchange feels like a good first goal. A transaction would set up pending trades between two parties that trust each other. The software builds and maintains the trade graph based on those transactions. After installing the app, you'd tell it who your friends are. Then you put in a trade, USD for BTC. The software tries to find a way to (partially) satisfy your trade through the nodes in the graph, and once it finds a solution executes a chain-traded transaction, so the trade graph chain is updated atomically with the Bitcoin chain. You would receive the BTC instantly and then owe some of your friends USD, they in turn may find they owe some of their friends USD, and so on.
You could try building such a system on top of your generic protocol, and get a feel for whether it genuinely simplifies things or just increases the complexity for no benefit.
Generalizing this as you are doing is potentially also valuable, but I feel like the exact forms and protocols needed will become clearer after some of these applications are actually written.
Merging some of the ideas in Ripple with Bitcoin to create a distributed exchange feels like a good first goal. A transaction would set up pending trades between two parties that trust each other. The software builds and maintains the trade graph based on those transactions. After installing the app, you'd tell it who your friends are. Then you put in a trade, USD for BTC. The software tries to find a way to (partially) satisfy your trade through the nodes in the graph, and once it finds a solution executes a chain-traded transaction, so the trade graph chain is updated atomically with the Bitcoin chain. You would receive the BTC instantly and then owe some of your friends USD, they in turn may find they owe some of their friends USD, and so on.
You could try building such a system on top of your generic protocol, and get a feel for whether it genuinely simplifies things or just increases the complexity for no benefit.
If variables are allowed in the non blinded assets, there's no need for booleans.
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?
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?
Jump to: