path: root/55/d11814028553e702479476751ae94b2ce58ecb

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <wtogami@gmail.com>) id 1VAKT9-0006x5-It
	for bitcoin-development@lists.sourceforge.net;
	Fri, 16 Aug 2013 13:53:35 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.160.54 as permitted sender)
	client-ip=209.85.160.54; envelope-from=wtogami@gmail.com;
	helo=mail-pb0-f54.google.com; 
Received: from mail-pb0-f54.google.com ([209.85.160.54])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1VAKT8-0002kZ-2p
	for bitcoin-development@lists.sourceforge.net;
	Fri, 16 Aug 2013 13:53:35 +0000
Received: by mail-pb0-f54.google.com with SMTP id ro12so2010097pbb.41
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 16 Aug 2013 06:53:28 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.68.229.2 with SMTP id sm2mr1775749pbc.68.1376661208134; Fri,
	16 Aug 2013 06:53:28 -0700 (PDT)
Received: by 10.66.72.225 with HTTP; Fri, 16 Aug 2013 06:53:28 -0700 (PDT)
In-Reply-To: <CANEZrP2cdQ4vyO5N42FO=Y6c_bt6yTes9p5UTs+cD66YiNC08Q@mail.gmail.com>
References: <CABsx9T32q8mKgtmsaZgh7nuhHY5cExeW=FiadzXq3jXVP=NBTw@mail.gmail.com>
	<CANEZrP0PEcP339MKRyrHXHCCsP3BxRHT-ZfKRQ7G2Ou+15CD7A@mail.gmail.com>
	<CANEZrP3LAR0erjgmTHruLwPNDdx-OVyb9KK52E6UnmE4ZuBrvQ@mail.gmail.com>
	<CAEz79PqpQ0NG3WHHo7gqoZJVWqAQ4GwUaqSD_7LzWSvSQCHHig@mail.gmail.com>
	<CANEZrP2cdQ4vyO5N42FO=Y6c_bt6yTes9p5UTs+cD66YiNC08Q@mail.gmail.com>
