I guess this would be a crazy fork and probably nobody wants something like this but me.
Um, I actually find this fairly interesting. It looks like you're continuing some mailing list discussion here, can you please point me to original discussion so I can learn more?
First of all, sorry for taking so long to answer.
The first time we talked about implementing ripple on top of bitcoin was here:
https://bitcointalk.org/index.php?topic=3557.0http://groups.google.com/group/rippleusers/browse_thread/thread/eac0505ca4e5b839But maybe you mean the previous discussion about the atomic swapping in the
bitcoin mailing listI believe that a ripple-like thing can be potentially more awesome that "colored bitcoins", but it would be much easier to get "colored bitcoins" up and running so that's what I'm doing now. But I want to return to ripple ideas later...
Actually colored coins are also an implementation of ripple on top of bitcoin. My crazy fork, ripplecoin, is about removing the need to use satoshis as tokens. Let anyone issue as much as they like and separate the accounting of that issued credit (be it bonds, fiat deposits or e-gold) from the "hostcoin" accounting. Jgarzik argues that requiring satoshis is not a disadvantage but a good measure to avoid spaming, but I can't see why fees should fail.
I have a sketch of a simple distributed ripple implementation which is based on message timestamping. It isn't designed to be compatible with blockchain in any way other than blockchain can be used to timestamp messages to get them into order.
But it looks like you've found some way to make it based on Bitcoin implementation, which might have some advantages, I guess, so I want to learn more...
Your proposal sounds pretty much like the current main design for distributed ripple. A two-phase approach in which "registries" (or timestampers) provide the atomicity. The current design is very flexible and allows various commit methods. Here's the main protocol:
http://ripple-project.org/Protocol/ProtocolThere's also a
blockchain commit method.
But the same concept of transitive atomic trades of credit tokens is also possible with colored coins. The A -> B -> C example I used before is a simple Ripple transaction, for the generic one you just substitute the number of arrows, 2 for n.
I don't see any impediment to do it with the rules you have described, it's just about creating the transaction that includes the credit path and all participants signing it.
My only disagreement here is...why credit units need to contain satoshis at all? Why not making the accounting for the credit currencies inside the blockchain (enforced by the protocol) for free when the expensive stuff is hashing and fees must be paid in the host
cash anyway?
It's great to have an implementation that doesn't require a fork though.