From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A96FD26C for ; Thu, 30 Jun 2016 09:57:11 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf0-f169.google.com (mail-pf0-f169.google.com [209.85.192.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F2276196 for ; Thu, 30 Jun 2016 09:57:07 +0000 (UTC) Received: by mail-pf0-f169.google.com with SMTP id h14so27939269pfe.1 for ; Thu, 30 Jun 2016 02:57:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rwjN3JTNpKIJYTo1Ldtqn0xjs4CWFC8XWLAVkC7g288=; b=K8NIhn+6MqmrRZRJ6TkOVesNJasuaCBxCgVJSP3ZD0HiPLqiHg6QJQBNOdpQB1G+ZH d1QHoqB+QiuBTgZRLwcTlinWZt4svZwdN94KjdO2R8twMs/yGNSemwnD5/rDeTR4aSWL s7O8nCdgE/PKvia5pQTrYh70ktVHemOw06I2WFNlgA69+Nvi/OFrRRNhTn4r+XpcNceV YF2xT7tfPbMBHXEqpiAFN+B5ur/BMcsPrRid1pl+3oYglbMtwNS0FUu8Gy7glRqxivfl nQJ632ENDm/3hsDSHp0cQzpN63MDwTTG90d5Smoyfi4QksY1m9DDLbiWHl1+QPAteS2a 5B2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rwjN3JTNpKIJYTo1Ldtqn0xjs4CWFC8XWLAVkC7g288=; b=WUqgB6PmuiPxaQNWrbNIKnH8xIp9vY5Mv0XMn8Av/B0GSk3nvJMLa04xGz07/PNLc+ 9VBJU68p2JJjcu0+Pdm2LDMeP8vVaLghLpAGzCTzflFomHzqdAwN1PTyiSJtZJ5McgtA /Oq1J80q8FX22HSjmaFJjHFtgu1jGLsp6vejdwebTiIs6VjXsbph6aQe4arGIIkz59nf SM2Q+9lQ+ABygKxV1zKW3qA3yPpFDWE88M55o21AN2hwECszKIZJQno6/OiB+JSVxSHY yPZmC0+UwaujuFH22cctbKndF4a1DUi/QkvFUIJVJ7KvcFeD8AKr3gbhrbBjaj0Bxn6n bMnA== X-Gm-Message-State: ALyK8tIW6wwmP6lMpIzu76jSiU0FZyyCYkcsLy/XyP5oA25exUNWo1VksVbh7FTRzaGKjw== X-Received: by 10.98.102.66 with SMTP id a63mr19769419pfc.32.1467280627495; Thu, 30 Jun 2016 02:57:07 -0700 (PDT) Received: from [10.171.23.222] ([166.170.43.16]) by smtp.gmail.com with ESMTPSA id 75sm4194038pfy.32.2016.06.30.02.57.05 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 30 Jun 2016 02:57:06 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Eric Voskuil X-Mailer: iPhone Mail (13F69) In-Reply-To: Date: Thu, 30 Jun 2016 11:57:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87h9cecad5.fsf@rustcorp.com.au> <1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org> <577234A4.3030808@jonasschnelli.ch> To: Gregory Maxwell X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, MIME_QP_LONG_LINE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] BIP 151 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 09:57:11 -0000 On Jun 29, 2016, at 3:01 AM, Gregory Maxwell wrote: >=20 >> On Tue, Jun 28, 2016 at 11:33 PM, Eric Voskuil wrote: >> I don't follow this comment. The BIP aims quite clearly at "SPV" wallets a= s its justifying scenario. >=20 > It cites SPV as an example, doesn't mention bloom filters.. and sure-- sou= nds like the bip text should make the "MOTIVATION: The Bitcoin network does not encrypt communication between peers today. This= opens up security issues (eg: traffic manipulation by others) and allows fo= r mass surveillance / analysis of bitcoin users. Mostly this is negligible b= ecause of the nature of Bitcoins trust model, however for SPV nodes this can= have significant privacy impacts [1] and could reduce the censorship-resist= ance of a peer." This is not an example, this is the exception that is described as "signific= ant" in comparison to the other issues, which are described as "negligible".= The Bloom filters messages are of course the unique aspects of the protocol a= s it pertains to "SPV". The RISKS section declares that the BIP cannot prevent MITM attacks and that= "identity authentication" will be defined in a forthcoming BIP. The obvious implication (accepted by the author) is that authentication is r= equired to prevent a MITM attack, and furthermore establishment of identity w= ill be required to ensure that the authenticated party is not a bad actor. >>> Without something like BIP151 network participants cannot have privacy f= or the transactions they originate within the protocol against network obser= vers. >>=20 >> And they won't get it with BIP151 either. Being a peer is easier than obs= erving the network. >=20 > Not passively, undetectable, and against thousands of users at once at low= cost. This is a straw man, as the BIP does not state that its objective is to mode= rately raise the cost of passive attack against large numbers of users. It is also a red herring, as passivity is not itself a benefit. It implies t= hat the attack is easier and therefore less costly. But a trivial active att= ack may be a larger security problem than a complex passive attack. Attacks a= gainst privacy under this BIP (and with authentication) can be carried out b= y passively monitoring traffic and operating one or more nodes. Operating a n= ode may be considered "active" because the node communicates, but technicall= y it is not. In either case the activeness itself hardly raises the difficul= ty, especially for a global (thousands of users) passive attacker. Depending on the attacker, cost may not be an issue at all, so raising it ca= n have zero effect. Certainly we are not talking about prohibitive (cryptogr= aphically hard) cost. Raising the cost *any* amount is not likely a reasonab= le cost-benefit tradeoff. Privacy attacks would remain entirely undetectable under this proposal, and u= nder any additional proposal that required authentication in the absence of i= dentity. Only with all users of the network identified as "good" would such p= roposals be effective. Until that point any bad actors can become an integra= l part of the network. I will investigate the question of identity in a foll= ow-up to an independent post. >> If one can observe the encrypted traffic one can certainly use a timing a= ttack to determine what the node has sent. >=20 > Not against Bitcoin Core, transactions are batched and relayed in > sorted order. (obviously there are limits at what this provides; > ironically, the lack of link encryption has been used to argue against > privacy preserving relay behavior) It cannot be both impossible ("not against Bitcoin Core") and limited in eff= ectiveness ("obviously there are limits"). We should be clear at this point that the transaction-posting security provi= ded against a privacy attack, based on the assumption of "good" (identified)= peers in the first few hops, derives entirely from the ability of the good p= eers to break the timing attack, which is itself "limited". This is a compound pair of weak assumptions, that to be made stronger will r= equire widespread use of identity (not just authentication). The proliferation of node identity is my primary concern - this relates to p= rivacy and the security of the network. Secondarily I am concerned about use= rs operating under a false assumption about the strength of privacy. Thirdly= I am concerned about the risk of vulnerability introduced by the integratio= n into the P2P network layer of an totally new network security scheme. Four= thly I'm concerned about the cost of the above based on the belief that the b= enefit may not be material and that it may lead to increased centralization.= >>> Even if, through some extraordinary effort, their own first hop is encry= pted, unencrypted later hops would rapidly >>> expose significant information about transaction origins in the network.= >>=20 >> As will remain the case until all connections are encrypted and authentic= ated, and all participants are known to be good guys. Starting to sound like= PKI? >=20 > Huh? The first and subsequent hops obscures the origin and timing. Described as "limited" in effectiveness, and clearly useful only if these ho= ps are not attacker nodes. So back to my comment on how we maintain a pool of "good" nodes for people t= o connect to, and raising the question of how effective is this strategy (wh= ich is itself unspecified and so cannot be assumed to even exist in the cont= ext of the BIP). >>> Without something like BIP151 authenticated links are not possible, so >>> manually curated links (addnode/connect) cannot be counted on to provide= protection against partitioning sybils. >>=20 >> If we trust the manual links we don't need/want the other links. In fact r= etaining the other links enables the attack you described above. Of course t= here is no need to worry about Sybil attacks when all of your peers are auth= enticated. But again, let us not ignore the problems of requiring all peers o= n the network be authenticated. >=20 > Don't need and want them for what? For _partitioning_ resistance, > you are not partitioned if you have one honest connection to the > functional network. Additional peers purely reduce your partition vulnerab= ility-- so long as an active network attacker isn't > intercepting all your connections out. Don't want them as peers for the purpose of tx relay. As I said this, "enabl= es the attack you described above." > For privacy, you have improve transaction privacy so long as your > transaction isn't initially relayed to a malicious peer-- but > malicious peers can lie further out because transit nodes obscure the > order of message creation. Bitcoin Core currently relays transactions > first and more frequently to outbound and whitelisted peers. This whitelisting is simply a stand-in for a more formal identity system. On= e doesn't whitelist anonymous peers, one whitelists peers controlled by trus= ted parties. Preferring trusted peers is another aspect of trying to break t= he timing attack. So I would lump this under the same analysis as above (bat= ching). >> Maybe I was insufficiently explicit. By "relies on identity" I meant that= the BIP is not effective without it. I did not mean to imply that the BIP i= tself implements an identity scheme. I thought this was clear from the conte= xt. >=20 > I understood that, but my point was that Bitcoin cannot be used at all_unl= ess users have secure communication channels to share addresses. This is true but not relevant. The parties with whom we transact are not in t= he same space as the nodes with which we connect. The fact that I am face-to= -face with a counterparty does not help me find a "good" node, nor does my a= bility to PGP email a payment address or to send a stealth address in the cl= ear. But the fact that you raise this point is itself instructive. The solution t= hat was devised to resolve the problem of verifying that a counterparty is w= ho one thinks it is ended up being based on the use of certificate authoriti= es - despite the fact the the BIP did not require this. Some people consider= this extremely dangerous for Bitcoin, enough so that Peter Todd recently pr= oposed scrapping the BIP. It's not clear to me how the Bitcoin community intends to establish what nod= es are good nodes. But one thing is certain, any anonymous node may be an un= detectable attacker. >> then there is no reason to expect any effective improvement, since nodes w= ill necessarily have to connect with anonymous peers. >=20 > They're not required to _only_ connect with anonymous peers. And partition= resistance requires that you have any one good link. As a minimum requirement, it implies that only need only to connect to one o= r more "good" peers. Anonymous peers are gravy for partition resistance, yet= they are potential attackers for tx tainting. In other words the logical to= pology is to only connect to good peers. That is a problem. >> Anyone with a node and the ability to monitor traffic should remain very e= ffective. >=20 > Not via passive observation. See above commentary on the irrelevance of this distinction. >> Defining an auth implementation is not a hard problem, nor is it the conc= ern I have raised. >=20 > Glad you agree. I don't get your point here. It seems like you are just trying to antagonize= . > We seem to be looping now. Feel free to not implement this proposal, At this point I think it's fair for me to say that nobody needs your permiss= ion. > no one suggests making it mandatory. Have you ever debated an optional feature proposal? e=