path: root/14/cec8ca06cd2053ff58481cf62d616ca003acf9

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 <cryptocurrencies@quidecco.de>) id 1Xtplt-0004YK-91
	for bitcoin-development@lists.sourceforge.net;
	Thu, 27 Nov 2014 03:29:33 +0000
X-ACL-Warn: 
Received: from quidecco.de ([81.169.136.15])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1Xtplr-0003oZ-5G
	for bitcoin-development@lists.sourceforge.net;
	Thu, 27 Nov 2014 03:29:33 +0000
Received: from localhost (localhost [127.0.0.1])
	by quidecco.de (Postfix) with SMTP id 2D4D4E1FC1A;
	Thu, 27 Nov 2014 04:29:24 +0100 (CET)
From: Isidor Zeuner <cryptocurrencies@quidecco.de>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
References: <CANEZrP1RzLmSB74xdFZbePAE9nxjR-_hSCGQhNH81vRKSji2AQ@mail.gmail.com>
	<20140820125901.CB71CE043A5@quidecco.de>
In-Reply-To: <CANEZrP1RzLmSB74xdFZbePAE9nxjR-_hSCGQhNH81vRKSji2AQ@mail.gmail.com>
Message-Id: <20141127032924.2D4D4E1FC1A@quidecco.de>
Date: Thu, 27 Nov 2014 04:29:24 +0100 (CET)
X-Spam-Score: -0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
X-Headers-End: 1Xtplr-0003oZ-5G
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Ivan Pustogarov <ivan.pustogarov@uni.lu>
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: <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: Thu, 27 Nov 2014 03:29:33 -0000

Hi Mike,

thanks for your assessment.

Please find my replies in-line:
> DKIM is hardly a PoW; signing is cheap and gets cheaper all the
> time. I used to work in the email business and big bulk mailers all spent
> far more CPU time on other aspects of their business, the overhead of
> DKIM is irrelevant.
>

Well, as long as bulk mailing companies run around investing into
per-destination DKIM toggling, stating that they want to cut down CPU
usage due to crypto processing, I tend to believe that it can have an
important impact depending on the setup. Of course, I cannot rule out
the possibility that they would be better off investing into profiling
CPU usage, and/or exploring a higher ROI possibly coming from using
more CPU time on other processing. I see no point neglecting an issue
just because there are business models where it is irrelevant,
though.

> PoW didn't work in the anti spam world because it (amongst other
> problems) mixes up bulk mail and spam, which are not the same
> thing. Very common conceptual error though.
>

I did not say so, either. But bulk mailing and e-mail spam are not
orthogonal with respect to the technical characteristics that make
them possible. And nor are DKIM and PoW/hash-cash fully orthogonal.

I like the objections you raised. Avoiding DKIM because of the CPU
costs involved might be as groundless as stating "we don't use
HTTPS in order to save CPU time". Still, these substantiations can be
found in the wild, and they won't disappear because we discuss
them here on a theoretical level.

If you assume conceptual errors, though, I would suggest we discuss
the e-mail topic off-list, though. I simplify things a bit in order to
not bore the group with too much text about non-Bitcoin stuff, but
this does not mean that I'm not familiar with, or am not open for
discussing the subtle differences of different approaches that have
been researched in the e-mail business.

>
>> humans also don't care if their patience is put to the test by
>> having to wait until one Tor exit node is finally unbanned, or by
>> waiting for the connection PoW to finish because it temporarily got
>> harder due to an attack.
>>
>
> They don't? This is news to me. Humans always care. One of the
> surest ways to hurt your online business is to have a slow website
> because lots of users will give up rather than tolerate a few seconds
> of latency. At Google we actually had formulas that could relate a
> change in web search latency to revenue impact.
>

You might want to re-read my statement more carefully. I did not say
they don't care about delays, but I do say that they don't
care where the delays come from.

It is a known fact that Google will also penalize web sites which have
high latencies, so the top results appear as being also of technical
quality. But neither the users nor Google will care if the web site is
slow because the site owner did not allocate proper resources for
running the frontend quickly, or if the database server is making
things slow.

> So humans very much care! I actually doubt that any reasonable
> mobile wallet will use the new Tor support bitcoinj by default, for
> example, because it imposes quite some startup cost when the
> downloaded consensus isn't fresh, and slow startup is painful. It
> could be optimised but nobody has done that. For long running desktop
> wallets where startup time can be amortised over hours or days, I
> guess it makes more sense.
>

