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. 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 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. 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 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 > >