From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 To: Mike Hearn Content-Type: text/plain; charset=UTF-8; format=flowed References: <20140820125901.CB71CE043A5@quidecco.de> In-Reply-To: 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 , 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: 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