The payment systems we have today are designed as hierarchical trust networks for easy payment routing and rely heavily on active regulation to protect the delicate points of failure inherent in this type of structure. Regulation has been at best only moderately successful -- destabilizing "attacks" on national currencies by speculators are a regular occurrence -- and always controversial, as various interest groups compete to use single points of control as levers for advancing their agendas.

There are alternatives to the present arrangement. The Internet demonstrates the feasibility of routing information in an arbitrary network, by developing a standard protocol. Payments are nothing but information about obligations -- if paths can be found to route information, paths can be found to route payments. The difference is that while information is routed along "best-effort" paths through physical data networks, payments must be routed along reserved paths through abstract trust networks. Billions of trust relationships that exist outside the tightly-regulated global hierarchical currency network could be integrated into that network, removing single points of failure without harming the value of existing obligations. The resulting network would be more stable, and therefore require less regulation and be less expensive to use, while at the same time being more democratic and responsive to local concerns.

So there's Nxt, MasterCoin, BitShares (or is it ProtoShares?), eMunie, Open Transactions, all of which are supposedly going to be launched/released soon (any others?). It is very easy to market vaporware - just claim that your product has feature X, and it does. Since its just vaporware it can have all the best features before it even exists.

Ripple, on the other hand, actually exists and already has one major gateway (kraken next in line) and two chinese gateways (with rising CNY capitalization btw, up from 250k CNY in october to 539k CNY on Nov 12th to 787k CNY today).

The competition hasn't even left the starting line.

Use PGP.

Let me ask you a question: why would you accept someone's IOUs instead of XRPs?

I managed to write down what I conceptually want to create. You can read the description here.

Notice the difference with the Ripple, in the use of a shared Bitcoin wallet to back IOUs.

I don't know whether this can be implemented on the Ripple network. I suspect it is not possible: if I am correct, there are only a limited number of message types in the Ripple protocol, and some of the things I want to do probably don't fit in these message types.

There must be some kind of timeout.  If I promise to pay X, then I need to reserve that portion of the trust link.  If the IOU isn't cashed in, then I can purse the funding lock.

Hm.

How about this:

I'm A, I want to pay one btc to B with fast validation.   I have a preexisting relationship with C, and B has a pre-existing relationship with B.

I give C a signed transaction with an nlocktime somewhat in the future, covering the the amount, any fees C is charging me, and any BTC txn fees.  C gives a similar open transaction to B.    

If there are more exchanges between any of the parties we replace the transactions with updated versions that reflect the new outstanding balances. All of the is hidden from the blockchain until the locktime runs out.  After some time has passed without any changes, the lock time arises and the latest version of the transactions are published, settling the accounts.

A<->C can settle independently of B<->C.

Parties are vulnerable to double spending of the committed funds, but thats why they have a pre-existing trust relationship. They are assured that their activities are backed by funds their trusted peer has— at least fractionally (in the case of double spending).

This obviously works when C is a chain of parties too.

So my big question is: what percent of all transactions go to 0/unconfirmed and never actually verify? Is there any way to find this number and compare it to the percent of all credit card transactions which are reversed, transaction fees and CC fraud?

Most merchants are pretty accustomed to a plethora of possible fees and reversal scenarios for CC payments and as such have typically rolled an amount of expected loss into their business plans. The point of bitcoin is to make reversals impossible and blockchain errors rare - no matter what we do there will still always be a margin of error and a small bit of fraud. What's important isn't creating a flawless system, what's important is creating a BETTER system. If we can (provably) show that the expected rate of loss for BTC is drastically lower than credit card transactions and make it easy to use, merchants will adopt it more readily.

I think that is similar to the suggestion to use the bitcoin chain itself as register.

You should add a packet length field to your message system.

This allows older clients to ignore (or forward) any new packet types.  It also allows clients to use non-standard packets.

Yeah, I was wondering how you were planning to handle that.  A node could end up holding an IOU to the last link and then suddenly the transaction is canceled and he has an IOU from someone he doesn't trust.

If I get you... In your proposed system generating normal blocks would not be computationally intensive, but generating transactions would be.
Isn't this going the wrong way? This places the weight of the system on merchants with the rest of the market participants simply acting as consumers.

And what's to keep a couple of nodes from making dummy purchases from each other simply to create coin? That sounds more like banking as it exists today IMO.

0.01 of a confirmation on your network is actually worse than 0 confirmations on the Bitcoin network. With 0 confirmations you are protected somewhat by the TCP-level network, but anyone can reverse a transaction with 0.01 confirmation, overruling the TCP-level network.

It's a lot more data that lightweight clients will have to download. There's an 80-byte header per block that clients need. If this was required for every transaction, then lightweight clients would have to download about 17MB more data currently. This will become a lot more significant as the number of transactions per block increases. Also, if you have multiple "previous block" hashes in each transaction, you'll need headers that are much larger than 80 bytes. Normal clients will quickly lose the ability to send transactions.

OK then, how do you control the rate of currency inflation? Seems as though you are talking about a fundamentally different system that uses some of the same tools.

That doesn't help much. You need to wait until your transaction is buried deep enough in the chain for an attacker with less than 50% of the network's computational power to be unable to reverse it. If there are many smaller, easier blocks, you'll just have to wait 300 confirmations (or whatever) until that target is reached. In other words, you always must wait for the network to do a lot of work after your transaction.

It would provide more fineness in desired confirmations; you could accept transactions with 2.5 Bitcoin-equivalent confirmations. But it's bad for scalability, and the increased fineness isn't valuable, IMO.

If you want a real time confirmation, patch the client to check if the sender really have coins (it may already do this). Once it's done, you don't need to really wait for inclusion in 6 blocks, or even in 1 block (but a transaction can currently be ignored by all blocks and forgotten, or depends on another transaction still not included, so 1 block may be a minimum of security)

Wouldn't this be the same as having only one transaction per block?

How that merge would be made?

But if that were true then transaction volume would be pegged to the rate of block creation. The only way to increase circulation would be to have bigger transactions... Won't work.