Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1WimoP-0003Xc-Qb
	for bitcoin-development@lists.sourceforge.net;
	Fri, 09 May 2014 15:34:13 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.181 as permitted sender)
	client-ip=209.85.214.181; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f181.google.com; 
Received: from mail-ob0-f181.google.com ([209.85.214.181])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WimoO-0006GQ-RU
	for bitcoin-development@lists.sourceforge.net;
	Fri, 09 May 2014 15:34:13 +0000
Received: by mail-ob0-f181.google.com with SMTP id wm4so5043705obc.12
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 09 May 2014 08:34:07 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.44.204 with SMTP id g12mr14852949oem.38.1399649647416;
	Fri, 09 May 2014 08:34:07 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.162 with HTTP; Fri, 9 May 2014 08:34:07 -0700 (PDT)
In-Reply-To: <20140509152715.GA12421@savin>
References: <CANEZrP3VNXSc2cd3b9pz9iC2BR0-vG=tfYwMyUGBGaWPq+geXQ@mail.gmail.com>
	<20140509150325.GA30436@savin>
	<CANEZrP1m=-GWD5rLRe9vrx0JYKeKXghNw-a47ZbJTd1h3ngFww@mail.gmail.com>
	<20140509152715.GA12421@savin>
Date: Fri, 9 May 2014 17:34:07 +0200
X-Google-Sender-Auth: RzCSUwHNohAmVYrFqs5D0PMXhNI
Message-ID: <CANEZrP0Yom_JjN2PnPsfKV5S4wZSze4XTcJJU2ZWee4VGo20tw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a113335ca0b5e2d04f8f954eb
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: 1WimoO-0006GQ-RU
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] ECDH in the payment protocol
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: Fri, 09 May 2014 15:34:14 -0000

--001a113335ca0b5e2d04f8f954eb
Content-Type: text/plain; charset=UTF-8

>
> Ah, you're still misunderstanding my point: You can get atomicity in the
> worst-case where the communications medium fails *and* stealth payments
> that use up no extra space in the blockchain. This gives you the best of
> both worlds.


Sounds great! How does a lightweight client identify such transactions
without any markers?

Regardless, there are lots of other useful features that require BIP70 to
work well person to person, like messages, refund addresses, etc. So
extending it with ECDH makes sense in the end anyway no matter what.

--001a113335ca0b5e2d04f8f954eb
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"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5"><span st=
yle=3D"color:rgb(34,34,34)">Ah, you&#39;re still misunderstanding my point:=
 You can get atomicity in the</span><br>
</div></div>
worst-case where the communications medium fails *and* stealth payments<br>
that use up no extra space in the blockchain. This gives you the best of<br=
>
both worlds.</blockquote><div><br></div><div>Sounds great! How does a light=
weight client identify such transactions without any markers?</div><div><br=
></div><div>Regardless, there are lots of other useful features that requir=
e BIP70 to work well person to person, like messages, refund addresses, etc=
. So extending it with ECDH makes sense in the end anyway no matter what.</=
div>
</div></div></div>

--001a113335ca0b5e2d04f8f954eb--