path: root/8c/78e01a22a51b02a947307d8dabe8de1b66d4c1

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 <oleganza@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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 <oleganza@gmail.com>
In-Reply-To: <CANEZrP2YJxwVEocNXjc5cadcq6Wwed7vTLh_4zEX2ct7bTCz5g@mail.gmail.com>
Date: Thu, 12 Feb 2015 14:36:52 +0100
Message-Id: <24A47357-8DB5-4225-AAFD-EF82159489A8@gmail.com>
References: <20150212064719.GA6563@savin.petertodd.org>
	<CANEZrP2uVT_UqJbzyQcEbiS78T68Jj2cH7OGXv5QtYiCwArDdA@mail.gmail.com>
	<CAAt2M1-eogn58zC_eAs4qD4-1GaY4wtuXLoSJ-UEZGKgdXGFyg@mail.gmail.com>
	<CANEZrP2YJxwVEocNXjc5cadcq6Wwed7vTLh_4zEX2ct7bTCz5g@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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.=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

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div =
class=3D"">On 12 Feb 2015, at 13:49, Mike Hearn &lt;<a =
href=3D"mailto:mike@plan99.net" class=3D"">mike@plan99.net</a>&gt; =
wrote:</div><div class=3D""><span style=3D"font-family: HelveticaNeue; =
font-size: 14px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
float: none; display: inline !important;" class=3D"">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.</span></div></blockquote></div><br class=3D""><div class=3D"">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.</div><div =
class=3D""><br class=3D""></div><div class=3D"">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.&nbsp;</div><div class=3D""><br class=3D""></div><div =
class=3D"">Example:</div><div class=3D""><br class=3D""></div><div =
class=3D"">I pay $10. The following path is discovered and signed off by =
the Merchant who accepts an ad-hoc 0.3% fee:</div><div class=3D""><br =
class=3D""></div><div class=3D"">Me: $10 -&gt; $9.99 (Alice) -&gt; $9.98 =
(Bob) -&gt; $9.97 (Merchant).</div><div class=3D""><br =
class=3D""></div><div class=3D"">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 &gt;1%).</div><div class=3D""><br =
class=3D""></div><div class=3D"">Pros:</div><div class=3D""><br =
class=3D""></div><div class=3D"">- Decentralized.</div><div class=3D"">- =
Mere seconds to settle a payment.</div><div class=3D"">- Infinite =
scalability (no global consensus). Each payment involves 5-7 nodes =
only.</div><div class=3D"">- No trusted parties or federation (trust is =
"purchased" using "joint escrow" txs on blockchain)</div><div class=3D"">-=
 No funny currency, IOUs denominated in BTC.</div><div class=3D"">- No =
global consensus or protocol. Nodes can be semi-compatible, upgrade =
independently. All risks are local.</div><div class=3D""><br =
class=3D""></div><div class=3D"">Political problems solved:</div><div =
class=3D""><br class=3D""></div><div class=3D"">- No need to debate =
zeroconf transactions. We don't *need* them anymore to buy a =
coffee.</div><div class=3D"">- 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.</div><div class=3D""><br class=3D""></div><div =
class=3D"">Cons:</div><div class=3D""><br class=3D""></div><div =
class=3D"">- 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.&nbsp;</div><div class=3D""><br class=3D""></div><div =
class=3D""><br class=3D""></div><div class=3D""><br class=3D""></div><div =
class=3D""><br class=3D""></div></body></html>=

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