path: root/c2/562a9e27f85367e2dad1c7cb8e14470e34bf55

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 <mh.in.england@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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: <CAEz79Pq87Bp-SZsadHaRPk9HuzoeYrCK7noHm+-0iqNP0DFKuA@mail.gmail.com>
References: <CABsx9T32q8mKgtmsaZgh7nuhHY5cExeW=FiadzXq3jXVP=NBTw@mail.gmail.com>
	<CANEZrP0PEcP339MKRyrHXHCCsP3BxRHT-ZfKRQ7G2Ou+15CD7A@mail.gmail.com>
	<CANEZrP3LAR0erjgmTHruLwPNDdx-OVyb9KK52E6UnmE4ZuBrvQ@mail.gmail.com>
	<20130816140116.GB16201@petertodd.org>
	<20130816141536.GD16201@petertodd.org>
	<CAEz79PoK9u9ffJ5jR8yXk8eCFP0Ytk_bno0mpcpM24mt-GGg5w@mail.gmail.com>
	<CANEZrP3hHh3k5+ePGbqVeyo3oV=RTy36FA+8MbOZXg3yMqRxAw@mail.gmail.com>
	<CAEz79Pq87Bp-SZsadHaRPk9HuzoeYrCK7noHm+-0iqNP0DFKuA@mail.gmail.com>
Date: Sat, 17 Aug 2013 14:35:41 +0200
X-Google-Sender-Auth: pQBd-CjTKBYN8pp_RyWbTq5eEIc
Message-ID: <CANEZrP21mwzAhNEOsT+wpw-OQd_r9BVbDFeQdgh0FZ6VGArFTw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: "Warren Togami Jr." <wtogami@gmail.com>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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. <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
>
>

--001a11c361fc014a3c04e423f2f4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">There shouldn&#39;t be a &quot;smaller subset of Bloom fil=
tering nodes&quot; because the idea of making it optional is a stupid one.=
=C2=A0<div><br></div><div>If you&#39;re worried about DoS, come up with rea=
l fixes instead of trying to break features that work.</div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sat,=
 Aug 17, 2013 at 2:08 AM, Warren Togami Jr. <span dir=3D"ltr">&lt;<a href=
