From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VAKHy-0003rN-DO for bitcoin-development@lists.sourceforge.net; Fri, 16 Aug 2013 13:42:02 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.192.172 as permitted sender) client-ip=209.85.192.172; envelope-from=wtogami@gmail.com; helo=mail-pd0-f172.google.com; Received: from mail-pd0-f172.google.com ([209.85.192.172]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VAKHw-0006JJ-HX for bitcoin-development@lists.sourceforge.net; Fri, 16 Aug 2013 13:42:02 +0000 Received: by mail-pd0-f172.google.com with SMTP id z10so2281038pdj.3 for ; Fri, 16 Aug 2013 06:41:54 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.66.232.8 with SMTP id tk8mr3198180pac.121.1376660514673; Fri, 16 Aug 2013 06:41:54 -0700 (PDT) Received: by 10.66.72.225 with HTTP; Fri, 16 Aug 2013 06:41:54 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 Aug 2013 03:41:54 -1000 Message-ID: From: "Warren Togami Jr." To: Bitcoin Dev Content-Type: multipart/alternative; boundary=047d7b11195ff41d3504e410c0f7 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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.192.172 listed in list.dnswl.org] -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: 1VAKHw-0006JJ-HX 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: Fri, 16 Aug 2013 13:42:02 -0000 --047d7b11195ff41d3504e410c0f7 Content-Type: text/plain; charset=UTF-8 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 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 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 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* >>> >>> >>> 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 > > --047d7b11195ff41d3504e410c0f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
= Anti-DoS Low Hanging Fruit: source IP or subnet connection limits
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'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.

This doesn'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't d= o much against the io vulnerability, which would require major redesigns to= prevent in Bitcoin.

Want to safely delay the block size limit increase for anothe= r year or two? =C2=A0This 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 appropriate= ly. 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 headroo= m 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 Hear= n <mike@plan99.net> wrote:
Cool. Maybe it's time for another development update o= n the foundation blog?


On Fri, Aug 16, 2013 at 3:00 AM, Gavin Andresen <gavinandresen@gmail.com> wrote:
Mike asked what non-0.9 cod= e I'm working on; the three things on the top of my list are:

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

2) "First double-spend" relaying and alerting= , to better support low-value in-person transactions. =C2=A0Related:=C2=A0<= /div>

Have=C2=A0a=C2=A0Snack, Pay with=C2=A0Bitcoins=C2=A0


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= 9;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/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


--047d7b11195ff41d3504e410c0f7--