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 (
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
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: 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
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
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
(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
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
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
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,
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
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
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
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
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
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
16 matches
Mail list logo
