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 (
> https://bitcointalk.org/index.php?topic=108423.msg117
> 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 commo
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 cus
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 hundred
> 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
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
On Thu, Apr 25, 2013 at 09:07:07PM -0400, Gavin Andresen wrote:
> On Thu, Apr 25, 2013 at 3:12 PM, Jeremy Spilman
> wrote:
>
> > 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 Invoice
On Thu, Apr 25, 2013 at 3:12 PM, Jeremy Spilman wrote:
> 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 to work on
> this be to
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 D
On Thu, Apr 25, 2013 at 4:13 PM, Mike Caldwell wrote:
> 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 event of
> compromise,
On Thu, Apr 25, 2013 at 12:45:33PM +0200, Mike Hearn wrote:
> > 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
>
> So I don't see how you can have a payment request signing key that's safer
> than an SSL key. As Jeremy notes, CAs will not issue you intermediate
> certificates. Perhaps if one existed that would do the necessary things for
> a reasonable price you could indeed give yourself an offline interme
>
> > 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 "
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,
> 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.
> 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
(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 get
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 lower-ca
Payment Protocol uses x509 certs to sign a Payment Request. This
allows wallets to display meta-data from the cert to the payer instead
of the address, which should make it easier to verify where money is
being sent, and make it harder for an attacker to change the address
displayed to a user so th
19 matches
Mail list logo
