Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.45 as permitted sender)
	client-ip=209.85.219.45; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f45.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <52E9E787.8080304@borboggle.com>
References: <52E9E787.8080304@borboggle.com>
Date: Thu, 30 Jan 2014 11:49:32 +0100
Message-ID: <CANEZrP0soR0xRqW=vsKaL__HRuWstA5vW=6_JkGZm=8wkm8Q3g@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Chuck <chuck+bitcoindev@borboggle.com>
Content-Type: multipart/alternative; boundary=001a11c2e60a063d4a04f12dd09d
Cc: Bitcoin-Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70 message delivery reliability
Precedence: list

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

Hi Chuck,

Both Bitcoin Core and bitcoinj are about to ship with the protocol as-is,
so any changes from this point on have to be backwards compatible.

On Thu, Jan 30, 2014 at 6:47 AM, Chuck <chuck+bitcoindev@borboggle.com>wrote:

> I presume the receipt R=(PaymentRequest,[transactions]) would suffice.
>

That's all you need to prove payment, yes.


> In the well-behaved case, I presume the point is to help the
> merchant associate some arbitrary data with the purchase as well as
> provide a refunding address for the customer.


That's right (+memo). And to provide an additional hook for future
features, like recurring billing, ECDH key agreements etc.


> In Step 3, it's critical the customer sign the message with the private
> key of the refund address, so that the merchant can be confident the
> refund address is correct.
>

Refund addresses as specced currently are optional. For instance bitcoinj
currently doesn't use them and won't until HD wallets support is done.

Let's get some practical experience with what we've got so far. We can
evolve PaymentRequest/Payment/PaymentACK in the right direction with
backwards compatible upgrades, I am hoping.

--001a11c2e60a063d4a04f12dd09d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Chuck,<div><br></div><div>Both Bitcoin Core and bitcoin=
j are about to ship with the protocol as-is, so any changes from this point=
 on have to be backwards compatible.</div><div><br></div><div class=3D"gmai=
l_extra">
<div class=3D"gmail_quote">On Thu, Jan 30, 2014 at 6:47 AM, Chuck <span dir=
=3D"ltr">&lt;<a href=3D"mailto:chuck+bitcoindev@borboggle.com" target=3D"_b=
lank">chuck+bitcoindev@borboggle.com</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">
I presume the receipt R=3D(PaymentRequest,[transactions]) would suffice.<br=
></blockquote><div><br></div><div>That&#39;s all you need to prove payment,=
 yes.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In the well-behaved case, I presume the point is to help the<br>
merchant associate some arbitrary data with the purchase as well as<br>
provide a refunding address for the customer. </blockquote><div><br></div><=
div>That&#39;s right (+memo). And to provide an additional hook for future =
features, like recurring billing, ECDH key agreements etc.</div><div>=C2=A0=
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">In Step 3, it&#39;s critical the customer si=
gn the message with the private<br>
key of the refund address, so that the merchant can be confident the<br>
refund address is correct.<br></blockquote><div><br></div><div>Refund addre=
sses as specced currently are optional. For instance bitcoinj currently doe=
sn&#39;t use them and won&#39;t until HD wallets support is done.</div>
<div><br></div><div>Let&#39;s get some practical experience with what we=
9;ve got so far. We can evolve PaymentRequest/Payment/PaymentACK in the rig=
ht direction with backwards compatible upgrades, I am hoping.</div></div>
</div></div>

--001a11c2e60a063d4a04f12dd09d--