Re: [Bitcoin-development] Cold Signing Payment Requests

2013-05-06 Thread Peter Todd
On Tue, Apr 30, 2013 at 10:17:23AM -0700, Jeremy Spilman wrote: [Aside] I was reading Peter's fidelitybond writeup for his idea on contract value accounting, and he points to Stephan's post from last September on payer-encoded metadata (

Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-30 Thread Mike Hearn
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. It's a real threat, albeit an exotic one. The threat model is a malware compromised host, with a wallet

Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-30 Thread Jouke Hofman
We do automatic refunds. When bitcoins arrive after an offer has expired (which happens quite often with webwallets that don't broadcast transactions immediately), we return all the bitcoins to a specified bitcoin-address. This happens a couple of times per day and can amount to a couple of

Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-30 Thread Gavin Andresen
RE: Timo's proposal for protecting the refund address: Seems to me there are two risks: 1) The risk that the merchant's web server will be compromised and the attacker will redirect refunds 2) The risk that the merchant will miss payments because they miss a POST to the payment_url (maybe the

Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-30 Thread Jeremy Spilman
1) The risk that the merchant's web server will be compromised and the attacker will redirect refunds 2) The risk that the merchant will miss payments because they miss a POST to the payment_url (maybe the customer's machine crashes during the HTTPS handshake) If payments are a lot more common

Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-29 Thread Jeremy Spilman
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

Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-25 Thread Mike Hearn
(for background: I did a lot of the design work with Gavin on the payment protocol and suggested/prototyped using x.509 in the way we do). So, I'm not a fan of weird hacks involving non-existent domain names. There's a clean way to implement this and we decided to punt on it for v1 in order to

Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-25 Thread Timo Hanke
So, I'm not a fan of weird hacks involving non-existent domain names. There's a clean way to implement this and we decided to punt on it for v1 in order to get something shippable, but if you're volunteering ... :) then indeed having a custom cert type that chains onto the end is the way to

Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-25 Thread Mike Hearn
Chaining a custom cert onto the end doesn't work, at least not if your end is the SSL cert. Chaining it to the SSL cert defeats the OP's intention of cold signing, as the SSL private key is usually kept online, therefore can't be used to sign a pubkey that is supposed to stay offline. What

Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-25 Thread Timo Hanke
On Thu, Apr 25, 2013 at 12:05:06PM +0200, Mike Hearn wrote: Chaining a custom cert onto the end doesn't work, at least not if your end is the SSL cert. Chaining it to the SSL cert defeats the OP's intention of cold signing, as the SSL private key is usually kept online,

Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-25 Thread Mike Hearn
That's a pointless goal to try and solve right now, because the SSL PKI cannot handle compromised web servers and so neither can we (with v1 of the payments spec). I don't think the OP intended to solve it right now, i.e. in v1. He differentiated between most trusted and less trusted

Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-25 Thread Mike Hearn
On Thu, Apr 25, 2013 at 4:13 PM, Mike Caldwell mcaldw...@swipeclock.comwrote: I am not sure if my replies hit the list. If not, can anyone who sees this help? In the past, I have pre signed (with PGP) large batches of Bitcoin addresses for distribution on my server. This way, even in the

Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-25 Thread Jeremy Spilman
There are definitely ways to keep the pay-to address secure even if the web server is compromised, just perhaps not perfectly clean standard X.509 ways under the current ecosystem which would be easier for everyone to agree on. - If a more trusted cert is an EV end cert, and a less trusted is a

Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-25 Thread Gavin Andresen
On Thu, Apr 25, 2013 at 3:12 PM, Jeremy Spilman jeremy.spil...@gmail.comwrote: Right now I'm leaning towards writing a prototype using a single cert with a fingerprint of PubKey in the Subject Alternate Name, and getting PubKey and InvoiceID in the Payment Request. Gavin, would the best way

Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-24 Thread Alan Reiner
There's some good discussion about that here: https://bitcointalk.org/index.php?topic=130749.msg1398972#msg1398972 thanke came up with this first, and then I reinvented it, and now you have. But the thread has some good discussion about how to move forward. I'm a big fan of putting the