* [Bitcoin-development] Gavin's post-0.9 TODO list... @ 2013-08-16 1:00 Gavin Andresen 2013-08-16 4:06 ` Melvin Carvalho 2013-08-16 12:11 ` Mike Hearn 0 siblings, 2 replies; 27+ messages in thread From: Gavin Andresen @ 2013-08-16 1:00 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 790 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 1382 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Gavin's post-0.9 TODO list... 2013-08-16 1:00 [Bitcoin-development] Gavin's post-0.9 TODO list Gavin Andresen @ 2013-08-16 4:06 ` Melvin Carvalho 2013-08-16 12:11 ` Mike Hearn 1 sibling, 0 replies; 27+ messages in thread From: Melvin Carvalho @ 2013-08-16 4:06 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1580 bytes --] On 16 August 2013 03:00, Gavin Andresen <gavinandresen@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=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > [-- Attachment #2: Type: text/html, Size: 3314 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Gavin's post-0.9 TODO list... 2013-08-16 1:00 [Bitcoin-development] Gavin's post-0.9 TODO list Gavin Andresen 2013-08-16 4:06 ` Melvin Carvalho @ 2013-08-16 12:11 ` Mike Hearn 2013-08-16 12:24 ` Mike Hearn 1 sibling, 1 reply; 27+ messages in thread From: Mike Hearn @ 2013-08-16 12:11 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 988 bytes --] Cool. Maybe it's time for another development update on the foundation blog? On Fri, Aug 16, 2013 at 3:00 AM, Gavin Andresen <gavinandresen@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 > > [-- Attachment #2: Type: text/html, Size: 1930 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Gavin's post-0.9 TODO list... 2013-08-16 12:11 ` Mike Hearn @ 2013-08-16 12:24 ` Mike Hearn 2013-08-16 13:41 ` Warren Togami Jr. 2013-08-16 14:01 ` Peter Todd 0 siblings, 2 replies; 27+ messages in thread From: Mike Hearn @ 2013-08-16 12:24 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1533 bytes --] 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 <mike@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 <gavinandresen@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 >> >> > [-- Attachment #2: Type: text/html, Size: 2818 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Gavin's post-0.9 TODO list... 2013-08-16 12:24 ` Mike Hearn @ 2013-08-16 13:41 ` Warren Togami Jr. 2013-08-16 13:46 ` Mike Hearn ` (2 more replies) 2013-08-16 14:01 ` Peter Todd 1 sibling, 3 replies; 27+ messages in thread From: Warren Togami Jr. @ 2013-08-16 13:41 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3619 bytes --] 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 <mike@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 <mike@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 <gavinandresen@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=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > [-- Attachment #2: Type: text/html, Size: 5854 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Gavin's post-0.9 TODO list... 2013-08-16 13:41 ` Warren Togami Jr. @ 2013-08-16 13:46 ` Mike Hearn 2013-08-16 13:53 ` Warren Togami Jr. 2013-08-16 14:06 ` Peter Todd 2013-08-16 14:56 ` Gregory Maxwell 2 siblings, 1 reply; 27+ messages in thread From: Mike Hearn @ 2013-08-16 13:46 UTC (permalink / raw) To: Warren Togami Jr.; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 4789 bytes --] 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. <wtogami@gmail•com>wrote: > > 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 <mike@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 <mike@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 <gavinandresen@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=48897031&iu=/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=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > [-- Attachment #2: Type: text/html, Size: 7664 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Gavin's post-0.9 TODO list... 2013-08-16 13:46 ` Mike Hearn @ 2013-08-16 13:53 ` Warren Togami Jr. 0 siblings, 0 replies; 27+ messages in thread From: Warren Togami Jr. @ 2013-08-16 13:53 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 5401 bytes --] Automatic heuristic driven prioritization, with sane defaults and some configurable knobs, is exactly what I suggest. In the short-term though, any connection limits added to the client by default would be the simplest and easiest protection measure to audit. It would improve things a lot over the current situation where there are no limits, and it requires no manual intervention from node operators. Warren On Fri, Aug 16, 2013 at 3:46 AM, Mike Hearn <mike@plan99•net> wrote: > 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. <wtogami@gmail•com>wrote: > >> >> 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 <mike@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 <mike@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 < >>>> gavinandresen@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=48897031&iu=/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=48897031&iu=/4140/ostg.clktrk >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists•sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> > [-- Attachment #2: Type: text/html, Size: 8642 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Gavin's post-0.9 TODO list... 2013-08-16 13:41 ` Warren Togami Jr. 2013-08-16 13:46 ` Mike Hearn @ 2013-08-16 14:06 ` Peter Todd 2013-08-16 14:56 ` Gregory Maxwell 2 siblings, 0 replies; 27+ messages in thread From: Peter Todd @ 2013-08-16 14:06 UTC (permalink / raw) To: Warren Togami Jr.; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1215 bytes --] On Fri, Aug 16, 2013 at 03:41:54AM -1000, Warren Togami Jr. wrote: > 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. Have you looked into what it would take to just apply the IP diversity tests for outgoing connections to incoming connections? The code's already there... -- 'peter'[:-1]@petertodd.org 0000000000000018dcf5bcc3f018a05517ba1c479b432ba422015d4506496e55 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Gavin's post-0.9 TODO list... 2013-08-16 13:41 ` Warren Togami Jr. 2013-08-16 13:46 ` Mike Hearn 2013-08-16 14:06 ` Peter Todd @ 2013-08-16 14:56 ` Gregory Maxwell 2 siblings, 0 replies; 27+ messages in thread From: Gregory Maxwell @ 2013-08-16 14:56 UTC (permalink / raw) To: Warren Togami Jr.; +Cc: Bitcoin Dev On Fri, Aug 16, 2013 at 6:41 AM, Warren Togami Jr. <wtogami@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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Gavin's post-0.9 TODO list... 2013-08-16 12:24 ` Mike Hearn 2013-08-16 13:41 ` Warren Togami Jr. @ 2013-08-16 14:01 ` Peter Todd 2013-08-16 14:15 ` Peter Todd 1 sibling, 1 reply; 27+ messages in thread From: Peter Todd @ 2013-08-16 14:01 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 4454 bytes --] 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 000000000000000b9656276a0fdab028ca759c3fd7f951fb20196c264b5cd1ce [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Gavin's post-0.9 TODO list... 2013-08-16 14:01 ` Peter Todd @ 2013-08-16 14:15 ` Peter Todd 2013-08-16 14:27 ` Warren Togami Jr. 2013-08-19 3:09 ` John Dillon 0 siblings, 2 replies; 27+ messages in thread From: Peter Todd @ 2013-08-16 14:15 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1749 bytes --] 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 0000000000000018dcf5bcc3f018a05517ba1c479b432ba422015d4506496e55 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Gavin's post-0.9 TODO list... 2013-08-16 14:15 ` Peter Todd @ 2013-08-16 14:27 ` Warren Togami Jr. 2013-08-16 14:36 ` Mike Hearn 2013-08-19 3:09 ` John Dillon 1 sibling, 1 reply; 27+ messages in thread From: Warren Togami Jr. @ 2013-08-16 14:27 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2800 bytes --] 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 <pete@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 > 0000000000000018dcf5bcc3f018a05517ba1c479b432ba422015d4506496e55 > > > ------------------------------------------------------------------------------ > 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=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > [-- Attachment #2: Type: text/html, Size: 3950 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Gavin's post-0.9 TODO list... 2013-08-16 14:27 ` Warren Togami Jr. @ 2013-08-16 14:36 ` Mike Hearn 2013-08-16 14:59 ` Peter Todd 2013-08-17 0:08 ` Warren Togami Jr. 0 siblings, 2 replies; 27+ messages in thread From: Mike Hearn @ 2013-08-16 14:36 UTC (permalink / raw) To: Warren Togami Jr.; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 4107 bytes --] 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. <wtogami@gmail•com>wrote: > 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 <pete@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 >> 0000000000000018dcf5bcc3f018a05517ba1c479b432ba422015d4506496e55 >> >> >> ------------------------------------------------------------------------------ >> 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=48897031&iu=/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=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > [-- Attachment #2: Type: text/html, Size: 5907 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Gavin's post-0.9 TODO list... 2013-08-16 14:36 ` Mike Hearn @ 2013-08-16 14:59 ` Peter Todd 2013-08-16 15:06 ` Warren Togami Jr. 2013-08-16 15:11 ` Mike Hearn 2013-08-17 0:08 ` Warren Togami Jr. 1 sibling, 2 replies; 27+ messages in thread From: Peter Todd @ 2013-08-16 14:59 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 849 bytes --] 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 000000000000003cfc051263917373a1cab2655994b97c54a625021f52c84658 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Gavin's post-0.9 TODO list... 2013-08-16 14:59 ` Peter Todd @ 2013-08-16 15:06 ` Warren Togami Jr. 2013-08-16 15:11 ` Mike Hearn 1 sibling, 0 replies; 27+ messages in thread From: Warren Togami Jr. @ 2013-08-16 15:06 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 964 bytes --] I might agree this would be helpful for the many phones plugged into power and on wifi for large portions of the day. However that doesn't really help much when phone IP addresses change often as you move onto different networks, and currently IP address is the only thing that peers can keep track of for the goodness of a peer as there is no roaming pseudo-identity cookie due to separate goal of anonymity? I haven't studied the issue if would be even possible to have both privacy protection and unique node identifiers for anti-DoS authentication at the same time. On Fri, Aug 16, 2013 at 4:59 AM, Peter Todd <pete@petertodd•org> wrote: > 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 > 000000000000003cfc051263917373a1cab2655994b97c54a625021f52c84658 > [-- Attachment #2: Type: text/html, Size: 1484 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Gavin's post-0.9 TODO list... 2013-08-16 14:59 ` Peter Todd 2013-08-16 15:06 ` Warren Togami Jr. @ 2013-08-16 15:11 ` Mike Hearn 2013-08-16 15:13 ` Mike Hearn 2013-08-16 15:59 ` Peter Todd 1 sibling, 2 replies; 27+ messages in thread From: Mike Hearn @ 2013-08-16 15:11 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1506 bytes --] On Fri, Aug 16, 2013 at 4:59 PM, Peter Todd <pete@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. [-- Attachment #2: Type: text/html, Size: 2159 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Gavin's post-0.9 TODO list... 2013-08-16 15:11 ` Mike Hearn @ 2013-08-16 15:13 ` Mike Hearn 2013-08-16 15:59 ` Peter Todd 1 sibling, 0 replies; 27+ messages in thread From: Mike Hearn @ 2013-08-16 15:13 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1006 bytes --] Oops, hit send too early. 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. > The other nice thing about this approach, besides being stateless on the server side, is that it's up to the client whether or not they present the cookie. So the node can say "if you don't present your cookie I'm going to disconnect you" but when the node has sufficient resources, it'd just not request this and the client remains anonymous. If the client thinks the server is calling its bluff, it can just wait and see if it really does get disconnected and if so, present the cookie up front next time. [-- Attachment #2: Type: text/html, Size: 1386 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Gavin's post-0.9 TODO list... 2013-08-16 15:11 ` Mike Hearn 2013-08-16 15:13 ` Mike Hearn @ 2013-08-16 15:59 ` Peter Todd 1 sibling, 0 replies; 27+ messages in thread From: Peter Todd @ 2013-08-16 15:59 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2331 bytes --] On Fri, Aug 16, 2013 at 05:11:35PM +0200, Mike Hearn wrote: > On Fri, Aug 16, 2013 at 4:59 PM, Peter Todd <pete@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 000000000000004a52a297d9ae8ecde2ba62b681cc5a4cfbf7636032fc78e7d0 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Gavin's post-0.9 TODO list... 2013-08-16 14:36 ` Mike Hearn 2013-08-16 14:59 ` Peter Todd @ 2013-08-17 0:08 ` Warren Togami Jr. 2013-08-17 12:35 ` Mike Hearn 1 sibling, 1 reply; 27+ messages in thread From: Warren Togami Jr. @ 2013-08-17 0:08 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 4585 bytes --] 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 <mike@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. <wtogami@gmail•com>wrote: > >> 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 <pete@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 >>> 0000000000000018dcf5bcc3f018a05517ba1c479b432ba422015d4506496e55 >>> >>> >>> ------------------------------------------------------------------------------ >>> 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=48897031&iu=/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=48897031&iu=/4140/ostg.clktrk >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists•sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> > [-- Attachment #2: Type: text/html, Size: 6688 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Gavin's post-0.9 TODO list... 2013-08-17 0:08 ` Warren Togami Jr. @ 2013-08-17 12:35 ` Mike Hearn 2013-08-17 13:41 ` Jeff Garzik 0 siblings, 1 reply; 27+ messages in thread From: Mike Hearn @ 2013-08-17 12:35 UTC (permalink / raw) To: Warren Togami Jr.; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 5620 bytes --] 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. On Sat, Aug 17, 2013 at 2:08 AM, Warren Togami Jr. <wtogami@gmail•com>wrote: > 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 <mike@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. <wtogami@gmail•com>wrote: >> >>> 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 <pete@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 >>>> 0000000000000018dcf5bcc3f018a05517ba1c479b432ba422015d4506496e55 >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> 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=48897031&iu=/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=48897031&iu=/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=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > [-- Attachment #2: Type: text/html, Size: 8415 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Gavin's post-0.9 TODO list... 2013-08-17 12:35 ` Mike Hearn @ 2013-08-17 13:41 ` Jeff Garzik 0 siblings, 0 replies; 27+ messages in thread From: Jeff Garzik @ 2013-08-17 13:41 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev On Sat, Aug 17, 2013 at 8:35 AM, Mike Hearn <mike@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/ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Gavin's post-0.9 TODO list... 2013-08-16 14:15 ` Peter Todd 2013-08-16 14:27 ` Warren Togami Jr. @ 2013-08-19 3:09 ` John Dillon 2013-08-19 3:17 ` Peter Todd ` (2 more replies) 1 sibling, 3 replies; 27+ messages in thread From: John Dillon @ 2013-08-19 3:09 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Fri, Aug 16, 2013 at 2:15 PM, Peter Todd <pete@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----- ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Gavin's post-0.9 TODO list... 2013-08-19 3:09 ` John Dillon @ 2013-08-19 3:17 ` Peter Todd 2013-08-19 5:00 ` John Dillon 2013-08-19 5:11 ` Mark Friedenbach 2013-08-19 9:16 ` Mike Hearn 2 siblings, 1 reply; 27+ messages in thread From: Peter Todd @ 2013-08-19 3:17 UTC (permalink / raw) To: John Dillon; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 648 bytes --] On Mon, Aug 19, 2013 at 03:09:07AM +0000, John Dillon wrote: > 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. Would you please delay these bounties for a few weeks while things settle down. The service bit selection is fine, but for the other two a month would be appreciated. Thanks -- 'peter'[:-1]@petertodd.org [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Gavin's post-0.9 TODO list... 2013-08-19 3:17 ` Peter Todd @ 2013-08-19 5:00 ` John Dillon 2013-08-19 5:34 ` John Dillon 0 siblings, 1 reply; 27+ messages in thread From: John Dillon @ 2013-08-19 5:00 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Dev -----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----- ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Gavin's post-0.9 TODO list... 2013-08-19 5:00 ` John Dillon @ 2013-08-19 5:34 ` John Dillon 0 siblings, 0 replies; 27+ messages in thread From: John Dillon @ 2013-08-19 5:34 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Dev My apologies, that was for Peter On Mon, Aug 19, 2013 at 5:00 AM, John Dillon <john.dillon892@googlemail•com> wrote: > -----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----- ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Gavin's post-0.9 TODO list... 2013-08-19 3:09 ` John Dillon 2013-08-19 3:17 ` Peter Todd @ 2013-08-19 5:11 ` Mark Friedenbach 2013-08-19 9:16 ` Mike Hearn 2 siblings, 0 replies; 27+ messages in thread From: Mark Friedenbach @ 2013-08-19 5:11 UTC (permalink / raw) To: bitcoin-development -----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----- ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Gavin's post-0.9 TODO list... 2013-08-19 3:09 ` John Dillon 2013-08-19 3:17 ` Peter Todd 2013-08-19 5:11 ` Mark Friedenbach @ 2013-08-19 9:16 ` Mike Hearn 2 siblings, 0 replies; 27+ messages in thread From: Mike Hearn @ 2013-08-19 9:16 UTC (permalink / raw) To: John Dillon; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1455 bytes --] On Mon, Aug 19, 2013 at 5:09 AM, John Dillon <john.dillon892@googlemail•com>wrote: > > 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. [-- Attachment #2: Type: text/html, Size: 1946 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2013-08-19 9:16 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-08-16 1:00 [Bitcoin-development] Gavin's post-0.9 TODO list Gavin Andresen 2013-08-16 4:06 ` Melvin Carvalho 2013-08-16 12:11 ` Mike Hearn 2013-08-16 12:24 ` Mike Hearn 2013-08-16 13:41 ` Warren Togami Jr. 2013-08-16 13:46 ` Mike Hearn 2013-08-16 13:53 ` Warren Togami Jr. 2013-08-16 14:06 ` Peter Todd 2013-08-16 14:56 ` Gregory Maxwell 2013-08-16 14:01 ` Peter Todd 2013-08-16 14:15 ` Peter Todd 2013-08-16 14:27 ` Warren Togami Jr. 2013-08-16 14:36 ` Mike Hearn 2013-08-16 14:59 ` Peter Todd 2013-08-16 15:06 ` Warren Togami Jr. 2013-08-16 15:11 ` Mike Hearn 2013-08-16 15:13 ` Mike Hearn 2013-08-16 15:59 ` Peter Todd 2013-08-17 0:08 ` Warren Togami Jr. 2013-08-17 12:35 ` Mike Hearn 2013-08-17 13:41 ` Jeff Garzik 2013-08-19 3:09 ` John Dillon 2013-08-19 3:17 ` Peter Todd 2013-08-19 5:00 ` John Dillon 2013-08-19 5:34 ` John Dillon 2013-08-19 5:11 ` Mark Friedenbach 2013-08-19 9:16 ` Mike Hearn
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox