Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.177 as permitted sender)
	client-ip=209.85.212.177; envelope-from=mh.in.england@gmail.com;
	helo=mail-wi0-f177.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <CAAS2fgTMKwo2LOAmW+WzFnHcE7UXvCKgi7WCQLMtGDn2eaxLDA@mail.gmail.com>
References: <CAGNXQMSSCtgiyFEGHS2ufuc-RZcAtpEJyFpQMDmNKd1qEDq5qA@mail.gmail.com>
	<CANEZrP0ZabL2S=UhB2u7en2AfrckPk5CQe0YN-i4eDXQK-LF6A@mail.gmail.com>
	<CAJHLa0NoDU+DOPfubhbVs8_Y92+uGG=mZ2+ruRCXkeULghWVVg@mail.gmail.com>
	<CANEZrP1H-_4XiG+Azm7M4FgLrayuML+kdQ7LineXsU3FUH6=Qw@mail.gmail.com>
	<CAAS2fgTMKwo2LOAmW+WzFnHcE7UXvCKgi7WCQLMtGDn2eaxLDA@mail.gmail.com>
Date: Sun, 11 Jan 2015 19:56:29 +0100
Message-ID: <CANEZrP3SE_=w_3K5YK2_L3JpiPp27Ykzbk79vn+3PsUAVWgzYg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=089e01419e02929aba050c64f292
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bi-directional micropayment channels with
	CHECKLOCKTIMEVERIFY
Precedence: list

--089e01419e02929aba050c64f292
Content-Type: text/plain; charset=UTF-8

Firstly, apologies to Nathan for not actually providing feedback on his
protocol. I've put pondering it onto my mental todo list. The notion of a
payment tree is interesting but complicated - I would need to think about
it and maybe draw myself some diagrams before having useful feedback here.
If you wanted to implement it, you could fork the existing code in bitcoinj
and extend it with the new functionality.

I raised the original Satoshi design mainly to inform and so the approaches
can be compared. It may well be that this proposed protocol is superior in
every way, in which case the nSequence approach would be of no further use,
assuming Nathan's protocol generalises to n-party HFT.

Replying now to Gregory:

I think we agree, and are just phrasing things differently (or slowly
groping towards consensus at the speed of email threads :-).

It's likely that over time Bitcoin will end up being multi-layered, with
the block chain being the base layer that syncs everyone up, and higher
layers doing things that miners either can't do or can't be trusted to do.
Like the proposal from GreenAddress to be a well known signer who is
trusted to not double spend.

From miners perspective, there are multiple schemes where they are viable
if cost(fraud) < benefit, at the moment unconfirmed transactions appear to
be an example of that, and putting resource control considerations to one
side, it's possible that tx replacement would be the same. Or not. The
calculation for miners isn't easy, because if they play by the rules then
they may have a long term and reliable income stream, but if they break the
rules then that payment traffic will migrate to other solutions and they
end up with nothing. Whether it's worth it depends on how long term they're
thinking.

If we imagine a hypothetical future where lots of economic activity is
being done over Satoshi-style replaceable contracts, and suddenly a new big
short-termist miner comes along who decides that just breaking the rules
will give him more profit before the business dries up, what would happen?
If fraud costs get too extreme the old fallback of a purely centralised
solution is always there - for software compatibility purposes this would
look like a trusted node who doesn't broadcast the transactions at all and
just keeps them centrally, then mines or broadcasts the final version
themselves. Client apps would just be configured to connect directly to
that node.

Making that more competitive means having more such nodes/miners, until
eventually you have a network of miners that are regulated by identity and
bannable and don't share the tx's outside their network. That probably gets
you 95% of the benefit of the old model with maybe 150% (wild ass guess) of
the costs. "Identity" in this case can mean lots of fancy crypto things
beyond old-fashioned govt name+address style.

I don't think that'd be just an expensive and inefficient PayPal, as you'd
still have the key difference that simplifies so much - the trusted third
party doesn't hold any funds on deposit and can't directly
steal/lend/gamble with any funds. To earn money by being corrupt requires
complicated schemes where they strike secret deals to favour one party or
another, and that corruption can then be easily detected and published, so
it seems like the risk is much lower.

