Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YLtx0-0000vu-EO for bitcoin-development@lists.sourceforge.net; Thu, 12 Feb 2015 13:37:02 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.177 as permitted sender) client-ip=209.85.212.177; envelope-from=oleganza@gmail.com; helo=mail-wi0-f177.google.com; Received: from mail-wi0-f177.google.com ([209.85.212.177]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YLtwz-0006aH-3U for bitcoin-development@lists.sourceforge.net; Thu, 12 Feb 2015 13:37:02 +0000 Received: by mail-wi0-f177.google.com with SMTP id bs8so4364055wib.4 for ; Thu, 12 Feb 2015 05:36:55 -0800 (PST) X-Received: by 10.180.10.66 with SMTP id g2mr3187323wib.61.1423748215045; Thu, 12 Feb 2015 05:36:55 -0800 (PST) Received: from [192.168.8.89] (pro75-5-88-162-202-99.fbx.proxad.net. [88.162.202.99]) by mx.google.com with ESMTPSA id l6sm5716662wjx.33.2015.02.12.05.36.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Feb 2015 05:36:54 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_9172849B-4A22-4F38-ADDD-F55AC540E975" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Oleg Andreev In-Reply-To: Date: Thu, 12 Feb 2015 14:36:52 +0100 Message-Id: <24A47357-8DB5-4225-AAFD-EF82159489A8@gmail.com> References: <20150212064719.GA6563@savin.petertodd.org> To: Mike Hearn X-Mailer: Apple Mail (2.1993) X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (oleganza[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1YLtwz-0006aH-3U Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 13:37:02 -0000 --Apple-Mail=_9172849B-4A22-4F38-ADDD-F55AC540E975 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 12 Feb 2015, at 13:49, Mike Hearn 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.=20 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.=20 --Apple-Mail=_9172849B-4A22-4F38-ADDD-F55AC540E975 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
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. 




= --Apple-Mail=_9172849B-4A22-4F38-ADDD-F55AC540E975--