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-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1We7h7-0000ma-RR for bitcoin-development@lists.sourceforge.net; Sat, 26 Apr 2014 18:51:25 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.171 as permitted sender) client-ip=209.85.214.171; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f171.google.com; Received: from mail-ob0-f171.google.com ([209.85.214.171]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1We7h7-0000zK-0x for bitcoin-development@lists.sourceforge.net; Sat, 26 Apr 2014 18:51:25 +0000 Received: by mail-ob0-f171.google.com with SMTP id uy5so5689033obc.30 for ; Sat, 26 Apr 2014 11:51:19 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.17.132 with SMTP id o4mr13353128oed.34.1398538279667; Sat, 26 Apr 2014 11:51:19 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.96.180 with HTTP; Sat, 26 Apr 2014 11:51:19 -0700 (PDT) In-Reply-To: <20140426183119.GB16440@savin> References: <20140426112312.GA17949@savin> <20140426183119.GB16440@savin> Date: Sat, 26 Apr 2014 20:51:19 +0200 X-Google-Sender-Auth: VakTioTxg7yDHTvHqXMAdEx_JDc Message-ID: From: Mike Hearn To: Peter Todd Content-Type: multipart/alternative; boundary=089e01294d0c5d4e2004f7f691ae 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: 1We7h7-0000zK-0x Cc: Bitcoin Development , Jeremy Spilman Subject: Re: [Bitcoin-development] Eliminating double-spends with two-party self-escrow for high value transactions 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: Sat, 26 Apr 2014 18:51:26 -0000 --089e01294d0c5d4e2004f7f691ae Content-Type: text/plain; charset=UTF-8 > > Note how the mechanism I'm proposing is basically just a Jeremy > Spilman-style micropayment channel(1) used for a single payment; I > should have made that clear in my original post. Right, that does make more sense. Yes, it's a good idea. The question is whether wallet UI's can support it without being overly complex. We'd be asking users to take extra steps to work around unintuitive limitations of the protocol. Products that do that too much tend to get left for something that "just works". But there may be a slick way to present it. --089e01294d0c5d4e2004f7f691ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Note how the mechanism I'm proposing is basi= cally just a Jeremy
Spilman-style micropayment channel(1) used for a single payment; I
should have made that clear in my original post.

Right, that does make more sense. Yes, it's a good idea. The ques= tion is whether wallet UI's can support it without being overly complex= . We'd be asking users to take extra steps to work around unintuitive l= imitations of the protocol. Products that do that too much tend to get left= for something that "just works". But there may be a slick way to= present it.=C2=A0
--089e01294d0c5d4e2004f7f691ae--