From: Oleg Andreev <oleganza@gmail•com>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Date: Thu, 12 Feb 2015 14:36:52 +0100 [thread overview]
Message-ID: <24A47357-8DB5-4225-AAFD-EF82159489A8@gmail.com> (raw)
In-Reply-To: <CANEZrP2YJxwVEocNXjc5cadcq6Wwed7vTLh_4zEX2ct7bTCz5g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3256 bytes --]
> On 12 Feb 2015, at 13:49, Mike Hearn <mike@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.
[-- Attachment #2: Type: text/html, Size: 4827 bytes --]
next prev parent reply other threads:[~2015-02-12 13:37 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-12 6:47 Peter Todd
2015-02-12 7:23 ` Tamas Blummer
2015-02-12 7:45 ` Peter Todd
2015-02-12 8:27 ` Tamas Blummer
2015-02-12 8:49 ` Peter Todd
2015-02-12 9:01 ` Tamas Blummer
2015-02-15 20:51 ` Troy Benjegerdes
2015-02-12 8:16 ` Alex Mizrahi
2015-02-12 11:58 ` Mike Hearn
2015-02-12 12:23 ` Natanael
2015-02-12 12:49 ` Mike Hearn
2015-02-12 13:02 ` Natanael
2015-02-12 13:44 ` Mike Hearn
2015-02-12 14:36 ` Natanael
2015-02-12 14:53 ` Mike Hearn
2015-02-12 15:20 ` Natanael
2015-02-12 15:30 ` Justus Ranvier
2015-02-12 13:36 ` Oleg Andreev [this message]
2015-02-12 12:52 ` Alex Mizrahi
2015-02-12 13:18 ` Mike Hearn
2015-02-12 13:45 ` Alex Mizrahi
2015-02-12 13:52 ` Mike Hearn
2015-02-12 14:04 ` Tamas Blummer
2015-02-12 14:16 ` Mike Hearn
2015-02-12 14:25 ` Tamas Blummer
2015-02-12 23:08 ` Tom Harding
2015-02-12 14:32 ` Alex Mizrahi
2015-02-12 15:15 ` Mike Hearn
2015-02-12 15:32 ` Natanael
2015-02-12 15:42 ` Mike Hearn
2015-02-12 15:54 ` Natanael
2015-02-12 16:57 ` Btc Drak
2015-02-12 17:24 ` Oleg Andreev
2015-02-12 18:11 ` Justus Ranvier
2015-02-12 18:37 ` Allen Piscitello
2015-02-12 19:15 ` Alan Reiner
2015-02-12 19:34 ` Justus Ranvier
2015-02-12 19:45 ` Peter Todd
2015-02-12 19:49 ` Justus Ranvier
2015-02-12 19:47 ` Allen Piscitello
2015-02-12 19:52 ` Justus Ranvier
2015-02-12 20:02 ` Natanael
2015-02-12 20:36 ` Allen Piscitello
2015-02-14 14:47 ` Ross Nicoll
2015-02-12 20:06 ` Peter Todd
2015-02-12 19:49 ` Gregory Maxwell
2015-02-12 20:18 ` Peter Todd
2015-02-13 11:34 ` Mike Hearn
2015-02-12 12:54 ` Tamas Blummer
2015-02-12 14:42 ` Alex Mizrahi
2015-02-12 15:27 ` Jeff Garzik
2015-02-15 21:25 ` Troy Benjegerdes
2015-02-15 21:40 ` Adam Gibson
2015-02-19 8:56 ` Troy Benjegerdes
2015-02-21 19:09 ` Jorge Timón
2015-02-21 20:30 ` Mark Friedenbach
2015-02-21 22:47 ` Jeff Garzik
2015-02-22 1:15 ` Peter Todd
2015-02-22 3:25 ` Jorge Timón
2015-02-22 4:06 ` Jeff Garzik
2015-02-22 11:41 ` Eric Lombrozo
2015-02-22 12:06 ` Eric Lombrozo
2015-02-22 13:41 ` Eric Lombrozo
2015-02-22 13:53 ` Peter Todd
2015-02-22 23:29 ` Eric Lombrozo
2015-02-24 1:11 ` Jeff Garzik
2015-03-01 17:59 ` Troy Benjegerdes
2015-03-01 19:05 ` Neil Fincham
2015-03-01 17:44 ` Troy Benjegerdes
2015-02-12 16:15 ` Lawrence Nahum
2015-02-12 18:14 ` Tom Harding
2015-02-12 21:40 ` Josh Lehan
2015-02-22 16:36 ` Tom Harding
2015-02-22 17:12 ` Peter Todd
2015-02-22 19:25 ` Tom Harding
2015-02-22 21:50 ` Peter Todd
2015-05-04 4:36 ` [Bitcoin-development] New release of replace-by-fee for Bitcoin Core v0.10.1 Peter Todd
2015-05-05 2:23 ` Kevin Greene
2015-05-23 18:26 ` [Bitcoin-development] Replace-by-fee v0.10.2 - Serious DoS attack fixed! - Also novel variants of existing attacks w/ Bitcoin XT and Android Bitcoin Wallet Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=24A47357-8DB5-4225-AAFD-EF82159489A8@gmail.com \
--to=oleganza@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox