Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VAfjR-0004Pz-5s for bitcoin-development@lists.sourceforge.net; Sat, 17 Aug 2013 12:35:49 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.179 as permitted sender) client-ip=209.85.214.179; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f179.google.com; Received: from mail-ob0-f179.google.com ([209.85.214.179]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VAfjP-0004MP-Eq for bitcoin-development@lists.sourceforge.net; Sat, 17 Aug 2013 12:35:49 +0000 Received: by mail-ob0-f179.google.com with SMTP id fb19so3026479obc.24 for ; Sat, 17 Aug 2013 05:35:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.236.169 with SMTP id uv9mr204938obc.59.1376742941998; Sat, 17 Aug 2013 05:35:41 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.80.165 with HTTP; Sat, 17 Aug 2013 05:35:41 -0700 (PDT) In-Reply-To: References: <20130816140116.GB16201@petertodd.org> <20130816141536.GD16201@petertodd.org> Date: Sat, 17 Aug 2013 14:35:41 +0200 X-Google-Sender-Auth: pQBd-CjTKBYN8pp_RyWbTq5eEIc Message-ID: From: Mike Hearn To: "Warren Togami Jr." Content-Type: multipart/alternative; boundary=001a11c361fc014a3c04e423f2f4 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1VAfjP-0004MP-Eq Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Gavin's post-0.9 TODO list... X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 12:35:49 -0000 --001a11c361fc014a3c04e423f2f4 Content-Type: text/plain; charset=UTF-8 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 > > --001a11c361fc014a3c04e423f2f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There shouldn't be a "smaller subset of Bloom fil= tering nodes" because the idea of making it optional is a stupid one.= =C2=A0

If you're worried about DoS, come up with rea= l 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 be= tter protects users could be...

If (plugged into p= ower) && (wifi) then non-bloom peers are OK. =C2=A0It would protect= those users more than reliance upon on the smaller subset of bloom nodes. = =C2=A0Scale back to the less secure behavior when battery and bandwidth mat= ters.
Warren


On F= ri, Aug 16, 2013 at 4:36 AM, Mike Hearn <mike@plan99.net> wrot= e:
That change was made in res= ponse to user complaints. Heck we get complaints about battery life and ban= dwidth impact even with Bloom filtering. We can't just randomly start u= sing 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 wor= k. I think there are plenty of people with private servers who would be wil= ling 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-cap= able (0.8+) peers by default and will disconnect from older nodes. This avo= ids accidental bandwidth saturation on mobile devices.
Given the user-security concern = that Peter brings up, reconsideration of this new default behavior in SPV c= lients may be warranted.



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<= br> > code, or when sent. Users unlucky enough to be surrounded by sybil nod= es
> will have their transactions mysteriously fail to arrive in their
> wallets, or have their transactions mysteriously never confirm. Given<= br> > how few full nodes there are, it probably won't take very many hon= eypots
> to pull off this attack, especially if you combine it with a
> simultaneous max connections or bloom io attack to degrade the capacit= y
> of honest nodes.

Oh, here's an even better way to do the "tx drop" attac= k: 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]@pet= ertodd.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/gam= pad/clk?id=3D48897031&iu=3D/4140/ostg.clktrk
___________________= ____________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment



-----------------------------------------------------------------------= -------
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/gam= pad/clk?id=3D48897031&iu=3D/4140/ostg.clktrk
___________________= ____________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment




-----------------------------------------------------------= -------------------
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/gam= pad/clk?id=3D48897031&iu=3D/4140/ostg.clktrk
___________________= ____________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--001a11c361fc014a3c04e423f2f4--