From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: <20140509150325.GA30436@savin> <20140509152715.GA12421@savin> Date: Fri, 9 May 2014 17:34:07 +0200 X-Google-Sender-Auth: RzCSUwHNohAmVYrFqs5D0PMXhNI Message-ID: From: Mike Hearn To: Peter Todd 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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 light= weight client identify such transactions without any markers?
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.
--001a113335ca0b5e2d04f8f954eb--