EDIT: the messages design here is probably flawed/obsolete. To know more about the general idea maybe the original post is better. For an updated and more concrete design better read about colored coins. This is basically the same without underlying satoshis (modfying the protocol)
I posted it in the Ripple forum, but some people may be interested here.
I want to propose the block chain as a mean to decentralize ripple
again. I think I've simplified the rippleCoin protocol.
The chain would act just as an exchange of IOUs.
Any address can generate new IOUs and transfer them to another address just like bitcoins are transferred.
The new owner of the IOUs can also transfer them.
Example:
add1 issues 10 units (the system doesn't care about the denomination) to add2. add2 transfers 5 units to add3. add3 transfers the 5 units to add1 and these IOUs are destroyed
Now, for ripple payments, imagine we have the ripple network: add1 <-> add2 <-> add3 <-> add4.
add2 offers up to 10 add2 IOUs for add1 IOUs at an exchange rate of 1 : 1.1 + 1
add3 offers up to 10 add3 IOUs for add2 IOUs at an exchange rate of 1 : 1.05
add4 offers up to 5 add4 IOUs for add3 IOUS at an exchange rate of 1 : 1
If add1 wants to pay 5 units to add4 he must:
1) Buy 5.25 add2 IOUs for 6.775 [(5.25 * 1.1) + 1] add1 IOUs
2) Buy 5 add3 IOUs for 5.25 add2 IOUs
3) Buy 5 add4 IOUs for 5 add3 IOUs
4) Transfer the add4 IOUs to add4
He could buy IOUs previously to increase its future liquidity, but if he hadn't, he only wants to make the 4 steps or none of them.
So to achieve atomic ripple payments within the block chain, there must be a type of super-transaction that includes smaller transactions and it can be only valid as a whole.
To incentive miners, rippleCoins are issued. To reward miners forever there's a few solutions, but I think the best is to have a stable monetary base (once the maximum has been issued) and destroy by demurrage as much as is given to miners.
RippleCoins can be traded for IOUs, increasing the liquidity of the system.
The connected nodes can share public keys to identify each other in the chain while maintaining a flexible level of privacy.
Trade offers can be sent to neighbors or broadcasted.
In summary we have 3 types of transactions that appear in the chain:
1) Simple transfers (of rippleCoins or IOUs)
2) Trades (of different IOUs or IOUs for ripplecoins)
3) Composite trades (composed of various trades)
Some specifications:
message TradeOffer {
required PublicKey seller;
optional PublicKey offeredIOUs;
required float maxAmount;
required float exchangeRate;
optional float flatFee;
optional PublicKey demandedIOUs;
required int expirationBlock;
required Signature sellerSignature;
}
* offeredIOUs or demandedIOUs must be defined (Doesn't make sense to trade rippleCoins for RippleCoins).
message Trade {
required TradeOffer offer;
required PublicKey buyer;
required float amount;
required Signature buyerSignature;
}
message compositeTrade {
repeated Trade trades;
optional int expirationBlock;
optional Transfer payment;
}
* A composite trade will expire when one of its trades expire, so compositeTrade::expirationBlock only makes sense when is lower than the lowest expiration clock of its trades.
** The payment transfer would be from the ripple payer to the ripple recipient and the currency would be IOUs issued by the recipient. The payer acquires them in this composite transaction, but they may have been issued before.
What do you think? Do you see any important flaw ?
NOTE: Ripplecoins could be exchanged for bitcoins too (within this decentralized chain) if the RippleCoin network watches the bitcoin blocks, which miners are going to store if there's merged mining anyway.
