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 1V4SG1-0007qT-5y for bitcoin-development@lists.sourceforge.net; Wed, 31 Jul 2013 08:59:45 +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 1V4SFz-0000q3-CH for bitcoin-development@lists.sourceforge.net; Wed, 31 Jul 2013 08:59:45 +0000 Received: by mail-oa0-f45.google.com with SMTP id m1so953501oag.32 for ; Wed, 31 Jul 2013 01:59:37 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.43.226 with SMTP id z2mr67034590oel.76.1375261177807; Wed, 31 Jul 2013 01:59:37 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.23.36 with HTTP; Wed, 31 Jul 2013 01:59:37 -0700 (PDT) In-Reply-To: References: Date: Wed, 31 Jul 2013 10:59:37 +0200 X-Google-Sender-Auth: 4FWgoEqyCP2HG9jzepAOlJA3_0A Message-ID: From: Mike Hearn To: Gavin Andresen Content-Type: multipart/alternative; boundary=001a11333dcefa0cb004e2caf1dd 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: 1V4SFz-0000q3-CH Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72 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: Wed, 31 Jul 2013 08:59:45 -0000 --001a11333dcefa0cb004e2caf1dd Content-Type: text/plain; charset=UTF-8 Woo, huzzah :-) Now the BIP draft is available and we know it all hangs together, I'm hoping to (re)start implementation work in bitcoinj in the next month or two. I'm currently trying to figure out which is more important, deterministic wallets or payment protocol, but I think right now the payment protocol would be easier to do and would benefit more from a second implementation. HD wallets have already been shown interoperable. Comments on BIP 70: "PaymentRequest messages larger than 50,000 bytes should be rejected by the merchant's server, to mitigate denial-of-service attacks." Do you mean "users wallet" here? You could note in the motivation section two more motivations: 1) That the protocol can be a foundation on which other features are built 2) That it is required to assist hardware wallets when there is a virus on the system Perhaps note in the BIP that the merchant should not assume the merchant_data field is trustworthy - malicious buyers could rewrite it as they see fit. Point out that a good way to use this is to serialize server state, signed by a merchant-only key, in the same way one might use an HTTP cookie. "PaymentDetails.payment_url must be secure against man-in-the-middle attacks that might alter Payment.refund_to (if using HTTP, it must be TLS-protected). This says "must", but what should a client do here if the payment URL is not HTTPS? I suggest weakening this to "should", as sometimes TLS is redundant (e.g. if you're sending to a Tor hidden service). The PaymentACK message contains a copy of Payment, but the BIP doesn't say what to do with it. I assume this means a client is free to ignore it and rely on TCP state to figure out the payment/ack connection instead? It may be worth noting that explicitly. In the certificates section, you could observe that "validation" means "verification that it correctly chains to a trusted root authority, where trusted roots may be obtained from the operating system. If there is no operating system, the Mozilla root store is recommended". All the rest LGTM. [edit ] On Wed, Jul 31, 2013 at 8:28 AM, Gavin Andresen wrote: > I've turned the preliminary payment protocol spec into three BIPs: > > https://en.bitcoin.it/wiki/BIP_0070 : Network protocol / messages > https://en.bitcoin.it/wiki/BIP_0071 : MIME types for the messages > https://en.bitcoin.it/wiki/BIP_0072 : bitcoin: URI extension > > I expect the wallet-side implementation to be pulled into Bitcoin-Qt Real > Soon: > https://github.com/bitcoin/bitcoin/pull/2539 > > There is also a reference implementation of server-side code for > generating payment requests in php and C++ : > https://github.com/gavinandresen/paymentrequest > > -- > -- > Gavin Andresen > > > > ------------------------------------------------------------------------------ > Get your SQL database under version control now! > Version control is standard for application code, but databases havent > caught up. So what steps can you take to put your SQL databases under > version control? Why should you start doing it? Read more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --001a11333dcefa0cb004e2caf1dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Woo, huzzah :-)

Now the BIP draft is av= ailable and we know it all hangs together, I'm hoping to (re)start impl= ementation work in bitcoinj in the next month or two. I'm currently try= ing to figure out which is more important, deterministic wallets or payment= protocol, but I think right now the payment protocol would be easier to do= and would benefit more from a second implementation. HD wallets have alrea= dy been shown interoperable.

Comments on BIP 70:

=C2=A0 =C2= =A0"PaymentRequest messages larger t= han 50,000 bytes should be rejected by the merchant's server, to mitiga= te denial-of-service attacks."

Do you mean "users wallet" here?
=

You could note in the motivation section two more motiv= ations:

1) That the protocol can be a foundation on which other= features are built
2) T= hat it is required to assist hardware wallets when there is a virus on the = system

Perhaps note in the BIP that the merchant should not as= sume the merchant_data field is trustworthy - malicious buyers could rewrit= e it as they see fit. Point out that a good way to use this is to serialize= server state, signed by a merchant-only key, in the same way one might use= an HTTP cookie.

=C2=A0 =C2=A0"PaymentDetails.payment_url must be secure against man-in-th= e-middle attacks that might alter Payment.refund_to (if using HTTP, it must= be TLS-protected).

This says "must", but what should a cl= ient do here if the payment URL is not HTTPS? I suggest weakening this to &= quot;should", as sometimes TLS is redundant (e.g. if you're sendin= g to a Tor hidden service).

The PaymentACK message cont= ains a copy of Payment, but the BIP doesn't say what to do with it. I a= ssume this means a client is free to ignore it and rely on TCP state to fig= ure out the payment/ack connection instead? It may be worth noting that exp= licitly.

In the certificates section= , you could observe that "validation" means "verification th= at it correctly chains to a trusted root authority, where trusted roots may= be obtained from the operating system. If there is no operating system, th= e Mozilla root store is recommended".

All the rest LGTM.

[edit]



On Wed,= Jul 31, 2013 at 8:28 AM, Gavin Andresen <gavinandresen@gmail.com> wrote:
I've turned the preliminary payment prot= ocol spec into three BIPs:
http= s://en.bitcoin.it/wiki/BIP_0071 : MIME types for the messages
http= s://en.bitcoin.it/wiki/BIP_0072 : bitcoin: URI extension

=
I expect the wallet-side implementation to be pulled into Bitcoi= n-Qt Real Soon:

There is also a reference implementation of server-side cod= e for generating payment requests in php and C++ :
=C2=A0=C2=A0https://github.com/gavinandresen/paymentrequest

--=C2=A0
--
Gavin Andresen


-----------------------------------------------------------------------= -------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gam= pad/clk?id=3D49501711&iu=3D/4140/ostg.clktrk
___________________= ____________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--001a11333dcefa0cb004e2caf1dd--