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 0BB5426C for ; Thu, 30 Jun 2016 13:03:23 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com [209.85.215.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DF69E16C for ; Thu, 30 Jun 2016 13:03:21 +0000 (UTC) Received: by mail-lf0-f49.google.com with SMTP id l188so54940669lfe.2 for ; Thu, 30 Jun 2016 06:03:21 -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; bh=ROrds7l1WYDmo8CTCNuZfhPVBdSp1nipPSKkcdGfPNk=; b=EC6wLEYyhBA5/hxwJZhBgBRIIuS60xGp2z1bq7bmxUGsrW8hvWqP/bCIRc/IxbO/HM dG4Do4yQvsAYeKxTNlhuWyk3tHCIIOwD42HAyJHO2vCFRj7MG3zqxrucckTVpYLueKEN 6vmY5Ev9rCLzXtCYMutCLFdYhpjtwHzJHuQ4+cjpDcs38ETfUN3iPfOogdzJMuOYyVWT d4nPIpRX20MXs77hQaImFgu1KYW5eTjk3rWFeCopA9JvKBEhrz/QoXk71rzHFTVY2/B+ vRsYCb7vBaqUJbUjecV/xzb0sM4JfufdBzadBsi4+PWX0VXC8rpIGFJbTlRcsbJ0ct0T RpSA== 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; bh=ROrds7l1WYDmo8CTCNuZfhPVBdSp1nipPSKkcdGfPNk=; b=eSEPQN7QAj8xnxo6zxdpPWDuCmwryBBttAS1OnDAWRYy9RFzfj8bGrZZy8y8Vg57QI pxBuWW8W/T5XF/8i3pm7oYpZPtDh6VDJgr+5WOvmUvVEYQVwOeSU7lrg4N8NjtuwM3WH tpo4lRj4KcuCovYHpKokBJN/VfZMMI8qyakE//iWhcaLD6fW4IZtBBhLxwuufvR+fVxS IlSpi4D/757zqBZ/YCu5WkU6gNg7MO47NIOpBBkSIuB488WNO/WuyFTPhWadpXjjS5+V StP+KAw8lIfNYtBoMGa+LCVyxEEp6P/uVN39bJ6oy6ZXILphdei+L/ftAgc4avxNIUHo 74mQ== X-Gm-Message-State: ALyK8tIiYpPAyQC1ko7FS7X/4DbSyEHmZ5ncB0VUaXsCVwlI63G9zDTA6T7nw0EtU1TnxRtcMsIHT5vEQxt5kw== X-Received: by 10.25.40.8 with SMTP id o8mr4437383lfo.22.1467291799854; Thu, 30 Jun 2016 06:03:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.180.101 with HTTP; Thu, 30 Jun 2016 06:03:18 -0700 (PDT) In-Reply-To: References: <87h9cecad5.fsf@rustcorp.com.au> <1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org> <577234A4.3030808@jonasschnelli.ch> From: Pieter Wuille Date: Thu, 30 Jun 2016 15:03:18 +0200 Message-ID: To: Eric Voskuil , Bitcoin Protocol Discussion Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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: Thu, 30 Jun 2016 13:03:23 -0000 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= 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, ...) * Several lightweight clients support configuring a trusted host to connect to. Perhaps you deplore that fact, but I believe it is inevitable that different pieces of the network will make different choices here. You can'tg prevent people from create connections along preexisting trust lines. That does not mean that the network as a whole relies on first establishing trust everywhere. 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 still prefer my attacker to actually do that over just listening in on my connection. And yes, we should also work on improving the privacy nodes and wallets have orthogonal to encryption, but nothing will make everything perfectly private. BIP 151 plus a simple optional pre-shared-secret authentication extension can improve upon pure IP-based authentication, as well as simplify things like SSL tunnels, and onion addresses purely used as identity. This will still require explicit configuration, but not more than now. BIP 151 plus a non-leaking public key authentication scheme (where peers can query "are you the peer with pubkey X?" but don't learn anything if the answer is no) with keys specific to the IP addresses can give a TOFU-like security. Nodes already remember IP addresses they've succesfully interacted with in the past, and ban IP addresses that misbehave. Being able to tell whether a node you connect to is the same as one you've connected to before is a natural extension of this, and does not require establishing any real-world identity beyond what we're already implicitly relying on. Perhaps these use cases and their security assumptions should be spelled out more clearly in the BIP. If there is a misunderstanding, it should be clearly stated that BIP 151 is only a building block for further improvements > Secondarily I am concerned about users operating under a false assumption about the strength of privacy. This is a widespread problem, but it exists far outside the scope of this proposal. The privacy properties of Bitcoin are often misrepresented and even used as advertizements. The solution is education, not avoiding improvements because they may be misunderstood. > The complexity of the proposed construction is comparable to that of Bitcoin itself. I really think this is an exaggeration. It's a diffie-hellman handshake and a stream cipher (both very common constructions), that apply to individual connections. There are no consensus risks nor a requirement for coordinated change through the network. The cryptographic code can be directly reused from a well-known project (OpenSSH), and is very small in size. -- Pieter