Re: [Bitcoin-development] Cold Signing Payment Requests
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 (possibly a low power hardware wallet like a Trezor) that can understand the payment protocol and sign transactions, but maybe not do a whole lot more than that. For instance, probably it cannot do HTTPS connections itself. So a virus on the host could swap the refund address for one that is owned by the attacker, and then try to make the merchant issue an automatic refund, thus bouncing the funds back off the merchant to the them. If there are merchants that offer large, automatic refunds, it could be an issue. I'm not sure how common that might be in reality. Steven or Tony would know. Timo's protocol is an interesting solution, but again, at this point the feature set for v1 is pretty much locked down. -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Cold Signing Payment Requests
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 bitcoins per offer. On 04/30/2013 11:17 AM, Mike Hearn wrote: If there are merchants that offer large, automatic refunds, it could be an issue. I'm not sure how common that might be in reality. Steven or Tony would know. Timo's protocol is an interesting solution, but again, at this point the feature set for v1 is pretty much locked down. -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Cold Signing Payment Requests
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 customer's machine crashes during the HTTPS handshake) If payments are a lot more common than refunds, then (2) will outweigh (1). I also think an attacker who compromises the front-end web server would probably just have it start generating plain-old pay-to-bitcoin-address payment requests, and hope that lots of customers pay them directly before the attack is discovered. -- -- Gavin Andresen -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Fwd: Service bits for pruned nodes
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. -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Cold Signing Payment Requests
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 than refunds, then (2) will outweigh (1). I think that's oversimplifying. (1) is theft, (2) is payment processing. Reliable payment processing with refund handling is not simple nor free, but it should be secure. The cost of (2) depends primarily on the failure rate, which we can only guess at this point, and secondarily on how much manual intervention is required to recover. (2) is perhaps more of a problem if wallets broadcast before POST. It's trading one failure mode (funds sent but not claimed) for another (coins marked as spent but not). Either way, you fix it by just retrying the POST. But only with Transmit-After-ACK can the payer's wallet detect the failure automatically, and even recover automatically (simply unlock the outputs, or to be sure, spend them back to self). Since merchants get to choose whether to have a POST url, they get to decide if the cost of keeping their server up is worth it. I think eventually there are enough benefits to Transmit-After-ACK that it will become a supported use case. Thanks Mike for explaining the threat. [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.msg1178438#msg1178438) which Timo applies here. As a relative newcomer, this is what I am loving most about Bitcoin. -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Service bits for pruned nodes
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 and thus make it more accessible, as well as cater for resumeable downloads. Speaking generally, I've always been a supporter of finding new and creative ways to store and transmit blocks. The more diversity, the less likely bitcoin can be shut down worldwide. HTTP is fine, but you run into many issues with large files. You would need a very well defined HTTP-retrievable layout, with proper HTTP headers along the entire path, if you want web caches to function properly. You need HTTP byte range support, HTTP 1.1 keep-alives, and other features for resuming large, interrupted downloads. 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. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Service bits for pruned nodes
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 far too much to the current storage format of bitcoind. Wouldn't it be better to add support for more bitcoin-protocol-oriented HTTP requests? Then any client can supply the same interface, rather than being forced to create blk.dat on the fly? http://bitcoind.example.com/block/BBB http://bitcoind.example.com/tx/ http://bitcoind.example.com/block/oftx/TTT http://bitcoind.example.com/peers http://bitcoind.example.com/peer/nnn Essentially: block explorer's raw mode but in every bitcoind. The hardest operation for light clients is finding out the block that contains a particular transaction -- something that bitcoind already knows. I'd like to see support for HTTP POST/PUT of signed transactions and block announcements too. Andy -- Dr Andy Parkins andypark...@gmail.com -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Service bits for pruned nodes
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 (HTTP caches, etc). - Brenton Camac On Apr 30, 2013, at 1:04 PM, Jeff Garzik jgar...@exmulti.com wrote: 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 and thus make it more accessible, as well as cater for resumeable downloads. Speaking generally, I've always been a supporter of finding new and creative ways to store and transmit blocks. The more diversity, the less likely bitcoin can be shut down worldwide. HTTP is fine, but you run into many issues with large files. You would need a very well defined HTTP-retrievable layout, with proper HTTP headers along the entire path, if you want web caches to function properly. You need HTTP byte range support, HTTP 1.1 keep-alives, and other features for resuming large, interrupted downloads. 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. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Service bits for pruned nodes
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 download, and serve the raw block files. That doesn't seem very generic. It's tied far too much to the current storage format of bitcoind. Hardly. The storage format is bitcoin protocol wire format, plus a tiny header. It is supported in multiple applications already, and is the most efficient storage format for bitcoin protocol blocks. Wouldn't it be better to add support for more bitcoin-protocol-oriented HTTP requests? Then any client can supply the same interface, rather than being forced to create blk.dat on the fly? You don't have to create anything on the fly, if you store blocks in their native P2P wire protocol format. http://bitcoind.example.com/block/BBB http://bitcoind.example.com/tx/ http://bitcoind.example.com/block/oftx/TTT http://bitcoind.example.com/peers http://bitcoind.example.com/peer/nnn Essentially: block explorer's raw mode but in every bitcoind. The hardest operation for light clients is finding out the block that contains a particular transaction -- something that bitcoind already knows. This is a whole new client interface. It's fun to dream this up, but it is far outside the scope of an efficient HTTP protocol that downloads blocks. Your proposal is closer to a full P2P rewrite over HTTP (or a proxy thereof). -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Service bits for pruned nodes
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 after the name, and enhance bitcoind to respond to HTTP and p2p caching would be used! Simon On Tue 30 Apr 2013 12:27:10 PM PDT, Andy Parkins 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 download, and serve the raw block files. That doesn't seem very generic. It's tied far too much to the current storage format of bitcoind. Wouldn't it be better to add support for more bitcoin-protocol-oriented HTTP requests? Then any client can supply the same interface, rather than being forced to create blk.dat on the fly? http://bitcoind.example.com/block/BBB http://bitcoind.example.com/tx/ http://bitcoind.example.com/block/oftx/TTT http://bitcoind.example.com/peers http://bitcoind.example.com/peer/nnn Essentially: block explorer's raw mode but in every bitcoind. The hardest operation for light clients is finding out the block that contains a particular transaction -- something that bitcoind already knows. I'd like to see support for HTTP POST/PUT of signed transactions and block announcements too. Andy -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
