diff options
| author | Eric Voskuil <eric@voskuil.org> | 2016-06-29 01:33:53 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-06-28 23:33:57 +0000 |
| commit | 1410df83a2d09274dccae61f5e3ceb2d5e24db15 (patch) | |
| tree | 337e135ccb1e6df5aa43d0c1cbb2c92881c59596 | |
| parent | 0f4c81ea54b2719ab43a855c0942af62962601b3 (diff) | |
| download | pi-bitcoindev-1410df83a2d09274dccae61f5e3ceb2d5e24db15.tar.gz pi-bitcoindev-1410df83a2d09274dccae61f5e3ceb2d5e24db15.zip | |
Re: [bitcoin-dev] BIP 151
| -rw-r--r-- | 66/3be895059cd8c41b5009a180b5bf8bcc81b2e0 | 177 |
1 files changed, 177 insertions, 0 deletions
diff --git a/66/3be895059cd8c41b5009a180b5bf8bcc81b2e0 b/66/3be895059cd8c41b5009a180b5bf8bcc81b2e0 new file mode 100644 index 000000000..65f6568a0 --- /dev/null +++ b/66/3be895059cd8c41b5009a180b5bf8bcc81b2e0 @@ -0,0 +1,177 @@ +Return-Path: <eric@voskuil.org> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 8AAB3483 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 28 Jun 2016 23:33:56 +0000 (UTC) +Received: by mail-wm0-f43.google.com with SMTP id f126so159084880wma.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <eric@voskuil.org> +X-Mailer: iPhone Mail (13F69) +In-Reply-To: <CAAS2fgQFqHBdbym4GMAV-mdcEWR1SdGc3av0mDu65keKP9Ak6g@mail.gmail.com> +Date: Wed, 29 Jun 2016 01:33:53 +0200 +Content-Transfer-Encoding: quoted-printable +Message-Id: <AB9C1C8F-7369-42CC-8551-7E03B16D5229@voskuil.org> +References: <87h9cecad5.fsf@rustcorp.com.au> + <1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org> + <577234A4.3030808@jonasschnelli.ch> + <CAAS2fgQFqHBdbym4GMAV-mdcEWR1SdGc3av0mDu65keKP9Ak6g@mail.gmail.com> +To: Gregory Maxwell <greg@xiph.org>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <bitcoin-dev@li= +sts.linuxfoundation.org> 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= + |