From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YANgj-0007B5-3X for bitcoin-development@lists.sourceforge.net; Sun, 11 Jan 2015 18:56:37 +0000 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; Received: from mail-wi0-f177.google.com ([209.85.212.177]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YANgh-00073Y-JC for bitcoin-development@lists.sourceforge.net; Sun, 11 Jan 2015 18:56:37 +0000 Received: by mail-wi0-f177.google.com with SMTP id l15so10876928wiw.4 for ; Sun, 11 Jan 2015 10:56:29 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.235.193 with SMTP id uo1mr22486627wjc.105.1421002589508; Sun, 11 Jan 2015 10:56:29 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.194.188.9 with HTTP; Sun, 11 Jan 2015 10:56:29 -0800 (PST) In-Reply-To: References: Date: Sun, 11 Jan 2015 19:56:29 +0100 X-Google-Sender-Auth: E1_XvjJfst6sXmf-NKniuEHG-WM Message-ID: From: Mike Hearn To: Gregory Maxwell Content-Type: multipart/alternative; boundary=089e01419e02929aba050c64f292 X-Spam-Score: -0.5 (/) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1YANgh-00073Y-JC Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Bi-directional micropayment channels with CHECKLOCKTIMEVERIFY 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: Sun, 11 Jan 2015 18:56:37 -0000 --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
Firstly, apologies to Nathan for not actually providing feedback on his pr= otocol. 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 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's protocol generalises to n-party HFT.

<= div>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 cha= in being the base layer that syncs everyone up, and higher layers doing thi= ngs 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 puttin= g resource control considerations to one side, it's possible that tx re= placement would be the same. Or not. The calculation for miners isn'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're thinking.

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'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.

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'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&quo= t; in this case can mean lots of fancy crypto things beyond old-fashioned g= ovt 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 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.

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?
--089e01419e02929aba050c64f292--