Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Y9Zq8-0003mW-JS for bitcoin-development@lists.sourceforge.net; Fri, 09 Jan 2015 13:43:00 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.173 as permitted sender) client-ip=74.125.82.173; envelope-from=mh.in.england@gmail.com; helo=mail-we0-f173.google.com; Received: from mail-we0-f173.google.com ([74.125.82.173]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Y9Zq6-0003Zv-O2 for bitcoin-development@lists.sourceforge.net; Fri, 09 Jan 2015 13:43:00 +0000 Received: by mail-we0-f173.google.com with SMTP id q58so8013182wes.4 for ; Fri, 09 Jan 2015 05:42:52 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.92.116 with SMTP id cl20mr3521047wjb.71.1420810972698; Fri, 09 Jan 2015 05:42:52 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.194.188.9 with HTTP; Fri, 9 Jan 2015 05:42:52 -0800 (PST) In-Reply-To: References: Date: Fri, 9 Jan 2015 14:42:52 +0100 X-Google-Sender-Auth: 2kf2vmocGuIV8-hRWK8Yhdv8nqY Message-ID: From: Mike Hearn To: Jeff Garzik Content-Type: multipart/alternative; boundary=047d7bd910c252204b050c38554f 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: 1Y9Zq6-0003Zv-O2 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: Fri, 09 Jan 2015 13:43:00 -0000 --047d7bd910c252204b050c38554f Content-Type: text/plain; charset=UTF-8 The original design is documented at the bottom of here: https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party In this design, time locked transactions can be broadcast across the network and replaced by broadcasting a new transaction that uses higher sequence numbers. That's what the sequence number field is for. It was intended to allow arbitrary high frequency trading between a set of parties, though the "channel" notion is a simple way to think about the two party case. The issue is that you can broadcast transactions with a lock time far in the future to fill up memory, and keep broadcasting replacements to use up CPU time and bandwidth. Additionally, there is a school of thought that says Bitcoin must work even if lots of miners are malicious and willing to break arbitrary things in order to try and get more money. I don't think Bitcoin can really be a mainstream success under such a threat model, for a whole bunch of reasons (e.g. the economy relies pretty heavily on unconfirmed transactions), but under such a threat model there's nothing that forces miners to actually include the latest version in the block chain. They could pick any version. In the 2-of-2 channel model it takes both parties to sign, so clients can enforce that all versions have the same fee attached. I disagree with Gregory that people refuse to use protocols that are affected by malleability. There aren't any user-friendly apps that use refunds currently, so we have no idea whether people would refuse to use them or not. It's an open question. The answer would probably depend on the real prevalence of attacks, which is currently unknowable and likely application specific. --047d7bd910c252204b050c38554f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The original design is documented at the bottom of here:

In this design,= time locked transactions can be broadcast across the network and replaced = by broadcasting a new transaction that uses higher sequence numbers. That&#= 39;s what the sequence number field is for. It was intended to allow arbitr= ary high frequency trading between a set of parties, though the "chann= el" notion is a simple way to think about the two party case.

The issue is that you can broadcast transactions with a lo= ck time far in the future to fill up memory, and keep broadcasting replacem= ents to use up CPU time and bandwidth.

Additionall= y, there is a school of thought that says Bitcoin must work even if lots of= miners are malicious and willing to break arbitrary things in order to try= and get more money. I don't think Bitcoin can really be a mainstream s= uccess under such a threat model, for a whole bunch of reasons (e.g. the ec= onomy relies pretty heavily on unconfirmed transactions), but under such a = threat model there's nothing that forces miners to actually include the= latest version in the block chain. They could pick any version. In the 2-o= f-2 channel model it takes both parties to sign, so clients can enforce tha= t all versions have the same fee attached.

I disag= ree with Gregory that people refuse to use protocols that are affected by m= alleability. There aren't any user-friendly apps that use refunds curre= ntly, so we have no idea whether people would refuse to use them or not. It= 's an open question. The answer would probably depend on the real preva= lence of attacks, which is currently unknowable and likely application spec= ific.

--047d7bd910c252204b050c38554f--