=3D"mailto:wtogami@gmail.com" target=3D"_blank">wtogami@gmail.com</a>&gt;</=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>A sane default that be=
tter protects users could be...</div><div><br></div><div>If (plugged into p=
ower) &amp;&amp; (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.<span class=3D"HOEnZb"><font color=3D"#888888"><br>

</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888"><div><br=
></div><div>Warren</div></font></span></div><div class=3D"HOEnZb"><div clas=
s=3D"h5"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On F=
ri, Aug 16, 2013 at 4:36 AM, Mike Hearn <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt;</span> wrot=
e:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">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&#39;t just randomly start u=
sing peoples bandwidth for relaying blocks, especially as I guess most SPV =
nodes are behind NAT.<div>


<br></div><div>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&#39;m not too worried about this.</div>


</div><div><div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quot=
e">On Fri, Aug 16, 2013 at 4:27 PM, Warren Togami Jr. <span dir=3D"ltr">&lt=
;<a href=3D"mailto:wtogami@gmail.com" target=3D"_blank">wtogami@gmail.com</=
a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">bitcoinj-0.10 release notes=
:<div><ul style=3D"font-family:arial,sans-serif;font-size:12.80000019073486=
3px;padding-left:25px;max-width:62em">


<li style=3D"margin-left:15px;margin-bottom:0.3em">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.</li>
</ul><div><font face=3D"arial, sans-serif">Given the user-security concern =
that Peter brings up, reconsideration of this new default behavior in SPV c=
lients may be warranted.</font></div><div><br></div></div></div><div class=
=3D"gmail_extra">



<br><br><div class=3D"gmail_quote"><div><div>On Fri, Aug 16, 2013 at 4:15 A=
M, Peter Todd <span dir=3D"ltr">&lt;<a href=3D"mailto:pete@petertodd.org" t=
arget=3D"_blank">pete@petertodd.org</a>&gt;</span> wrote:<br></div>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div><div>
<div>On Fri, Aug 16, 2013 at 10:01:16AM -0400, Peter Todd wrote:<br>
&gt; Doing this also makes it more difficult to sybil the network - for<br>
&gt; instance right now you can create &quot;SPV honeypots&quot; that allow=
 incoming<br>
&gt; connections only from SPV nodes, thus attracting a disproportionate % =
of<br>
&gt; the total SPV population given a relatively small number of nodes. You=
<br>
&gt; can then use that to harm SPV nodes by, for instance, making a % of<br=
>
&gt; transactions be dropped deterministicly, either by the bloom matching<=
br>
&gt; code, or when sent. Users unlucky enough to be surrounded by sybil nod=
es<br>
&gt; will have their transactions mysteriously fail to arrive in their<br>
&gt; wallets, or have their transactions mysteriously never confirm. Given<=
br>
&gt; how few full nodes there are, it probably won&#39;t take very many hon=
eypots<br>
&gt; to pull off this attack, especially if you combine it with a<br>
&gt; simultaneous max connections or bloom io attack to degrade the capacit=
y<br>
&gt; of honest nodes.<br>
<br>
</div>Oh, here&#39;s an even better way to do the &quot;tx drop&quot; attac=
k: when you drop<br>
a transaction, make a fake one that pays the same scriptPubKeys with the<br=
>
same amount, and send it to the SPV peer instead. They&#39;ll see the<br>
transaction go through and show up in their wallet, but it&#39;ll look like=
<br>
it got stuck and never confirmed. They&#39;ll soon wind up with a wallet<br=
>
full of useless transactions, effectively locking them out of their<br>
money.<br>
<br>
Here&#39;s another question for you Mike: So does bitcoinj have any<br>
protections against peers flooding you with useless garbage? It&#39;d be<br=
>
easy to rack up a user&#39;s data bill for instance by just creating junk<b=
r>
unconfirmed transactions matching the bloom filter.<br>
<div><div><br>
--<br>
&#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org" target=3D"_blank">pet=
ertodd.org</a><br>
0000000000000018dcf5bcc3f018a05517ba1c479b432ba422015d4506496e55<br>
</div></div><br></div></div><div>------------------------------------------=
------------------------------------<br>
Get 100% visibility into Java/.NET code with AppDynamics Lite!<br>
It&#39;s a free troubleshooting tool designed for production.<br>
Get down to code-level detail for bottlenecks, with &lt;2% overhead.<br>
Download for free and get started troubleshooting in minutes.<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D48897031&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D48897031&amp;iu=3D/4140/ostg.clktrk</a><br>___________________=
____________________________<br>




Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></div></blockquote></div><br></div>
<br>-----------------------------------------------------------------------=
-------<br>
Get 100% visibility into Java/.NET code with AppDynamics Lite!<br>
It&#39;s a free troubleshooting tool designed for production.<br>
Get down to code-level detail for bottlenecks, with &lt;2% overhead.<br>
Download for free and get started troubleshooting in minutes.<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D48897031&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D48897031&amp;iu=3D/4140/ostg.clktrk</a><br>___________________=
____________________________<br>



Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div><br>-----------------------------------------------------------=
-------------------<br>
Get 100% visibility into Java/.NET code with AppDynamics Lite!<br>
It&#39;s a free troubleshooting tool designed for production.<br>
Get down to code-level detail for bottlenecks, with &lt;2% overhead.<br>
Download for free and get started troubleshooting in minutes.<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D48897031&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D48897031&amp;iu=3D/4140/ostg.clktrk</a><br>___________________=
____________________________<br>

Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>

--001a11c361fc014a3c04e423f2f4--