Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/18/13 8:09 PM, John Dillon wrote: On the other hand, a tx with some txin proofs can be safely relayed by SPV nodes, an interesting concept. Do the UTXO commitment people have keeping proof size small in mind? More than a kilobyte, probably less than a few tens of kilobytes. It depends on parameters (branching factor, script vs hash(script)) that are tweakable with time/space and long-term/short-term tradeoffs. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSEakMAAoJEAdzVfsmodw4B9wQAIu82nxMAyMiTpFcWW6v0fQ9 26bzOznyIhzAlFUeCXvgwtqoxjRcheLOnsFsAr0TLdLYrx00o4+MS0GepV40gEpd Ds/itvAnW8aWdCls0qy1hljWrsp8R3IfXWchXy13kjOhTIx8JaALeHEzOCsJVxCf nWrV7UNLRO1eXhLUnFLnZ3/HdljMZnLqLexSGXorn4I2zwg5HGNMJxIenU3vDj8s 68k4rSk/eUptG97ZmJxCysn7nt5F1cxRutsVOPxsC/4+FptMYf9YJRJDNpvttYyl ztI2xV+ARfEvSZs0lqGAcpvKwVV4IvZDGXhUCiS6LQ99tvMid4kjIGYPwlyK6SJW LoYVbvjbauEIPn4URW8XilMB5EEJisr5/7ZV/aDLEFcBA/is5ePuQioo/81yOWUw k5PghJ/TBMBQhxOGCz86onCI1YwrWfhu2sz6xNIHm9lbyZQcw3N/ai77FQqxxkxp iBbIAvhk4sQ7lPt4QHmiL4isPzaiScKVTjvzfc5hAHSmu6xQysf8VA/SwUSgAJZB iUPYRz5URaw8a/WDlo7YA6BRV/l7RloEcWGs6br3jVYxtJSaxqDwwrUV3SdDtzBR uiE1OVPp8ihY3OJbnZkbvy3lXXlLjwrLVwMUgprhUo793QtktZH+O0V+StcGKLGD 4rdK6Z3C8Wx9FY2fvkBy =HZdx -END PGP SIGNATURE- -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
On Mon, Aug 19, 2013 at 5:09 AM, John Dillon john.dillon...@googlemail.comwrote: Here's another question for you Mike: So does bitcoinj have any protections against peers flooding you with useless garbage? It'd be easy to rack up a user's data bill for instance by just creating junk unconfirmed transactions matching the bloom filter. Unconfirmed transactions that are received show up as unspendable and in most wallets they have a little graphic that changes as more peers announce the tx. So if a peer sent non-existent transactions then they'd allow show up as seen by only one peer, which would look different to how normal broadcast transactions show up. Whether users really notice this graphic or understand what it means is debatable, of course, but all Bitcoin wallets have that problem. I've yet to see any that would successfully communicate the notion of confidence to new, untrained users. That's why the default is to not let you spend unconfirmed transactions, unless they were created by yourself (you're allowed to spend change). bitcoinj does not attempt to handle DoS attacks by malicious remote peers today, because such an attack has never been observed, has no obvious profit motive and as you don't get to choose which nodes the wallets connect to it'd be difficult to pull off. Unless you control the users internet connection of course, but that's a well known caveat which is documented on the website. -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Aug 16, 2013 at 2:15 PM, Peter Todd p...@petertodd.org wrote: On Fri, Aug 16, 2013 at 10:01:16AM -0400, Peter Todd wrote: Doing this also makes it more difficult to sybil the network - for instance right now you can create SPV honeypots that allow incoming connections only from SPV nodes, thus attracting a disproportionate % of the total SPV population given a relatively small number of nodes. You can then use that to harm SPV nodes by, for instance, making a % of transactions be dropped deterministicly, either by the bloom matching code, or when sent. Users unlucky enough to be surrounded by sybil nodes will have their transactions mysteriously fail to arrive in their wallets, or have their transactions mysteriously never confirm. Given how few full nodes there are, it probably won't take very many honeypots to pull off this attack, especially if you combine it with a simultaneous max connections or bloom io attack to degrade the capacity of honest nodes. Oh, here's an even better way to do the tx drop attack: when you drop a transaction, make a fake one that pays the same scriptPubKeys with the same amount, and send it to the SPV peer instead. They'll see the transaction go through and show up in their wallet, but it'll look like it got stuck and never confirmed. They'll soon wind up with a wallet full of useless transactions, effectively locking them out of their money. Excellent, and makes a mockery of zero-confirmation transactions to boot. Can be prevented by passing along txin proofs, but they require the full transaction, so the effective UTXO set size would go up greatly post-pruning. I am sure Mike would love to demand that full nodes do this for their peers though, at least until UTXO commitments are greated, at great cost to full nodes. On the other hand, a tx with some txin proofs can be safely relayed by SPV nodes, an interesting concept. Do the UTXO commitment people have keeping proof size small in mind? Here's another question for you Mike: So does bitcoinj have any protections against peers flooding you with useless garbage? It'd be easy to rack up a user's data bill for instance by just creating junk unconfirmed transactions matching the bloom filter. That is good too. I'll bounty 2.5BTC to implement the first attack, and 0.5BTC for the second. Should be easy to do as a patch to satoshi bitcoin I think. The implementation must include a RFC3514 compliant service bit to let peers know of the operators intentions. Along those lines I'll donate 3BTC to adding service bit selection to DNS seeds. We should clearly show people the limitations of SPV before they depend too much on it. Nothing wakes users up like a 21 million BTC transaction in their wallet. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJSEYvxAAoJEEWCsU4mNhiPxI8IAJaWJ9s0YG3Ex5h8Dr6oPJ9M uXTXa/Rt0DqS6mmyD9O80sXfgPbPbQa2rDL6imlqONaWfpXFZl2W9vxRGaZJ9wrr 3KBHzK8lasDOKqlEX92h8ZmQBjw4w5bK/heRLo1PnSZ8ojKn8+My1JvZWOPzF0Ct tDXXuCE94csKuGRdmdDdVoXqy4XZaMQhHrGbrWVotQs1HzX3iK146GoGaZC0YyBx cdWg/xDPtAxgb5zf2RSeNHfXeY0wZawe8vBxaS56gCRl54PG7fJvqL+YPcarNb1p zEmahJjoyQHskjFeDpgEiXnWu3K3JGTSA5GvekWvBbJCcV4o1E6EI6LG0f1SfIs= =12DC -END PGP SIGNATURE- -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
-BEGIN PGP MESSAGE- Version: GnuPG v1.4.11 (GNU/Linux) hQEMA8xUMVQPvvGFAQf9HL/SN/TZNQuVAjz5ggDzVzpYEzLRkFlgTR2lPURaR28F G0SgcvJmt1cvucxZRxzSUDCx58Ub16dzx9IBKQ+GDDUXbHGqExfbeIFx96okNsSm GmRRyORm+L7rdpQ3G8HcfKr1R9YufgaAjsa05eXlXl+fgpYrSBgitY6T3IZ9c0Z7 eF6yjogj5iaDUP2m7xLmRyaQvT/0GdRYk+c2JOH0HGGQ2WWylPMiczJmKmV4jrDd 6asoesEk5kH0IWM2xiY2re+/WkRVeNUlVT7R4+uIzQm/iMzKpIWNiF5a87x3+E9+ +KgJg1a4elKZ6UO4Bvov+Gw65u7q3eunVUYHUKfaLIUBDAO4Pc5vOCVNqAEIAJyT qFTqTbV9XE+REN/1KVmRLgidcRcxnSFFnkUVUozdMev8oGqoW3iAs8rVr5DuSO/a FW0UOdI9vBLC51+pdbBNoR9c1saheRbnTks67kLziQmuBFkly6cbLYUyh859pA3K yjRaRLa1Q6IX76NZTdEc3F7XnfmMBwEFS2t9vSAqhFptAXlhnmKov+g7iJ8oaAWQ 361OcXvxPk6wmWKFroZIo1is0a3izoAcLFB9NWv7BU9I06XB3Gw5gVnzXQexTlV+ KHd8zeJYfc1IaPLdxefhp8tfrJIjAOXq9FmKjgB5Qki8cgCWM1pJIJK0t4XTVxI6 8LU1aldq5Qlond0aIBfS6QFErTFtVYmFLjl8YETcphBZAOSb6Rgudrz9mAL1brOu fjg9aVTSTjWjFHflRFSpNKVjj+5zS93NMEEaNQmWjeexScw175DVKJoU6lnVFgfk I7d+Lf5axVwlawZ+euN9YURE1azWUR4OECfDvd6Na8MGs+OwedbWP5/OfDGg2rzN OG/SK5AxlrshrOmrY7emlMOhYIhd8A+KQ0ghLocTv8JVDvaIEnWkWEq4idhzOv4m 9xFmde45SOxy/PuReDEgGAS3S1IOMMzdkEH8yuzYf2cFzQ0d4PmHNn6NGDo9bEIV Bjw9pqg5rg+8un14T3+c9ZbfkEvLB+sEQ9uVidg9jE1ZSH/l9XG0stbSnnDmAkYy DbbA7WDsJ0fxQD1zvnDUlq84I2Fr5RwecOWuCUUUHGXdfe0AnxGL1k96Jd0t3BXj JbY5fBUbN1QTuwqUSUBhE8uE7gGVZyWHel+DtKxwpIkpQ/CPLxFWJQL8oswN4Re+ CgS1Fs/P2MJdb0ht8cTTdFUEIKYW41eG84Vgpyn7gwd/IE1gPdpsDtoAV8uwIXsJ WBHtYgO/cH3ofyITOcsm7gfkI3V4T87I3Sjrnk0ipa6fWh8dwhZnG1s5b7lKVgAp QOqgWdjoP+4/FWCCpo9EVWqRfRU7js/TfuKOBiLDpKEkdmmuCOiMlxe5vt5FUHbq wT0V5Iian5GcqZvJ/CZWzAxMY+qXu/OziI9Emvz5AA/yWymcHJl2M8RY+L+fVB67 /JSsHl0xQLHehKIFZKuTacy87pRHCoq7vA72lm+XCqC7+RojzPwODia7ShCfrZe2 YctdU/VWVMMgkpLcGxRMRFc2Rxbbge3kEQCt+b7lL7HVq0vsBoF4g3X4kzLxxyeD JiR8PHknlWOjy5KgseKzTCt3sygvyJZrEPQ5SiBtoAkLgmEzkOxiy1DHrj59soM9 QY7L3XTLLOya4daL5+iZjZXm28JNXAYycAu3fyXx7rnbL6m/gcGjJZiuwwajMvmF WvjbJBm9f5qOxK87ShnPj2ZwQ1w1nnz7i5oOdtELwUb96uMFegNDRSfMNpN4pmTh 2Qpffp9QZMEOxE+a7SnNjq5xG4S3qTnhdhTzQL5sIC+yJZ7L2gdbbrjdud2gcKRc yQIkst51OIV6/xJ65AD6qzIcifpLm+u5/t6eVGLvw0G8u3gFHgelM1kPfX8iYDOR CTDnJxx30/GXEvqD4/nCm5JytgolzH/PilBME1w2dPf845HebA0XCAhSoqdoLCvF 7jrllVCh/PDlK40XbO/cDYgXF7deDbgXVF2OBGc6qqAho3VE83ebR1wQWlUOyPIo ScQyePNu500Yy/GUnwBK7029N4r6R1RBDn/rTsD/2w== =6OvE -END PGP MESSAGE- -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
On Sat, Aug 17, 2013 at 8:35 AM, Mike Hearn m...@plan99.net wrote: There shouldn't be a smaller subset of Bloom filtering nodes because the idea of making it optional is a stupid one. If you're worried about DoS, come up with real fixes instead of trying to break features that work. It is not just abstract worry. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
Cool. Maybe it's time for another development update on the foundation blog? On Fri, Aug 16, 2013 at 3:00 AM, Gavin Andresen gavinandre...@gmail.comwrote: Mike asked what non-0.9 code I'm working on; the three things on the top of my list are: 1) Smarter fee handling on the client side, instead of hard-coded fees. I was busy today generating scatter-plots and histograms of transaction fees versus priorities to get some insight into what miner policies look like right now. 2) First double-spend relaying and alerting, to better support low-value in-person transactions. Related: *Have *a *Snack*, Pay with *Bitcoins*http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf 3) Work on 2-3 whitepapers on why we need to increase or remove the 1MB block size limit, how we can do it safely, and go through all of the arguments that have been made against it and explain why they're wrong. -- -- Gavin Andresen -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
The only other thing I'd like to see there is the start of a new anti-DoS framework. I think once the outline is in place other people will be able to fill it in appropriately. But the current framework has to be left behind. If I had to choose one thing to evict to make time for that, it'd be the whitepapers. At the moment we still have plenty of headroom in block sizes, even post April. It can probably be safely delayed for a while. On Fri, Aug 16, 2013 at 2:11 PM, Mike Hearn m...@plan99.net wrote: Cool. Maybe it's time for another development update on the foundation blog? On Fri, Aug 16, 2013 at 3:00 AM, Gavin Andresen gavinandre...@gmail.comwrote: Mike asked what non-0.9 code I'm working on; the three things on the top of my list are: 1) Smarter fee handling on the client side, instead of hard-coded fees. I was busy today generating scatter-plots and histograms of transaction fees versus priorities to get some insight into what miner policies look like right now. 2) First double-spend relaying and alerting, to better support low-value in-person transactions. Related: *Have *a *Snack*, Pay with *Bitcoins*http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf 3) Work on 2-3 whitepapers on why we need to increase or remove the 1MB block size limit, how we can do it safely, and go through all of the arguments that have been made against it and explain why they're wrong. -- -- Gavin Andresen -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
https://togami.com/~warren/archive/2013/example-bitcoind-dos-mitigation-via-iptables.txt *Anti-DoS Low Hanging Fruit: source IP or subnet connection limits* If you disallow the same IP and/or subnet from establishing too many TCP connections with your node, it becomes more expensive for attackers to use a single host exhaust a target node's resources. This iptables firewall based example has almost zero drawbacks, but it is too complicated for most people to deploy. Yes, there is a small chance that you will block legitimate connections, but there are plenty of other nodes for random connections to choose from. Configurable per source IP and source subnet limits with sane defaults enforced by bitcoind itself would be a big improvement over the current situation where one host address can consume limited resources of many target nodes. This doesn't remove the risk of a network-wide connection exhaustion attack by a determined attacker, but it at least makes multiple types of attacks a lot more expensive. This also doesn't do much against the io vulnerability, which would require major redesigns to prevent in Bitcoin. https://github.com/litecoin-project/litecoin/commit/db4d8e21d99551bef4c807aa1534a074e4b7964d *Want to safely delay the block size limit increase for another year or two? * This patch alone enables that. On Fri, Aug 16, 2013 at 2:24 AM, Mike Hearn m...@plan99.net wrote: The only other thing I'd like to see there is the start of a new anti-DoS framework. I think once the outline is in place other people will be able to fill it in appropriately. But the current framework has to be left behind. If I had to choose one thing to evict to make time for that, it'd be the whitepapers. At the moment we still have plenty of headroom in block sizes, even post April. It can probably be safely delayed for a while. On Fri, Aug 16, 2013 at 2:11 PM, Mike Hearn m...@plan99.net wrote: Cool. Maybe it's time for another development update on the foundation blog? On Fri, Aug 16, 2013 at 3:00 AM, Gavin Andresen gavinandre...@gmail.comwrote: Mike asked what non-0.9 code I'm working on; the three things on the top of my list are: 1) Smarter fee handling on the client side, instead of hard-coded fees. I was busy today generating scatter-plots and histograms of transaction fees versus priorities to get some insight into what miner policies look like right now. 2) First double-spend relaying and alerting, to better support low-value in-person transactions. Related: *Have *a *Snack*, Pay with *Bitcoins*http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf 3) Work on 2-3 whitepapers on why we need to increase or remove the 1MB block size limit, how we can do it safely, and go through all of the arguments that have been made against it and explain why they're wrong. -- -- Gavin Andresen -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
A ban-subnet RPC would be a reasonable addition, but obviously DoS attackers that are IP or bandwidth constrained are really just script kiddies. Also anything that involves every node operator doing manual intervention rather works against decentralisation and having a big network. That's why I keep pushing for automated heuristic driven prioritisation. On Fri, Aug 16, 2013 at 3:41 PM, Warren Togami Jr. wtog...@gmail.comwrote: https://togami.com/~warren/archive/2013/example-bitcoind-dos-mitigation-via-iptables.txt *Anti-DoS Low Hanging Fruit: source IP or subnet connection limits* If you disallow the same IP and/or subnet from establishing too many TCP connections with your node, it becomes more expensive for attackers to use a single host exhaust a target node's resources. This iptables firewall based example has almost zero drawbacks, but it is too complicated for most people to deploy. Yes, there is a small chance that you will block legitimate connections, but there are plenty of other nodes for random connections to choose from. Configurable per source IP and source subnet limits with sane defaults enforced by bitcoind itself would be a big improvement over the current situation where one host address can consume limited resources of many target nodes. This doesn't remove the risk of a network-wide connection exhaustion attack by a determined attacker, but it at least makes multiple types of attacks a lot more expensive. This also doesn't do much against the io vulnerability, which would require major redesigns to prevent in Bitcoin. https://github.com/litecoin-project/litecoin/commit/db4d8e21d99551bef4c807aa1534a074e4b7964d *Want to safely delay the block size limit increase for another year or two?* This patch alone enables that. On Fri, Aug 16, 2013 at 2:24 AM, Mike Hearn m...@plan99.net wrote: The only other thing I'd like to see there is the start of a new anti-DoS framework. I think once the outline is in place other people will be able to fill it in appropriately. But the current framework has to be left behind. If I had to choose one thing to evict to make time for that, it'd be the whitepapers. At the moment we still have plenty of headroom in block sizes, even post April. It can probably be safely delayed for a while. On Fri, Aug 16, 2013 at 2:11 PM, Mike Hearn m...@plan99.net wrote: Cool. Maybe it's time for another development update on the foundation blog? On Fri, Aug 16, 2013 at 3:00 AM, Gavin Andresen gavinandre...@gmail.com wrote: Mike asked what non-0.9 code I'm working on; the three things on the top of my list are: 1) Smarter fee handling on the client side, instead of hard-coded fees. I was busy today generating scatter-plots and histograms of transaction fees versus priorities to get some insight into what miner policies look like right now. 2) First double-spend relaying and alerting, to better support low-value in-person transactions. Related: *Have *a *Snack*, Pay with *Bitcoins*http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf 3) Work on 2-3 whitepapers on why we need to increase or remove the 1MB block size limit, how we can do it safely, and go through all of the arguments that have been made against it and explain why they're wrong. -- -- Gavin Andresen -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes.
Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
On Fri, Aug 16, 2013 at 02:24:04PM +0200, Mike Hearn wrote: The only other thing I'd like to see there is the start of a new anti-DoS framework. I think once the outline is in place other people will be able to fill it in appropriately. But the current framework has to be left behind. Part of anti-DoS should include making it easier for people to contribute back to the network. Lowest hanging fruit: 1) SPV nodes with spare bandwidth should relay whole blocks to reduce the load on full-nodes. The SPV security model is based on hashing power anyway, so there is no major harm in doing so - if you have the resources to fake blocks, you probably have the resources to sybil the network anyway. 2) It's probably reasonable for SPV peers with bandwidth to be willing to do bloom filtering on the behalf of peers that don't have spare bandwidth. Hence they would set NODE_BLOOM, but not NODE_NETWORK. (or more likely some more nuanced flags) Again this has to apply to full blocks only unless we come up with some PoW scheme or similar to discourage DoS attacks via invalid transactions. (maintaining partial UTXO sets is another possibility, although a complex one) Both examples work best with payment protocols where the recipient is responsible for getting the transaction broadcast. Similarly you can by default not connect to full-node peers, and then connect to them on demand when you have a transaction to send. Doing this also makes it more difficult to sybil the network - for instance right now you can create SPV honeypots that allow incoming connections only from SPV nodes, thus attracting a disproportionate % of the total SPV population given a relatively small number of nodes. You can then use that to harm SPV nodes by, for instance, making a % of transactions be dropped deterministicly, either by the bloom matching code, or when sent. Users unlucky enough to be surrounded by sybil nodes will have their transactions mysteriously fail to arrive in their wallets, or have their transactions mysteriously never confirm. Given how few full nodes there are, it probably won't take very many honeypots to pull off this attack, especially if you combine it with a simultaneous max connections or bloom io attack to degrade the capacity of honest nodes. Deanonymization is another attack that can be done at the same time of course. In any case, the more peers on the network that can relay data the better. 3) Make it easier to run a full node. IMO partial mode is the way to go here. Note that from a legal perspective we really want to make sure that running full nodes (and mining p2pool or solo) continue to be something ordinary users do. We do not want to give the impression to regulators that running a full node is in any way unusual or rare, and thus something that might be practical or desirable to regulate. Users should be given clear options about how much disk space and bandwidth to donate to the health of the network, and within those limits nodes should always try to make progress towards being full nodes, and in the meantime being increasingly productive partial nodes. Even with pure SPV nodes if they are relaying block data and ideally transactions they make it much more difficult for regulations to be made that, say, require full node operators to apply blacklists to transactions in the mempool or in blocks. 4) This is really a side effect, and not directly DoS-related, but unfortunately we're going to have to create some kind of proof-of-UTXO-possession that miners include in the blocks they mine. With partial mode it's just too easy and tempting for people to mine blocks with fee paying transactions in them without actually having the full UTXO set; such nodes can't tell if a block is invalid due to a fake txin, and thus will happily extend a invalid chain. This possession proof can probably be make part of a UTXO commitment. If I had to choose one thing to evict to make time for that, it'd be the whitepapers. At the moment we still have plenty of headroom in block sizes, even post April. It can probably be safely delayed for a while. Lots of off-chain tx solutions are popping up which will help push back the issue's relevance as well. Also your micropayment channels possibly. -- 'peter'[:-1]@petertodd.org 000b9656276a0fdab028ca759c3fd7f951fb20196c264b5cd1ce signature.asc Description: Digital signature -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
That change was made in response to user complaints. Heck we get complaints about battery life and bandwidth impact even with Bloom filtering. We can't just randomly start using peoples bandwidth for relaying blocks, especially as I guess most SPV nodes are behind NAT. If Gavin is right and the future is dominated by mobiles and tablets, then it will require a change of thinking in how P2P networks work. I think there are plenty of people with private servers who would be willing to run nodes though. I'm not too worried about this. On Fri, Aug 16, 2013 at 4:27 PM, Warren Togami Jr. wtog...@gmail.comwrote: bitcoinj-0.10 release notes: - We now require Bloom-capable (0.8+) peers by default and will disconnect from older nodes. This avoids accidental bandwidth saturation on mobile devices. Given the user-security concern that Peter brings up, reconsideration of this new default behavior in SPV clients may be warranted. On Fri, Aug 16, 2013 at 4:15 AM, Peter Todd p...@petertodd.org wrote: On Fri, Aug 16, 2013 at 10:01:16AM -0400, Peter Todd wrote: Doing this also makes it more difficult to sybil the network - for instance right now you can create SPV honeypots that allow incoming connections only from SPV nodes, thus attracting a disproportionate % of the total SPV population given a relatively small number of nodes. You can then use that to harm SPV nodes by, for instance, making a % of transactions be dropped deterministicly, either by the bloom matching code, or when sent. Users unlucky enough to be surrounded by sybil nodes will have their transactions mysteriously fail to arrive in their wallets, or have their transactions mysteriously never confirm. Given how few full nodes there are, it probably won't take very many honeypots to pull off this attack, especially if you combine it with a simultaneous max connections or bloom io attack to degrade the capacity of honest nodes. Oh, here's an even better way to do the tx drop attack: when you drop a transaction, make a fake one that pays the same scriptPubKeys with the same amount, and send it to the SPV peer instead. They'll see the transaction go through and show up in their wallet, but it'll look like it got stuck and never confirmed. They'll soon wind up with a wallet full of useless transactions, effectively locking them out of their money. Here's another question for you Mike: So does bitcoinj have any protections against peers flooding you with useless garbage? It'd be easy to rack up a user's data bill for instance by just creating junk unconfirmed transactions matching the bloom filter. -- 'peter'[:-1]@petertodd.org 0018dcf5bcc3f018a05517ba1c479b432ba422015d4506496e55 -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
On Fri, Aug 16, 2013 at 6:41 AM, Warren Togami Jr. wtog...@gmail.com wrote: If you disallow the same IP and/or subnet from establishing too many TCP connections with your node, [...] has almost zero drawbacks, There are whole countries who access the internet from single IP addresses. There are major institution with hundreds or even thousands of hosts that could be running Bitcoin who are visible to the public internet as a single IP address (/single subnet). Most tor traffic exits to the internet from a dozen of the largest exits, common local-network configurations have people addnode-ing local hosts from many systems on a subnet, etc. Prioritizing the availability of inbound slots based on source IP is reasonable and prudent, but it does not have almost zero drawbacks. Outright limiting is even worse. As a protective measure its also neigh useless for IPv6 connected hosts and hidden service hosts. It's also ineffective at attacks which exhaust your memory, cpu, IO, or bandwidth without trying to exhaust your sockets. So I am not opposed to prioritizing based on it (e.g. when full pick an inbound connection to drop based on criteria which includes network mask commonality), but I would not want to block completely based on this. -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
On Fri, Aug 16, 2013 at 04:36:20PM +0200, Mike Hearn wrote: That change was made in response to user complaints. Heck we get complaints about battery life and bandwidth impact even with Bloom filtering. We can't just randomly start using peoples bandwidth for relaying blocks, especially as I guess most SPV nodes are behind NAT. UPNP seems to work well for the reference client. What's the situation there on Android? I leave my phone plugged in and connected via wifi for most of the day; lots of people do that. The user interface for this stuff is very simple: How much bandwidth will you contribute back? If you contribute more bandwidth back, other peers will prioritize you and your wallet will be more reliable. -- 'peter'[:-1]@petertodd.org 003cfc051263917373a1cab2655994b97c54a625021f52c84658 signature.asc Description: Digital signature -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
On Fri, Aug 16, 2013 at 4:59 PM, Peter Todd p...@petertodd.org wrote: UPNP seems to work well for the reference client. What's the situation there on Android? Not sure - it could be investigated. I think UPNP is an entirely userspace-implementable protocol, so in theory it could be done by a userspace library (even libminiupnp - java is not a requirement on android) I leave my phone plugged in and connected via wifi for most of the day; lots of people do that. I suspect you mean I think lots of people do that. I'm not so sure. We could potentially run an experiment in the Android app to measure how many users are in a position to contribute back, but just because you have wifi doesn't mean you can reconfigure it using UPnP. That helps a lot in home networks, but at the office it doesn't help. I'm wary of a ton of work being put in to achieve not very much here. Satoshi's original vision was always that millions of users were supported by 100,000 or so nodes. I don't think that's unreasonable over the long term. Besides, prioritisation isn't very hard. Nodes can just hand clients a signed timestamp which they remember. When re-connecting, the signed timestamp is handed back to the node and it gives priority to those with old timestamps. No state is required on the node side. Signing and checking can be passed onto the general ECDSA thread pool that works its way through pending signature operations, they'd be prioritised lower than checking blocks/broadcasts. -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
On Fri, Aug 16, 2013 at 05:11:35PM +0200, Mike Hearn wrote: On Fri, Aug 16, 2013 at 4:59 PM, Peter Todd p...@petertodd.org wrote: UPNP seems to work well for the reference client. What's the situation there on Android? Not sure - it could be investigated. I think UPNP is an entirely userspace-implementable protocol, so in theory it could be done by a userspace library (even libminiupnp - java is not a requirement on android) Do find out. I leave my phone plugged in and connected via wifi for most of the day; lots of people do that. I suspect you mean I think lots of people do that. I'm not so sure. We could potentially run an experiment in the Android app to measure how many users are in a position to contribute back, but just because you have wifi doesn't mean you can reconfigure it using UPnP. That helps a lot in home networks, but at the office it doesn't help. Also worth finding out. I'm wary of a ton of work being put in to achieve not very much here. Satoshi's original vision was always that millions of users were supported by 100,000 or so nodes. I don't think that's unreasonable over the long term. Appeal to authority. Stop bringing up Satoshi's vision - our understanding of crypto-currencies has improved in the 4.5 years since Bitcoin was released. Satoshi didn't even forsee pool mining, which says a lot about his economic judgement. Besides, prioritisation isn't very hard. Nodes can just hand clients a signed timestamp which they remember. When re-connecting, the signed timestamp is handed back to the node and it gives priority to those with old timestamps. No state is required on the node side. Signing and checking can be passed onto the general ECDSA thread pool that works its way through pending signature operations, they'd be prioritised lower than checking blocks/broadcasts. Right, so you're giving priority to peers that have been around for awhile. You've succeeded in forcing attackers to wait a bit. A) What's the definition of a peer? What stops me from pretending to be 100 peers? B) Given an attacker willing to wait, what's your plan? -- 'peter'[:-1]@petertodd.org 004a52a297d9ae8ecde2ba62b681cc5a4cfbf7636032fc78e7d0 signature.asc Description: Digital signature -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
A sane default that better protects users could be... If (plugged into power) (wifi) then non-bloom peers are OK. It would protect those users more than reliance upon on the smaller subset of bloom nodes. Scale back to the less secure behavior when battery and bandwidth matters. Warren On Fri, Aug 16, 2013 at 4:36 AM, Mike Hearn m...@plan99.net wrote: That change was made in response to user complaints. Heck we get complaints about battery life and bandwidth impact even with Bloom filtering. We can't just randomly start using peoples bandwidth for relaying blocks, especially as I guess most SPV nodes are behind NAT. If Gavin is right and the future is dominated by mobiles and tablets, then it will require a change of thinking in how P2P networks work. I think there are plenty of people with private servers who would be willing to run nodes though. I'm not too worried about this. On Fri, Aug 16, 2013 at 4:27 PM, Warren Togami Jr. wtog...@gmail.comwrote: bitcoinj-0.10 release notes: - We now require Bloom-capable (0.8+) peers by default and will disconnect from older nodes. This avoids accidental bandwidth saturation on mobile devices. Given the user-security concern that Peter brings up, reconsideration of this new default behavior in SPV clients may be warranted. On Fri, Aug 16, 2013 at 4:15 AM, Peter Todd p...@petertodd.org wrote: On Fri, Aug 16, 2013 at 10:01:16AM -0400, Peter Todd wrote: Doing this also makes it more difficult to sybil the network - for instance right now you can create SPV honeypots that allow incoming connections only from SPV nodes, thus attracting a disproportionate % of the total SPV population given a relatively small number of nodes. You can then use that to harm SPV nodes by, for instance, making a % of transactions be dropped deterministicly, either by the bloom matching code, or when sent. Users unlucky enough to be surrounded by sybil nodes will have their transactions mysteriously fail to arrive in their wallets, or have their transactions mysteriously never confirm. Given how few full nodes there are, it probably won't take very many honeypots to pull off this attack, especially if you combine it with a simultaneous max connections or bloom io attack to degrade the capacity of honest nodes. Oh, here's an even better way to do the tx drop attack: when you drop a transaction, make a fake one that pays the same scriptPubKeys with the same amount, and send it to the SPV peer instead. They'll see the transaction go through and show up in their wallet, but it'll look like it got stuck and never confirmed. They'll soon wind up with a wallet full of useless transactions, effectively locking them out of their money. Here's another question for you Mike: So does bitcoinj have any protections against peers flooding you with useless garbage? It'd be easy to rack up a user's data bill for instance by just creating junk unconfirmed transactions matching the bloom filter. -- 'peter'[:-1]@petertodd.org 0018dcf5bcc3f018a05517ba1c479b432ba422015d4506496e55 -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
On 16 August 2013 03:00, Gavin Andresen gavinandre...@gmail.com wrote: Mike asked what non-0.9 code I'm working on; the three things on the top of my list are: 1) Smarter fee handling on the client side, instead of hard-coded fees. I was busy today generating scatter-plots and histograms of transaction fees versus priorities to get some insight into what miner policies look like right now. +1 2) First double-spend relaying and alerting, to better support low-value in-person transactions. Related: *Have *a *Snack*, Pay with *Bitcoins*http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf +1 3) Work on 2-3 whitepapers on why we need to increase or remove the 1MB block size limit, how we can do it safely, and go through all of the arguments that have been made against it and explain why they're wrong. What block size do you think is ideal? -- -- Gavin Andresen -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
