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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XLAyo-0002UY-D8 for bitcoin-development@lists.sourceforge.net; Sat, 23 Aug 2014 13:03:38 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.50 as permitted sender) client-ip=209.85.219.50; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f50.google.com; Received: from mail-oa0-f50.google.com ([209.85.219.50]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XLAyY-0000lS-8b for bitcoin-development@lists.sourceforge.net; Sat, 23 Aug 2014 13:03:38 +0000 Received: by mail-oa0-f50.google.com with SMTP id g18so9475172oah.37 for ; Sat, 23 Aug 2014 06:03:05 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.19.135 with SMTP id f7mr10704460obe.40.1408798985802; Sat, 23 Aug 2014 06:03:05 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.82.34 with HTTP; Sat, 23 Aug 2014 06:03:05 -0700 (PDT) In-Reply-To: <20140823115321.AC158E07036@quidecco.de> References: <20140820125901.CB71CE043A5@quidecco.de> <20140823115321.AC158E07036@quidecco.de> Date: Sat, 23 Aug 2014 15:03:05 +0200 X-Google-Sender-Auth: xQ-gDi8WRaxmT3q7U0RMjWqK1e8 Message-ID: From: Mike Hearn To: Isidor Zeuner Content-Type: multipart/alternative; boundary=001a11c299661bded805014b93d9 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 0.0 TIME_LIMIT_EXCEEDED Exceeded time limit / deadline X-Headers-End: 1XLAyY-0000lS-8b Cc: Bitcoin Dev , Ivan Pustogarov Subject: Re: [Bitcoin-development] Proposal: PoW-based throttling of addresses (was: Outbound connections rotation) 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, 23 Aug 2014 13:03:38 -0000 --001a11c299661bded805014b93d9 Content-Type: text/plain; charset=UTF-8 > > Since when? This has been a recognized approach since people called it > "hashcash" ([1] - before cryptocurrencies were even invented). > I only know of one site that worked the way you propose: TicketMaster, a long time ago. They used it as a less harsh form of blocking for IPs that they strongly suspected were bots, which is what you suggest indeed. But 99% of the hard work of that system was in scoring the connections. The actual PoW part didn't work that great because bots have much more patience than humans do. Other sites also use proofs of work, but they're CAPTCHAs i.e. human PoWs. And unfortunately those don't work very well these days either :( > To be clear, I do not propose to have _all_ clients do complicated > work. Just those using an address which has been misbehaving. Yes, I understand, but then you're back to scoring clients - the hard part - and the only question is do you slow down that client by sticking them at the bottom of a work queue or by requiring them to solve a difficult PoW. The best approach is the first one because that scales naturally .... you don't have to define some notion of misbehaviour, you just prioritise amongst clients. The current notion of "misbehaviour" is only somewhat useful. It's easy to classify reasonable behaviour as harmful and shoot yourself in the foot. We managed this at least once back in 2010 when we actually released a version of Bitcoin that interpreted a normal request to serve the block chain as a DoS attack! It couldn't serve the chain at all! Additionally many things that can be interpreted as an attack like sending a message with a bad signature can also be caused just by mistakes, or version skew during software upgrades. So it's very tricky to get this right. That's important because one quite common way big sites suffer DoS attacks is by accidentally having real users create a DoS "attack" by e.g. pushing a bad software update, or by having sudden and unexpected press-driven growth, etc. You really don't want to force users to sit around waiting and wasting battery. It's better to serve as many requests as you can up to your absolute limit and try to ensure as many of them as possible are good. > Exactly. Not every user may like to have a cookie by which an observer >> > might get the chance to even link his connection to his previous > connections, thereby allowing the discussed deanonymization technique > to get even more effective. > I doubt it matters. Any DoS attack that's powerful enough to use up most of the networks resources is probably being driven by a botnet of some kind, and *all* legitimate users will lose in an even fight against a botnet. Cookies can be somewhat anonymized. For example a cookie that is merely a signature over a timestamp of some kind (doesn't have to be an secp256k1 signature) can be normalised to the day or week. So you can prove you've been using Bitcoin for say 3 years but it doesn't pin you down precisely. This isn't perfect: attackers can and do "age" accounts before preparing for abuse. Proof of UTXO is another way to rank users. If you're richer you're presumably more important for the network to process than poor people. However you end up back at a CPU imbalance. PoW can possibly play a role here to even it out: the cost of submitting a UTXO proof should be at least equal to the cost of verifying the signature, but that is a PoW small enough that users would not notice. --001a11c299661bded805014b93d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Since when? This has been a recognized approach = since people called it
"hashcash" ([1] - before cryptocurrencies were even invented).

I only know of one site that worked the w= ay you propose: TicketMaster, a long time ago. They used it as a less harsh= form of blocking for IPs that they strongly suspected were bots, which is = what you suggest indeed. But 99% of the hard work of that system was in sco= ring the connections. The actual PoW part didn't work that great becaus= e bots have much more patience than humans do.

Other sites also use proofs of work, but they're CA= PTCHAs i.e. human PoWs. And unfortunately those don't work very well th= ese days either :(
=C2=A0
To be clear, I do not propose to have _all_ clients do complicated
work. Just those using an address which has been misbehaving.
<= div>
Yes, I understand, but then you're back to scoring c= lients - the hard part - and the only question is do you slow down that cli= ent by sticking them at the bottom of a work queue or by requiring them to = solve a difficult PoW. The best approach is the first one because that scal= es naturally .... you don't have to define some notion of misbehaviour,= you just prioritise amongst clients.=C2=A0

The current notion of "misbehaviour" is only = somewhat useful. It's easy to classify reasonable behaviour as harmful = and shoot yourself in the foot. We managed this at least once back in 2010 = when we actually released a version of Bitcoin that interpreted a normal re= quest to serve the block chain as a DoS attack! It couldn't serve the c= hain at all! Additionally many things that can be interpreted as an attack = like sending a message with a bad signature can also be caused just by mist= akes, or version skew during software upgrades. So it's very tricky to = get this right.

That's important because one quite common way big s= ites suffer DoS attacks is by accidentally having real users create a DoS &= quot;attack" by e.g. pushing a bad software update, or by having sudde= n and unexpected press-driven growth, etc. You really don't want to for= ce users to sit around waiting and wasting battery. It's better to serv= e as many requests as you can up to your absolute limit and try to ensure a= s many of them as possible are good.
=C2=A0
Exactly. Not every user may like to have a cookie by which an observer
<= /blockquote>
might get the chance to even link his connection to his previous
connections, thereby allowing the discussed deanonymization technique
to get even more effective.

I doubt it = matters. Any DoS attack that's powerful enough to use up most of the ne= tworks resources is probably being driven by a botnet of some kind, and = all legitimate users will lose in an even fight against a botnet.

Cookies can be somewhat anonymized. For example a cooki= e that is merely a signature over a timestamp of some kind (doesn't hav= e to be an secp256k1 signature) can be normalised to the day or week. So yo= u can prove you've been using Bitcoin for say 3 years but it doesn'= t pin you down precisely.

This isn't perfect: =C2=A0attackers can and do &quo= t;age" accounts before preparing for abuse. Proof of UTXO is another w= ay to rank users. If you're richer you're presumably more important= for the network to process than poor people. However you end up back at a = CPU imbalance. PoW can possibly play a role here to even it out: the cost o= f submitting a UTXO proof should be at least equal to the cost of verifying= the signature, but that is a PoW small enough that users would not notice.=
--001a11c299661bded805014b93d9--