Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Tlk9l-0001DF-IY for bitcoin-development@lists.sourceforge.net; Thu, 20 Dec 2012 17:43:41 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.43 as permitted sender) client-ip=209.85.219.43; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f43.google.com; Received: from mail-oa0-f43.google.com ([209.85.219.43]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Tlk9k-0007Uw-HG for bitcoin-development@lists.sourceforge.net; Thu, 20 Dec 2012 17:43:41 +0000 Received: by mail-oa0-f43.google.com with SMTP id k1so3661462oag.2 for ; Thu, 20 Dec 2012 09:43:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.172.164 with SMTP id bd4mr8622519oec.51.1356025415142; Thu, 20 Dec 2012 09:43:35 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.128.139 with HTTP; Thu, 20 Dec 2012 09:43:34 -0800 (PST) In-Reply-To: References: <20121128233619.GA6368@giles.gnomon.org.uk> <20121129170713.GD6368@giles.gnomon.org.uk> <20121129185330.GE6368@giles.gnomon.org.uk> Date: Thu, 20 Dec 2012 18:43:34 +0100 X-Google-Sender-Auth: eDiEeB1tqUujt3NflFhJW7nbs4M Message-ID: From: Mike Hearn To: Stephen Pair Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.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 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: 1Tlk9k-0007Uw-HG Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts 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, 20 Dec 2012 17:43:41 -0000 Thanks for the thoughts. For those who don't know, Stephen works for BitPay. > My first observation is that the proposal is too heavily oriented around a > merchant/customer interaction. The term "merchant" is just being used to mean the entity requesting the payment. I'm hopeful that in future mobile wallets will be creating these messages where today they'd make URLs and QRcodes. So it's definitely intended for person to person payments too. > you may find yourself in a situation needing to parse a protobuf > message in a web browser Nothing stops you converting them into whatever form you want on the server side. If you don't care about the signature checking then it's no problem to use a server. If you do then you'd need to ship all the code for verifying signatures that to the client anyway, at which point a small protobuf parser is hardly a deal killer. > ...like what about the casual user that wants to create a payment request to > send to their friend over email They can send an unsigned payment request. Note that if you mail it as an attachment from a competent, up to date email provider then the attachment isn't really unsigned. The whole thing is covered by the emails DKIM signature which is applied transparently by the ESP. If the signature fails to verify then the mail client can show that or treat the mail differently (as Gmail does). This is easy to use for the end user - they don't have to think about cryptography or PKI. As long as their email account is secure then they can send signed mails asserting to their identity. > Refund addresses...this is not going to be as useful as people might > think...most refunds that bitpay needs to process happen days or even months > after the initial purchase Useful feedback, thanks. Still, there may be other types of merchants for whom it's useful, and many users won't change their wallet. It certainly simplifies things if you can present the refund address and give a one-click option to use it. If the user wants to use a different address, then they can go onto the slow/complicated path. This current spec deliberately punts on the topic of identifying end users. It's a difficult problem. Whereas many merchants have SSL certs, most end users don't have published keys in any useful form. By far the easiest way for 99% of people to generate a signed message is to send email that's signed by DKIM (from gmail, hotmail, yahoo, other providers etc). Then it's all transparent and behind the scenes. Their identity is their email address. So for BitPays scenario, you could require an email to be sent by the end user containing new instructions. Your MTA can show you whether the mail is correctly DKIM signed or not when deciding whether to follow the instructions. > But, if the recipient never cashes the check, the sender could pull those > funds back after a certain period of time. Yeah, I like the term "check"/"cheque" for that concept of a reversible payment. > I like the use of merchant_data...this means that you no longer will need a > unique bitcoin address for every invoice. It's still a good idea to use one for privacy reasons. The merchant data is there so you can stuff whatever state you want into it. So it's like cookies. You don't have to keep state on the server side. Just encrypt/sign it, put it in the invoice, and when you get a payment message back there's no need to do database lookups or anything, you can just do some crypto and know who is submitting it. > Generally speaking, I'm not a fan of embedding things like that What's wrong with it? Isn't your proposal more complex? I don't see why it's better than just embedding it. > The Receipt should be signed...it could be used as proof of payment by > wallets. There's no Receipt message, a SignedPaymentRequest + transactions that pay to the requested outputs are together the proof of payment. Re a new URI scheme. Interesting idea, thanks for the suggestion. It seemed like it'd be easier for merchants to integrate if a single linked worked for all wallet implementations/versions. But I guess we could do both schemes, even.