I think the block chain is the most brilliant, elegant way I've seen for independent machines to form a consensus.  My main issue with it is the delay in confirming transactions.

My idea is to have transactions added to the block chain individually, rather than in blocks.  What would happen is that multiple transactions would simultaneously be added to the head of the chain, which ought to be fine as long as they are all mutually compatible.  All that's needed is for further transactions to be able to build on multiple compatible transaction streams and merge them, rather than just picking one.  It's possible that a transaction gets merged into several different streams, but that actually helps its odds should it ever end up in a stream that ends up getting rejected.

Each transaction includes its own proof-of-work.  If there are two parallel streams containing incompatible transactions, the stream with the greatest cumulative proof-of-work in its history becomes valid, and the other is dropped.  Therefore peers are motivated to build on as many valid transactions as they know, to decrease the odds of their stream being dropped, meaning they will want to merge all the compatible parallel streams they know of in order to maximize the proof-of-work in their new stream.  Peers will also be motivated to include as much proof-of-work as they can in their own transactions, for the same reason.

One benefit of this arrangement is that it doesn't need transaction fees or any other reward to motivate third-party block computations.

Thoughts?

Ryan

Thanks for the reply.  It's a good point.  Being a bank and issuing your own debt-backed currency -- which is essentially what Ripple enables -- can be tricky.  The hope is that participants learn to handle defaults in the same way as banks:  They accept the loss in the context of overall assets and liabilities, rather than isolating particular liabilities they allowed to be incurred by granting the credit.  It really isn't your fault that Fred decided to trust Sue, and *you* have to trust Fred to be mature enough to acknowledge that.  If you don't think he is, then you shouldn't offer *him* credit. 

We will need to design the software to guide users' through these processes, as well as giving them advice and tools to make them continually aware of their own exposure to debt and prepare them for inevitable defaults, such as highlighting inactivity on risky accounts near their credit limit, and a way to to set aside a reserve fund, possibly from transaction fees or interest charged on loans.

It's definitely not a trivial problem, but I envision solutions evolving as more and more value is transacted in Ripple and it becomes more important.

Ryan

No.  Ripple only has a few non-distributed/single-server implementations that are still really proofs of concept.  We are working on a feasible distributed protocol, as well as designing marketplaces to motivate growth in the network.  I understand there is some interest in using a Ripple-type system for real-time approval of Bitcoin transactions in, for example, a POS setting, which is one of the motivators of renewed work on the protocol.

Ryan

Hi Mike.  I'd like to understand this concern...  If you're comfortable granting credit to a friend (ie, lending to them) on the system, why would you not be comfortable lending them your IOU to give to another one of your friends (ie, vouch for them)?  Obviously, you only have to grant credit to those people you trust to make good on their debts...  What am I missing here?  Thanks for your input.

Ryan

Ripplepay is a single-server implementation of the Ripple decentralized payment concept.  There's no distributed implementation yet.  Designs for a distributed protocol are here:

http://ripple-project.org/Protocol/Index

Ryan

Hi.  I'm the founder and main developer on the Ripple project.  Cool discussions going on here.  Something like Ripple would be a great way to allow for a decentralized network of independent account hubs for instantaneous payment.  You might want to implement it as a centralized hub first to get some people using it, work out some of the kinks and figure out exactly what you need, then worry about doing decentralized transactions as another phase.  If there are multiple competing hubs operating, they may all be motivated to work out the best way to interoperate.  I'll be glad to help: ryan@ripplepay.com.

You should also check out http://www.opentransact.org/ for the outward-facing payment API.

Ryan

Ripplepay.com, a system for transferring value through trust networks, and in particular social networks, now accepts Bitcoin donations.

https://ripplepay.com/donate/

For more information about Ripplepay, see ripple-project.org.

Ryan