Date: Fri, 16 Aug 2013 03:53:28 -1000
Message-ID: <CAEz79Ppx-qt630+jurFBkJ6NwsEAb8gZgziL_zJK0v39jcnbZg@mail.gmail.com>
From: "Warren Togami Jr." <wtogami@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=047d7b162fd7497adb04e410eafb
X-Spam-Score: -0.6 (/)
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
	(wtogami[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	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: 1VAKT8-0002kZ-2p
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: Fri, 16 Aug 2013 13:53:35 -0000

--047d7b162fd7497adb04e410eafb
Content-Type: text/plain; charset=UTF-8

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

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

<div dir=3D"ltr">Automatic heuristic driven prioritization, with sane defau=
lts and some configurable knobs, is exactly what I suggest.<div><br></div><=
div>In the short-term though, any connection limits added to the client by =
default would be the simplest and easiest protection measure to audit. =C2=
=A0It would improve things a lot over the current situation where there are=
 no limits, and it requires no manual intervention from node operators.<div=
>
<br></div><div>Warren<br><div><br></div><div><br></div><div><br><div><br></=
div><div><br></div></div></div></div></div><div class=3D"gmail_extra"><br><=
br><div class=3D"gmail_quote">On Fri, Aug 16, 2013 at 3:46 AM, Mike Hearn <=
span dir=3D"ltr">&lt;<a href=3D"mailto:mike@plan99.net" target=3D"_blank">m=
ike@plan99.net</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">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 eve=
ry node operator doing manual intervention rather works against decentralis=
ation and having a big network. That&#39;s why I keep pushing for automated=
 heuristic driven prioritisation.</div>
<div class=3D"HOEnZb"><div class=3D"h5">
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri, Aug 1=
6, 2013 at 3:41 PM, Warren Togami Jr. <span dir=3D"ltr">&lt;<a href=3D"mail=
to:wtogami@gmail.com" target=3D"_blank">wtogami@gmail.com</a>&gt;</span> wr=
ote:<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 href=3D"https://tog=
ami.com/~warren/archive/2013/example-bitcoind-dos-mitigation-via-iptables.t=
xt" target=3D"_blank">https://togami.com/~warren/archive/2013/example-bitco=
ind-dos-mitigation-via-iptables.txt</a><br>

</div><b>Anti-DoS Low Hanging Fruit: source IP or subnet connection limits<=
/b><div>
<div>If you disallow the same IP and/or subnet from establishing too many T=
CP connections with your node, it becomes more expensive for attackers to u=
se a single host exhaust a target node&#39;s resources. =C2=A0This iptables=
 firewall based example has almost zero drawbacks, but it is too complicate=
d for most people to deploy. =C2=A0Yes, there is a small chance that you wi=
ll block legitimate connections, but there are plenty of other nodes for ra=
ndom connections to choose from. =C2=A0Configurable per source IP and sourc=
e subnet limits with sane defaults enforced by bitcoind itself would be a b=
ig improvement over the current situation where one host address can consum=
e limited resources of many target nodes.</div>


<div><br></div><div>This doesn&#39;t remove the risk of a network-wide conn=
ection exhaustion attack by a determined attacker, but it at least makes mu=
ltiple types of attacks a lot more expensive. =C2=A0This also doesn&#39;t d=
o much against the io vulnerability, which would require major redesigns to=
 prevent in Bitcoin.</div>


<div><br></div><div><a href=3D"https://github.com/litecoin-project/litecoin=
/commit/db4d8e21d99551bef4c807aa1534a074e4b7964d" target=3D"_blank">https:/=
/github.com/litecoin-project/litecoin/commit/db4d8e21d99551bef4c807aa1534a0=
74e4b7964d</a><br>


</div><div><b>Want to safely delay the block size limit increase for anothe=
r year or two?</b> =C2=A0This patch alone enables that.</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 2:24 AM, Mike Hearn <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt;</s=
pan> wrote:<br>
</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div><div><div dir=3D"ltr">The o=
nly other thing I&#39;d like to see there is the start of a new anti-DoS fr=
amework. 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.<=
div>



<br></div><div>If I had to choose one thing to evict to make time for that,=
 it&#39;d be the whitepapers. At the moment we still have plenty of headroo=
m in block sizes, even post April. It can probably be safely delayed for a =
while.</div>



</div><div><div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quot=
e">On Fri, Aug 16, 2013 at 2:11 PM, Mike Hearn <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt;</spa=
n> 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">Cool. Maybe it&#39;s time for another development update o=
n the foundation blog?</div><div><div><div class=3D"gmail_extra"><br><br><d=
iv class=3D"gmail_quote">On Fri, Aug 16, 2013 at 3:00 AM, Gavin Andresen <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:gavinandresen@gmail.com" target=3D"_b=
lank">gavinandresen@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">Mike asked what non-0.9 cod=
e I&#39;m working on; the three things on the top of my list are:<div><br><=
/div>




<div>1) Smarter fee handling on the client side, instead of hard-coded fees=
. I was busy today generating scatter-plots and histograms of transaction f=
ees versus priorities to get some insight into what miner policies look lik=
e right now.</div>





<div><br></div><div>2) &quot;First double-spend&quot; relaying and alerting=
, to better support low-value in-person transactions. =C2=A0Related:=C2=A0<=
/div><h3 style=3D"margin:0px;padding:0px;border:0px;font-weight:normal;font=
-size:16px;font-family:Arial,sans-serif">





<a href=3D"http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/=
P2P2013_093.pdf" style=3D"color:rgb(102,17,204);outline:none" target=3D"_bl=
ank"><b style=3D"color:rgb(102,17,204);outline:none">Have=C2=A0</b><font co=
lor=3D"#6611cc">a=C2=A0</font><b style=3D"color:rgb(102,17,204);outline:non=
e">Snack</b><font color=3D"#6611cc">, Pay with=C2=A0</font><b style=3D"colo=
r:rgb(102,17,204);outline:none">Bitcoins</b></a>=C2=A0</h3>





<div><br></div><div>3) Work on 2-3 whitepapers on why we need to increase o=
r 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&#3=
9;re wrong.<span><font color=3D"#888888"><div class=3D"gmail_extra">





<div><br></div>-- <br>--<br>Gavin Andresen<br>
</div></font></span></div><div class=3D"gmail_extra"><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</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>

--047d7b162fd7497adb04e410eafb--