> On 12 Feb 2015, at 13:49, Mike Hearn <m...@plan99.net> wrote:
> If unconfirmed payments become flaky enough that people stop using them, then
> a portion of the Bitcoin community will find workarounds like trusted third
> parties, trusted hardware, whatever and will just struggle one. Other people
> will look at the new tradeoffs/complexity, and decide that Bitcoin is no
> longer better for them than banks.
How about a Ripple-like IOU-based payment network that is 100% decentralized,
for "dumb and daily" payments only? IOUs will propagate from node to node and
will trusted because of a "joint escrow" transaction between each pair of nodes
(locking up certain amount on both ends in 2-of-2 multisig). Total amount of
debt from one node to another will be limited to 50% of the locked amount (e.g.
if both nodes lock up $20 each, they allow debt up to $10 in each direction).
When debt is reaching its limit, it's being "cleared" by debtor via a real BTC
transaction or simply by "closing" the contract transaction with correct
proportion on outputs to pay off the debt.
Every node may require an arbitrary fee for a service of providing his funds to
back IOUs, when making a payment, merchant/customer may find several possible
"paths" and choose the quickest/cheapest one to use. Centralization is possible
at a proportional capital expense. If some node wants to be Visa-scale with
millions of contracts and a lot of fees to earn, they'll have to lock up huge
amount of money. This puts natural limit on centralization or associated risk.
Example:
I pay $10. The following path is discovered and signed off by the Merchant who
accepts an ad-hoc 0.3% fee:
Me: $10 -> $9.99 (Alice) -> $9.98 (Bob) -> $9.97 (Merchant).
Now I owe $10 to Alice, Alice owes $9.98 to Bob, Bob owes $9.97 to Merchant.
Clearing of debts happens independently between each participant based on their
debt-to-capital ratio and whether any party wishes to exit. Of course, if
several paths are discovered within a reasonable timeframe, Merchant will
choose the cheapest one. And maybe abort transaction if the proposed path is
too expensive (e.g. total fee is >1%).
Pros:
- Decentralized.
- Mere seconds to settle a payment.
- Infinite scalability (no global consensus). Each payment involves 5-7 nodes
only.
- No trusted parties or federation (trust is "purchased" using "joint escrow"
txs on blockchain)
- No funny currency, IOUs denominated in BTC.
- No global consensus or protocol. Nodes can be semi-compatible, upgrade
independently. All risks are local.
Political problems solved:
- No need to debate zeroconf transactions. We don't *need* them anymore to buy
a coffee.
- No need to debate block size limit. It'd still be nice to raise it when
needed, but for 99% of transactions we'll have a good decentralized solution
off-chain, so the issue is less pressing.
Cons:
- Some amount of cash needs to be locked up with random nodes most of the time.
If one of the nodes is offline, payments can't be cleared through that node.
Although, it could not be a big problem as the network is useful for small-ish
payments and every node will have 10-15 contracts, so it will tolerate
occasional unavailability of some of them.
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
