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
As part of a roadmap for block downloading, I think this may be a good time
to look into providing an HTTP/HTTPS protocol for block downloading - this
would also allow web proxies to cache blocks and thus make it more
accessible, as well as cater for resumeable downloads.
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
On Tue, Apr 30, 2013 at 12:14 PM, Rebroad (sourceforge)
rebroad+sourceforge@gmail.com wrote:
As part of a roadmap for block downloading, I think this may be a good time
to look into providing an HTTP/HTTPS protocol for block downloading - this
would also allow web proxies to cache blocks
On Tuesday 30 April 2013 19:04:59 Jeff Garzik wrote:
The format currently used by bitcoind would be just fine --
blocks/blk.dat for raw data, size-limited well below 1GB. Just
need to add a small metadata download, and serve the raw block files.
That doesn't seem very generic. It's tied
Sounds like this part of Bitcoin (block sharing) would definitely benefit from
having a REST (HTTP) API.
REST-based web APIs are a common feature of most online services these days.
Makes writing other client services so much easier. Plus you get the benefit
of the HTTP ecosystem for free
On Tue, Apr 30, 2013 at 3:27 PM, Andy Parkins andypark...@gmail.com wrote:
On Tuesday 30 April 2013 19:04:59 Jeff Garzik wrote:
The format currently used by bitcoind would be just fine --
blocks/blk.dat for raw data, size-limited well below 1GB. Just
need to add a small metadata
And then the problem of what domain name to use - ideally a single name
would be used so caches had the maximum chance to reuse content. To
keep the network distributed perhaps the existing DNS seed mechanism
could be used - a few names, each serving a random bitcoind's address.
Put :8333
10 matches
Mail list logo
