Topic: NodeBank - Concept for a p2p banking network (Read 4198 times)
+1 watching this thread
Meni:
your ideas have merit ... Ripple, Loom, Open Transactions are also pieces with similar lines and shapes ... it is like a jigsaw.
Thanks, I'll look into those more closely. your ideas have merit ... Ripple, Loom, Open Transactions are also pieces with similar lines and shapes ... it is like a jigsaw.
Meni:
your ideas have merit ... Ripple, Loom, Open Transactions are also pieces with similar lines and shapes ... it is like a jigsaw.
I was going to make a new thread but you made one first. Instead of using an arbitrary "trust" variable which some smartypants could skew, why not just use the concept of bitcoin itself? Let''s call the architecture "Bitchange" because I think it sounds cool.
I was talking with a friend about the Mt.Gox debacle and he had an idea for a new mining opportunity, while increasing market security.
They aren't anybody with economic, programming or common sense experience. This is just a high-ass idea.
Trading would be handled with the Bitchange client program, like Bitcoins.
Trading security and confirmations would be handled by the mining machines.
Trading information security distribution would be handled by tradepools.
My argument to him is the 50btc newblock reward can't be integrated. This looks like a serious detractor.
He said there should be enough transactions to support it using a responsive, floating percentage fee.
exchange fee --> mining roi (a marginal roi, imo)
exchange nodes --> mining pools (who would get paid very little)
exchange market --> bitchange network & executable
+security enhanced
- very ddos resistant; would require all tradepools to be synchronously attacked
- distributed records; hostile entities might be statistically identifiable
-- might discourage nefarious people
- no email or password requirement, personal security=caveat emptor
- no central exchange point
-- no market control through exchange control
- open to audit from blockexplorer equivalent
- transactions guaranteed via math & mining, not trust
- new, risky trading systems are forced to be market independent (derivatives market, etc.)
+extreme redundancy
- exchange history core distributed amongst all traders & miners
--financial scams much easier to prove existing (Madoff, Ponzi, etc.)
- use of legal exchange points using a mining pool distribution concept
- any fiat currency might be exchanged based on liquid availability (is this even legal/possible?)
- world bitchange market + external exchanges (TradeHill, Mt.Gox, etc.)
=unknowns
- considerations for in/exclusion should be made regarding the operation of robotic trading
- market/trade reaction times inherently delayed
-- slower speed may contribute positively to market stability
-what about fiat currency handling? dwolla, libertyreserve?
--If for example Dwolla is used, how would dwolla bucks be transferred & secured?
--If for example Dwolla goes out of business, what options for fiat:btc exchange exist?
-would direct fiat trade be statistically non-anonymous, or even possible at all?
Technical problems for contemplation:
Trading is normal, all systems nominal, then TradepoolX is knocked offline from DictatorZ.
Would the market be effected in any way?
If DictatorY cut out the internet would the blockchain be effected? (Re: English market & Libya)
Would a Mt.Gox attack occur ONLY if every effected trader has been infected/compromised?
Would traders obviously going about hostile business be restricted with a price-band?
An example would be +-20% of current price. A current price of $17 would set minimum sell to ~$14.
Again, this is just a stupid, high-ass idea and probably wouldn't work.
I was talking with a friend about the Mt.Gox debacle and he had an idea for a new mining opportunity, while increasing market security.
They aren't anybody with economic, programming or common sense experience. This is just a high-ass idea.
Trading would be handled with the Bitchange client program, like Bitcoins.
Trading security and confirmations would be handled by the mining machines.
Trading information security distribution would be handled by tradepools.
My argument to him is the 50btc newblock reward can't be integrated. This looks like a serious detractor.
He said there should be enough transactions to support it using a responsive, floating percentage fee.
exchange fee --> mining roi (a marginal roi, imo)
exchange nodes --> mining pools (who would get paid very little)
exchange market --> bitchange network & executable
+security enhanced
- very ddos resistant; would require all tradepools to be synchronously attacked
- distributed records; hostile entities might be statistically identifiable
-- might discourage nefarious people
- no email or password requirement, personal security=caveat emptor
- no central exchange point
-- no market control through exchange control
- open to audit from blockexplorer equivalent
- transactions guaranteed via math & mining, not trust
- new, risky trading systems are forced to be market independent (derivatives market, etc.)
+extreme redundancy
- exchange history core distributed amongst all traders & miners
--financial scams much easier to prove existing (Madoff, Ponzi, etc.)
- use of legal exchange points using a mining pool distribution concept
- any fiat currency might be exchanged based on liquid availability (is this even legal/possible?)
- world bitchange market + external exchanges (TradeHill, Mt.Gox, etc.)
=unknowns
- considerations for in/exclusion should be made regarding the operation of robotic trading
- market/trade reaction times inherently delayed
-- slower speed may contribute positively to market stability
-what about fiat currency handling? dwolla, libertyreserve?
--If for example Dwolla is used, how would dwolla bucks be transferred & secured?
--If for example Dwolla goes out of business, what options for fiat:btc exchange exist?
-would direct fiat trade be statistically non-anonymous, or even possible at all?
Technical problems for contemplation:
Trading is normal, all systems nominal, then TradepoolX is knocked offline from DictatorZ.
Would the market be effected in any way?
If DictatorY cut out the internet would the blockchain be effected? (Re: English market & Libya)
Would a Mt.Gox attack occur ONLY if every effected trader has been infected/compromised?
Would traders obviously going about hostile business be restricted with a price-band?
An example would be +-20% of current price. A current price of $17 would set minimum sell to ~$14.
Again, this is just a stupid, high-ass idea and probably wouldn't work.
seems like a good idea, woukd love to start a bank client/server/whateveryouwannacallit. I havent read it all yet, since its painfull on a 2inch screen...
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.
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.
I was thinking of something similar.
My thoughts were that you could leverage real world trust between friends.
For example, a user would run the client and create a username. They could then add some of their friends to the client and set maximum trust values + fee levels. The person might set it at $20 trust. This means that they would trust their friend to pay them back up to $20 (probably don't want to set it to high, or could cause strain on the friendship).
To send money between 2 people, you just need to create a chain (or as you point out multiple chains) that has enough slack. Each client would sign their part of the transaction.
The only way someone could be ripped off is if their friend refuses to pay. The system assumes you can trust your friends (hopefully).
Leaving your client running would end up giving fees.
Also, with something like an ebay rep system, you could end up with lots of people around the world who would be willing to the "last-mile".
Most banks charge almost nothing for internal bank transfers. You would just need to find someone in the same bank as you and have them transfer money to your account (or you send money to theirs).
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.
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.
Jump to: