From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W8pBm-000165-SC for bitcoin-development@lists.sourceforge.net; Thu, 30 Jan 2014 10:49:42 +0000 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; Received: from mail-oa0-f45.google.com ([209.85.219.45]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1W8pBk-0002S4-W4 for bitcoin-development@lists.sourceforge.net; Thu, 30 Jan 2014 10:49:42 +0000 Received: by mail-oa0-f45.google.com with SMTP id i11so3410061oag.4 for ; Thu, 30 Jan 2014 02:49:32 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.213.166 with SMTP id nt6mr800236obc.53.1391078972732; Thu, 30 Jan 2014 02:49:32 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.99.112 with HTTP; Thu, 30 Jan 2014 02:49:32 -0800 (PST) In-Reply-To: <52E9E787.8080304@borboggle.com> References: <52E9E787.8080304@borboggle.com> Date: Thu, 30 Jan 2014 11:49:32 +0100 X-Google-Sender-Auth: 5jES72YOIQS62TVHMmXcsLBT8F4 Message-ID: From: Mike Hearn To: Chuck Content-Type: multipart/alternative; boundary=001a11c2e60a063d4a04f12dd09d 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: 1W8pBk-0002S4-W4 Cc: Bitcoin-Dev Subject: Re: [Bitcoin-development] BIP70 message delivery reliability 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: Thu, 30 Jan 2014 10:49:43 -0000 --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 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
Hi Chuck,

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.

On Thu, Jan 30, 2014 at 6:47 AM, Chuck <chuck+bitcoindev@borboggle.com> wrote:
I presume the receipt R=3D(PaymentRequest,[transactions]) would suffice.

That's all you need to prove payment,= yes.
=C2=A0
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.

<= div>That's right (+memo). And to provide an additional hook for future = features, like recurring billing, ECDH key agreements etc.
=C2=A0=
In Step 3, it's critical the customer si= gn the message with the private
key of the refund address, so that the merchant can be confident the
refund address is correct.

Refund addre= sses as specced currently are optional. For instance bitcoinj currently doe= sn't use them and won't until HD wallets support is done.

Let'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.
--001a11c2e60a063d4a04f12dd09d--