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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UWt07-0007W0-Mc for bitcoin-development@lists.sourceforge.net; Mon, 29 Apr 2013 18:40:35 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.128.172 as permitted sender) client-ip=209.85.128.172; envelope-from=jeremy.spilman@gmail.com; helo=mail-ve0-f172.google.com; Received: from mail-ve0-f172.google.com ([209.85.128.172]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UWt06-0006J9-UN for bitcoin-development@lists.sourceforge.net; Mon, 29 Apr 2013 18:40:35 +0000 Received: by mail-ve0-f172.google.com with SMTP id db10so3273815veb.31 for ; Mon, 29 Apr 2013 11:40:29 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.52.180.195 with SMTP id dq3mr29959206vdc.9.1367260829397; Mon, 29 Apr 2013 11:40:29 -0700 (PDT) Received: by 10.58.137.197 with HTTP; Mon, 29 Apr 2013 11:40:29 -0700 (PDT) In-Reply-To: <20130428180304.GA30115@crunch> References: <20130428180304.GA30115@crunch> Date: Mon, 29 Apr 2013 11:40:29 -0700 Message-ID: From: Jeremy Spilman To: timo.hanke@web.de, Bitcoin Dev Content-Type: multipart/alternative; boundary=bcaec51969f30d39ae04db843822 X-Spam-Score: -0.6 (/) 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 (jeremy.spilman[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1UWt06-0006J9-UN Subject: Re: [Bitcoin-development] Cold Signing Payment Requests 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: Mon, 29 Apr 2013 18:40:35 -0000 --bcaec51969f30d39ae04db843822 Content-Type: text/plain; charset=ISO-8859-1 It's neat to use the payment address as an implicit signature by hashing something and multiplying it into the payee's pubKey. One downside is that it complicates the merchant's wallet. In this case the payment is going to a pseudo-random address which the merchant will have to explicitly add to their wallet, complicating backups, etc. The other challenge is how to handle an error when you POST to the payment_url. In the original spec, the payer would only broadcast the transaction themselves if there wasn't a payment_url. In the current version it looks like the payer will broadcast the transaction(s) either way. I only saw some of the discussions around this, but I think part of the problem is what state do you put the payer's wallet into if you POST a Payment and don't get a PaymentAck? If the payer always broadcasts the transaction, then wallet state becomes obvious. With your proposal you would not want the payer to broadcast the transaction without a PaymentAck, since you need the merchant to acknowledge they know where to look for the payment. Backing up a step, I'm not sure what the threat model is for signing the refund address? The same process that's signing the transaction is doing an HTTPS POST with the refund address. If an attacker can defeat that, then they can just redirect the payment in the first place. The only benefit I can think of is the payer can prove what refund address they specified with the payment. Wouldn't it be easier to just get the merchant to sign the PaymentAck? Technically they already are signing it, but a TLS stream probably isn't the most convenient way to capture that. --bcaec51969f30d39ae04db843822 Content-Type: text/html; charset=ISO-8859-1
It's neat to use the payment address as an implicit signature by hashing something and multiplying it into the payee's pubKey.

One downside is that it complicates the merchant's wallet. In this case the payment is going to a pseudo-random address which the merchant will have to explicitly add to their wallet, complicating backups, etc.

The other challenge is how to handle an error when you POST to the payment_url. In the original spec, the payer would only broadcast the transaction themselves if there wasn't a payment_url. In the current version it looks like the payer will broadcast the transaction(s) either way. I only saw some of the discussions around this, but I think part of the problem is what state do you put the payer's wallet into if you POST a Payment and don't get a PaymentAck? If the payer always broadcasts the transaction, then wallet state becomes obvious. With your proposal you would not want the payer to broadcast the transaction without a PaymentAck, since you need the merchant to acknowledge they know where to look for the payment.

Backing up a step, I'm not sure what the threat model is for signing the refund address? The same process that's signing the transaction is doing an HTTPS POST with the refund address. If an attacker can defeat that, then they can just redirect the payment in the first place. The only benefit I can think of is the payer can prove what refund address they specified with the payment.

Wouldn't it be easier to just get the merchant to sign the PaymentAck? Technically they already are signing it, but a TLS stream probably isn't the most convenient way to capture that.
--bcaec51969f30d39ae04db843822--