Meni Rosenfeld (OP)
Donator
Legendary
Offline
Activity: 2058
Merit: 1054
|
|
June 22, 2011, 06:10:40 PM |
|
This is an idea I've been thinking about for a while. In fact one of the things that drew me to Bitcoin is that it provides an answer to some of what my idea tries to solve.
The plan is for a peer-to-peer banking system. Like traditional banks, it will allow you to make a deposit of any currency - be it government-issued, Bitcoin, or a future alternative cryptocurrency - and have the ability to transfer it to beneficiaries of your choice. Unlike traditional banking, you are not locked in to a single provider (whom you must trust with your entire fortune) and the barrier of entry to aspiring banks will be very low.
I can argue that even in a world dominated by cryptocurrencies, this system can have advantages - for example, instantaneous confirmations of large transactions. But speaking practically, government-issued currencies will exist for the foreseeable future and there will be a need for a good way to handle them.
This is only a very rough sketch of the plan, I can't hope to figure out all the details myself. I also cannot know for sure if this idea is novel, or if it was discussed before, or if it is so trivial it was never worth a mention.
The plan
Every user of the system will have a cryptographic identity (maybe more than one) for digital signatures and encryption, and be a node in the p2p network. There will also be many bank nodes (anyone can start one easily, it's basically just announcing to the network that you'd like to be a bank). Each bank node will hold locally a balance for each identity he's interacted with.
Every user will have a "trust value" associated with every bank, representing the maximum amount he is willing to deposit in it. Ideally there will be an algorithmic way to determine trust values based on the bank's history, not only with this user but also with other trustworthy users (a trust propagation reminiscent of Google PageRank) - but I can't yet think of a good way to do it and it's not strictly necessary. Instead the user will input manually how much he trusts several banks based on external information.
When Alice wants to send money to Bob, they need to negotiate (this is done automatically by the software) to find a bank node, Trent, to handle the transfer. In the simplest case this is a bank which Bob trusts with the amount and with which Alice has the amount in the balance. Bob sends Alice some identifier to recognize the transaction. Alice sends Trent a request to credit Bob and have the identifier part of the transaction. Trent moves funds from Alice's balance to Bob's, and sends Bob a confirmation of the transfer (he can also give Alice a copy).
In a more general case, Trent doesn't have to be trusted by both Alice and Bob. Rather, a strong enough path of trust must exist from both Alice and Bob to Trent. So there must be a path A -> X1 -> X2 -> ... -> Xk -> T <- Ym <- ... <- Y2 <- Y1 <- B, where an arrow means trusting with the required amount (and we assume that on the path from A to T, each node has the required balance with the next node). A informs X1 she would like to transfer money to B; X1 debits A's balance and takes on the assignment of delivering the money to B. This is done by requesting the transfer from X2, and so on; eventually T is trusted with delivering to B. This is done by crediting Ym's balance (which he trusts T to do) and requesting that he sends to B, and so on. Eventually B receives a payment confirmation containing the code he originally sent A, so he knows she paid.
Even more generally, there needn't be a single chain to handle the entire amount; if A's funds are distributed between several banks, or if not enough trust exists in a single chain, the payment can be done in several pieces accross several trust chains.
Sharing trust information to find this arrangement of chains will be the hardest part in the protocol. But if enough trust exists in the network an arrangement should be possible, and the mechanics of finding it should be doable.
Every bank node will charge a competitive fee for his services, and the negotiation will also include finding the flow with the least fees.
Depositing funds from the outside world into this system isn't too hard if we assume there is some bank that, while we don't trust to guard our savings for any length of time, we do trust to properly handle a sizable deposit without running away with the money. A deposit will be done in such a bank, with instructions on how to distribute it between other banks; It will use its trust relationships as well as bulk transfers to credit the required banks, and send the user confirmations.
Enabled technology: Distributed Bitcoin exchange
And now we get to the interesting part, why now of all times I decided to write this up. With the recent mtgox woes, there have been calls for the need of a distributed Bitcoin exchange. The reaction has generally been that this is impossible. I claim that with a distributed banking system in place, a distributed exchange can be built on top of it.
Alice wants to place a market order, say for buying BTC for USD. She informs Trent, a bank with which she has the USD balance needed for it, of her intentions. Trent freezes the amount and broadcasts the order. Thus the data on all pending orders is publicly available, and can be visually displayed by the client software or 3rd party services (like blockexplorer is to Bitcoin). Bob, who wants to execute Alice's order, finds a path of trust to Trent, and through it transfers BTC to Trent (each node in the path guarantees to the previous one that he will receive a refund if things go wrong). Trent credits Alice with the BTC, debits the USD, and sends the USD back to Bob.
And, incidentally, it needn't be a Bitcoin exchange. It can exchange any two currencies, making global currency exchange more competitive.
|