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 8AAB3483 for ; Tue, 28 Jun 2016 23:33:57 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 74D4216C for ; Tue, 28 Jun 2016 23:33:56 +0000 (UTC) Received: by mail-wm0-f43.google.com with SMTP id f126so159084880wma.1 for ; Tue, 28 Jun 2016 16:33:56 -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=PH+SO31nWDCCBuAwU0ge+quU82tmN8lluhy+WdxUzcU=; b=pS08vM7YyEFnKEyQkhBMF8fDFyMHBCAxyX08w+86e5nhvspIonSDAbMsybYJbXkTQw 59rlQaWUJtkSwjN9GEHk3xq6s7KwWCWkzpJcKkbfzS3kHTpHuYg+mGKPgk6osYSB/+bm KR97yUYIAQfy91W3Vst5EYOMRWnPWWm7olVAPqio8lgSojlslRZ7cPZSf/QIlzax1per QcxrRO40IxVtpUY0u6vbT2XfUL2MIrn+w0wasOiUXIWqX5V6x475SnZLFeVp5NyGucM3 9ANYafAOgYdNXiVa48apeTtCKfcWpUa3PY29rEg0V4+hDDsa1YcCgPcTq6aaC7IbrFsk Nbew== 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=PH+SO31nWDCCBuAwU0ge+quU82tmN8lluhy+WdxUzcU=; b=B19kaXcdnGit8IXG9IrBsG0PmvlQa+Rcj/XpI6ibrYApmqXwsl0iC3wT6nhH7HK6t/ FD7zGtGuAgbCR9YgC+Y8y+/A7QJCGep1ycmJBPgFa8R1JAD0s1OkSP5C5ukLDZUhdfhg IXtXCduc+vFVnWiRcDSqTvzYo0Drmnfu1LCy0B5PAyp+2Wab6jUHAeUgZrk44pyAVFO6 3xKW3QeCFAYf0W7u2/fxbk0mWxOfgmFW+k8wmv67SeKt3CkX7FoOAkEYna8bPansMPaa nrSBG66JbpiChbhiYove/r+TNOWLH20WZohLWLpvKzvgnGPLoaGwLUKh2uHei+0ulgnh +CcA== X-Gm-Message-State: ALyK8tKRM1be6axPniPdc9pCdBytNCboeBVGegNdMr3Wm5kuMvXhDVpbU0sVwYtdle8UdA== X-Received: by 10.28.140.202 with SMTP id o193mr19538026wmd.55.1467156835144; Tue, 28 Jun 2016 16:33:55 -0700 (PDT) Received: from [10.114.7.71] ([41.33.219.246]) by smtp.gmail.com with ESMTPSA id a4sm664440wjq.40.2016.06.28.16.33.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 28 Jun 2016 16:33:54 -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: Wed, 29 Jun 2016 01:33:53 +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 , Bitcoin Protocol Discussion 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 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: Tue, 28 Jun 2016 23:33:57 -0000 On Jun 28, 2016, at 9:55 PM, Gregory Maxwell via bitcoin-dev wrote: >> I understand the use, when coupled with a yet-to-be-devised identity syst= em, with Bloom filter features. Yet these features >=20 > This is a bit of a strawman, you've selected a single narrow usecase which= isn't proposed by the BIP and then argue it is worthless. I agree that exam= ple doesn't have much value (and I believe that > eventually the BIP37 bloom filters should be removed from the protocol). I don't follow this comment. The BIP aims quite clearly at "SPV" wallets as i= ts justifying scenario. > Without something like BIP151 network participants cannot have privacy for= the transactions they originate within the protocol against network observe= rs. And they won't get it with BIP151 either. Being a peer is easier than observ= ing the network. If one can observe the encrypted traffic one can certainly u= se a timing attack to determine what the node has sent. > Even if, through some extraordinary effort, their own first hop is encrypt= ed, unencrypted later hops would rapidly > expose significant information about transaction origins in the network. As will remain the case until all connections are encrypted and authenticate= d, and all participants are known to be good guys. Starting to sound like PK= I? > Without something like BIP151 authenticated links are not possible, so > manually curated links (addnode/connect) cannot be counted on to provide p= rotection against partitioning sybils. If we trust the manual links we don't need/want the other links. In fact ret= aining the other links enables the attack you described above. Of course the= re is no need to worry about Sybil attacks when all of your peers are authen= ticated. But again, let us not ignore the problems of requiring all peers on= the network be authenticated. > Along the way BIP151 appears that it will actually make the protocol faste= r. >=20 >> Given that the BIP relies on identity >=20 > This is untrue. The proposal is an ephemerally keyed opportunistic > encryption system. The privacy against a network observer does not depend o= n authentication, much less "identity". And when used with authentication a= t all it makes interception strongly detectable after the fact. Maybe I was insufficiently explicit. By "relies on identity" I meant that th= e BIP is not effective without it. I did not mean to imply that the BIP itse= lf implements an identity scheme. I thought this was clear from the context.= >> The BIP does not [...] contemplate the significant problems associated wi= th key distribution in any identity system >=20 > Because it does not propose any "identity system" or authorization (also, I= object to your apparent characterization of authentication as as an 'identi= ty system'-- do you also call Bitcoin addresses an identity system?). Please read more carefully what I wrote. I did not characterize authenticati= on as an identity system. I proposed that key distribution has significant p= roblems, and used identity systems as an example of systems with such proble= ms. I could just have easily written "authentication systems", (and probably= should have). > That said, manually maintaining adds nodes to your own and somewhat truste= d nodes is a recommend best practice for miners and other high value systems= which is rendered much less effective due to a lack of > authentication, there is no significant key distribution problem in that c= ase This is the only legitimate scenario that I am aware of. Doing this by IP ad= dress (as we do) is weak if there is no VPN. Yet this scenario is very different than general authentication. This scenar= io is a set of nodes that is essentially a single logical node from the pers= pective of the Bitcoin security model. One entity controls the validation ru= les, or is collaborating with another entity to do so. My concern is that a general authentication requirement expands this single l= ogical node and gives control over if to the entity that controls key distri= bution - the hard problem that hasn't been addressed. If there is no such entity restricting access to the network (which hopefull= y we can assume) then there is no reason to expect any effective improvement= , since nodes will necessarily have to connect with anonymous peers. Anyone w= ith a node and the ability to monitor traffic should remain very effective. > and I expect the future auth BIP (Jonas had one before, but it was put asi= de for now to first focus on the link layer encryption) > to address that case quite well. Defining an auth implementation is not a hard problem, nor is it the concern= I have raised. e=