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 69D5C6C for ; Wed, 31 Aug 2016 14:29:56 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f172.google.com (mail-ua0-f172.google.com [209.85.217.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C274820A for ; Wed, 31 Aug 2016 14:29:55 +0000 (UTC) Received: by mail-ua0-f172.google.com with SMTP id l94so91568574ual.0 for ; Wed, 31 Aug 2016 07:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1RcPsDlNUCpav+Oh9jT2KsHEBzUlON1Xrn2TuhCO2og=; b=dlnTOM8Zd5sTopprPVtl4Dm/JD2Fq7edurG/MmT4Y2wDYvPEMyn+8VZuJAC9B/Ve+a f/xBDtpoWF+t7Ad2cmYNcYgwL8wKmqURLRSK1jymEuti95S9xNKgsAPZPLi5hWufRcaS 1YiHTgtHfmaQgSnixsId3Ei604zUsifVvY5bfsz6baWshcWeJSRf1B2CxCypJw81f9RJ mJtLOaCwdhiL2SHoir3i5iTBn7KIK6g/6kT9VtvD1gEtSzFfWao6dUgH3coGQG3lNX2X xrtUsg2L/f25VfANmNva3PP+kBwfTdJotY75raaAvBu3LpFixuV/CWEGdpFmj6dk2zgx bepQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1RcPsDlNUCpav+Oh9jT2KsHEBzUlON1Xrn2TuhCO2og=; b=IUtpcQUrOnb0+2mtdWHft78o0yDm9SzxzJE21wUPTCFwuethJwuQVnYH/Bfy8XNFYS z8pj7cRgiD55qTcT2RowKdsPzVtUYNLnejg1ns9q1K2tJKXcrQl26SZo2yfinrwN/bql ll0Vymi2U2tgZVYZBXxypRqUoC4ArrKjbVoEeBzBh73ebcwh9AZ4UTTTZ5uakSl6NMyP lsL7tDyIdnqClgZbwuJ0Jz+cDObPEkb96QZipmKRhUXczLWIkQ9YoknUbHzUV7SCKID7 jo3T4wJyA1hZ5NxlToDtPSFjV1HMnAWXesfH4I16JZX8ff+HA9VXwqnDlHPKt6A+CLu/ sH0w== X-Gm-Message-State: AE9vXwM7EqN3evAum+4RPcn1kBoCV+59AWvLs6V7/Cwvhm44uQG7doVq4SmNYtKL3N8B5TuQA91Z+Qn1TL8Ehw== X-Received: by 10.31.158.200 with SMTP id h191mr5831868vke.127.1472653794698; Wed, 31 Aug 2016 07:29:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.51.77 with HTTP; Wed, 31 Aug 2016 07:29:53 -0700 (PDT) In-Reply-To: <0932A659-6BE0-441F-AD05-ED846BBE7C80@voskuil.org> References: <87h9cecad5.fsf@rustcorp.com.au> <1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org> <577234A4.3030808@jonasschnelli.ch> <0932A659-6BE0-441F-AD05-ED846BBE7C80@voskuil.org> From: Pieter Wuille Date: Wed, 31 Aug 2016 16:29:53 +0200 Message-ID: To: Eric Voskuil Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_SPAM autolearn=no 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: Wed, 31 Aug 2016 14:29:56 -0000 Hello Eric, I felt like I still owed you a response to the points below. On Thu, Jun 30, 2016 at 5:10 PM, Eric Voskuil wrote: > Pieter, these are in my opinion very reasonable positions. I've made some= observations inline. > >> On Jun 30, 2016, at 3:03 PM, Pieter Wuille wro= te: >> >> On Thu, Jun 30, 2016 at 11:57 AM, Eric Voskuil via bitcoin-dev >> wrote: >>> The proliferation of node identity is my primary concern - this relates= to privacy and the security of the network. >> >> I think this is a reasonable concern. >> >> However, node identity is already being used widely, and in a very >> inadvisable way: >> * Since forever there have been lists of 'good nodes' to pass in >> addnode=3D configuration options. >> * Various people run multiple nodes in different geographic locations, >> peering with each other. >> * Various pieces of infrastructure exist that relies on connecting to >> well-behaving nodes (miner relay networks, large players peering >> directly with each other, ...) > > Yes, libbitcoin also provides these options on an IP basis. > >> * Several lightweight clients support configuring a trusted host to conn= ect to. > > I explicitly exclude client-server behavior as I believe the proper resol= ution is to isolate clients from the P2P protocol. Libbitcoin does this alr= eady. I think that's a false dichotomy. There is no reason why the P2P network consists of purely servers (full nodes) and clients (lightweight nodes). Where does a client fit that is SPV at startup, but upgrades in the background to a full node? It seems strange that such a client would use a 'client protocol' for initial connections, but the P2P protocol for syncing with history, when both come from the same peers, and transmit the same kind of information. What would make sense IMHO is a protocol split between the different kinds of transmission: 1) Historical block download 2) Block synchronization at the tip 3) Transaction relay ... (1) prefers high bandwidth, has no connectivity concerns, and does not care about latency and has no privacy concerns. (2) needs partition-resistance, low latency and has also no privacy concerns. (3) needs moderate latency, reliability of propagation and privacy. If there were to be separate protocols for these, I would argue that (3) should use opportunistic encryption always to increase transaction source privacy, and (2) and (3) need authentication when one of the peers is not fully validating. BIP 150/151 give the tools to construct these. >> Perhaps you deplore that fact, but I believe it is inevitable that diffe= rent pieces of the network will make different choices here. You can't prev= ent people from create connections along preexisting trust lines. That does= not mean that the network as a whole relies on first establishing trust ev= erywhere. > > Of course, the network operates just fine without universal trust. My con= cern is not that it is required, but that it may grow significantly and wil= l have a tendency to gravitate towards more effective registration mechanis= ms for what is a "good" peer. Even an informal but pervasive web of trust m= ay make it difficult for untrusted parties to connect. Maybe, but I'm very unconvinced that that will happen more than how today IP and DNS-based "authentication" is used already (in very inadvisable ways). >> And I do think there are advantages. >> >> BIP 151 on its own gives you opportunistic encryption. You're very right= to point out that this does not give you protection from active attackers,= and that active attacking is relatively easy through sybil attacks. I stil= l prefer my attacker to actually do that over just listening in on my conne= ction. > I agree, and I doubt this proposal will have much impact on an advanced p= ersistent threat, or even lesser threats. People should understand that the= re is both a risk and a limited benefit to this proposal. I believe the risk is only in misunderstanding what it is good for, and there significant benefits to a network that encrypts connections by default, as it excludes purely passive attackers. > I believe you have misinterpreted my comments on distributed anonymous cr= edentials (and the like) as commentary on the construction of BIP151 (and a= subsequent auth proposal). As such your observation that it is exaggerated= would make sense, but it is not what I intended. Encryption and auth are s= traightforward. Preventing bad nodes from participating in an anonymous dis= tributed system is not. Preventing bad nodes from participating is a very hard problem, if not impossible. That doesn't mean we can't improve the current situation: people are relying on node identity already, and doing so in ways that have unclear attack vectors (IP spoofing, DNS poisoning, BGP routing attacks). Adding optional and non-discoverable cryptographic identities can improve this. --=20 Pieter