I agree that improving on the performance of the consensus
bootstrapping logic is an interesting topic.

> I agree that PoW tokens might make sense as a last resort if nodes
> can't even put a connection at the bottom of a priority queue and
> you're right that it may be a useful tool in a shared
> toolbox. However if we reach the point where users are all being PoWd
> then we're already pretty hosed and it's probably close to
> game over :(
>

I don't think this was ever about _all_ IPs suffering from DoS
measures. But I do think that Bitcoin will already suffer if we get to
a point where it is practically useless when being used over Tor, or
where this is only possible by immediately sacrificing the privacy
improvement Tor introduces.

>> I'd say, better have a few Tor-based users realize that they
>> should look for a fixed update because their client has to do PoW
>> for connecting, rather than having all Tor-based users locked out.
>>
>
> I think Tor is a separate issue. If an attacker wants to either
> force all users off Tor, or force them via a handful of exits, then
> this attack is quite detectable already and wallets could already
> decide to simply give up on Tor at that point automatically. No PoW
> needed. Well, ideally, nodes would disconnect a banned IP with some
> kind of notice saying why it was banned, but that's a small
> improvement.
>

I fully agree. A ban notice could also make it easier to track down
DoS handling issues triggered by incompatible updates, and possibly
make it harder for someone to issue bans for malicious reasons without
being noticed. Also, I see it as an important step towards a modern
security policy, because it would emphasize that the Bitcoin network
can be kept secure with minimum obscurity.

>> Still, users should be notified that something is unusual.
>>
>
> If we're talking mainstream success then users by and large do
> not care about technical mumbo jumbo like peer to peer networks or Tor
> ("that's the thing drug dealers and pedos use???"). They just want
> the damn thing to work reliably. So notifying them is unhelpful -
> it's not actionable. They would just see a message like
>
>    "The wizzle sprocket is kaput - keep working? YES NO"
>
> and then everyone presses yes.
>

As you say, the mainstream user won't care about technical mumbo
jumbo like Tor, so he won't be likely to run Bitcoin over Tor. So,
the most likely cases where he would encounter the notification would
be:

* incompatible update

* his machine / network is compromised and connects to Bitcoin,
  triggering DoS measures

In both cases, he would consider it as important to take action, so
even a scary notification might be the way to go.

The non-mainstream user who is willing to dive into the technical
details of running Bitcoin over Tor securely will generally be more
likely to be able to make more differentiated decisions about such an
anomaly, but I cannot see why we would want him to not have proper
tools to deal with the situation, or not to be informed about
something unusual happening.

> Stuff like Tor plays well in the crypto community but it's very
> hard to actually switch on by default, because it needs to have absolutely
> no cost at all, otherwise you'll just annoy the vast majority who
> don't want to pay for very abstract and hard to quantify privacy
> benefits.
>

Agreed. But as outlined above, those who enable it on purpose will
benefit, and those who don't also don't have a
disadvantage. Am I missing something?

> So I think it's worth considering the DoS problem and Tor
> somewhat separately, even though they're related. The solution to
> a crafty privacy-attacking DoS that tries to make exits useless is
> don't use Tor at all. The solution to "the entire Bitcoin network
> is under attack" is much harder.

Indeed. For the issues we're seeing, Tor can actually be regarded
to be at fault to some extent. So the Tor development might also
benefit from these things being researched. But I see no reason to
sacrifice the possibility to use Tor on Bitcoin properly at this
point.

I also agree that a solution which improves the situation of Tor nodes
must not make it easier to attack the entire Bitcoin network. I'm
just not seeing why this would be the case for the approach I
outlined. I actually think that having multiple values to tune in
order to throttle unwanted behaviour on the network might even improve
on Bitcoin's robustness as a whole, because it might enable better
targeted moves against other (non-Tor-related) threats. How do we know
if the most dangerous attacker Bitcoin will face has more resources
with respect to IP addresses, or CPU time?

> It's unclear to me we can ever
> solve it convincingly - banks don't connect together using private
> networks in which anonymity is forbidden because they're
> stupid. They do it because it solves DoS attacks in one solid move and
> they feel it's worth the high cost.

Well, banks did not even consider inventing something like Bitcoin
because what they have works well enough for their purposes. Still,
for some reasons, there are a lot of people interested in Bitcoin. I
would argue that it is because it tried to solve some things private
banking networks did not, so we might consider not only keeping
Bitcoin attractive for those who consider it as a badly implemented
form of what banking networks already provide.

Kind regards,

Isidor