Bitcoin is already a pretty complex ecosystem with different kinds of trust
and decentralisation models in use. I see the next 5-10 years as a giant
cost optimisation experiment  .... where are the best settings of the
various decentralisation/speed/fees/complexity/identity knobs for different
kinds of people?

--089e01419e02929aba050c64f292
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>Firstly, apologies to Nathan for not actually providing feedback on his pr=
otocol. I&#39;ve put pondering it onto my mental todo list. The notion of a=
 payment tree is interesting but complicated - I would need to think about =
it and maybe draw myself some diagrams before having useful feedback here. =
If you wanted to implement it, you could fork the existing code in bitcoinj=
 and extend it with the new functionality.</div><div><br></div><div>I raise=
d the original Satoshi design mainly to inform and so the approaches can be=
 compared. It may well be that this proposed protocol is superior in every =
way, in which case the nSequence approach would be of no further use, assum=
ing Nathan&#39;s protocol generalises to n-party HFT.</div><div><br></div><=
div>Replying now to Gregory:</div><div><br></div><div>I think we agree, and=
 are just phrasing things differently (or slowly groping towards consensus =
at the speed of email threads :-).</div><div><br></div><div>It&#39;s likely=
 that over time Bitcoin will end up being multi-layered, with the block cha=
in being the base layer that syncs everyone up, and higher layers doing thi=
ngs that miners either can&#39;t do or can&#39;t be trusted to do. Like the=
 proposal from GreenAddress to be a well known signer who is trusted to not=
 double spend.</div><div><br></div><div>From miners perspective, there are =
multiple schemes where they are viable if cost(fraud) &lt; benefit, at the =
moment unconfirmed transactions appear to be an example of that, and puttin=
g resource control considerations to one side, it&#39;s possible that tx re=
placement would be the same. Or not. The calculation for miners isn&#39;t e=
asy, because if they play by the rules then they may have a long term and r=
eliable income stream, but if they break the rules then that payment traffi=
c will migrate to other solutions and they end up with nothing. Whether it&=
#39;s worth it depends on how long term they&#39;re thinking.<br></div><div=
><br></div><div>If we imagine a hypothetical future where lots of economic =
activity is being done over Satoshi-style replaceable contracts, and sudden=
ly a new big short-termist miner comes along who decides that just breaking=
 the rules will give him more profit before the business dries up, what wou=
ld happen? If fraud costs get too extreme the old fallback of a purely cent=
ralised solution is always there - for software compatibility purposes this=
 would look like a trusted node who doesn&#39;t broadcast the transactions =
at all and just keeps them centrally, then mines or broadcasts the final ve=
rsion themselves. Client apps would just be configured to connect directly =
to that node.</div><div><br></div><div>Making that more competitive means h=
aving more such nodes/miners, until eventually you have a network of miners=
 that are regulated by identity and bannable and don&#39;t share the tx&#39=
;s outside their network. That probably gets you 95% of the benefit of the =
old model with maybe 150% (wild ass guess) of the costs. &quot;Identity&quo=
t; in this case can mean lots of fancy crypto things beyond old-fashioned g=
ovt name+address style.</div><div><br></div><div>I don&#39;t think that&#39=
;d be just an expensive and inefficient PayPal, as you&#39;d still have the=
 key difference that simplifies so much - the trusted third party doesn&#39=
;t hold any funds on deposit and can&#39;t directly steal/lend/gamble with =
any funds. To earn money by being corrupt requires complicated schemes wher=
e they strike secret deals to favour one party or another, and that corrupt=
ion can then be easily detected and published, so it seems like the risk is=
 much lower.</div><div><br></div><div>Bitcoin is already a pretty complex e=
cosystem with different kinds of trust and decentralisation models in use. =
I see the next 5-10 years as a giant cost optimisation experiment =C2=A0...=
. where are the best settings of the various decentralisation/speed/fees/co=
mplexity/identity knobs for different kinds of people?</div></div></div></d=
iv>

--089e01419e02929aba050c64f292--