Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CBAD48CC for ; Wed, 22 Mar 2017 00:04:33 +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 DA1E717E for ; Wed, 22 Mar 2017 00:04:32 +0000 (UTC) Received: by mail-pf0-f169.google.com with SMTP id p189so63080783pfp.1 for ; Tue, 21 Mar 2017 17:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=gtxrarxVBGCuC99pC5ea/PvBE+AoFgHf7bbh7KHGGak=; b=oLvNaahDjKAJ7v28szRJ9HIba0VivcCcSs8o4i6PtQPlHm5kkVRMOvME4NN5fa79Ff xn2ugZ8enby/cJ3NYjLYdMXXLus4VVes/Fjuo7kcVIRCacwqIOk9a/ESsmn58UlrRkMV coGwP9q9hpt6UXN4BdmUMwZXz9bbC3s8dXHKLFtEmeBKqQKTYpHuRbH7J1FtCL0zEjWT nS9ztSlBph6+z6PPK25FEVfj22CvffSeUtjXG2tuf8qx+MqQP5Xr237ehkiT9QdT6/dr 9oQnZNn1SoBUEn7rVTlI1VSUjZs4ucVr5Yon5QCHS9Nms8Yd4uOtYDE87q94/y/PUlvd nblA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=gtxrarxVBGCuC99pC5ea/PvBE+AoFgHf7bbh7KHGGak=; b=VnZe8zRgk7Ba1iDAxnKJmhE5vSQ1CBp3o22RF0QMsA0ERT7lC8UKtHtFzZtsSkLw6Y mkPyVWTLfCZMPen0J29MtGtDk73Dn/BGZhrfKGrpRKxvaPrJ+jU8Yr+hanI7Wq16ILkb 2Q5LoFrF/r++O8sG23TcwKofaGJwqj7hBdX3+qJZY4l4hi2mwD6aMWkCLLdIwFhZl/05 0wrElvJJR5V1dVEvWhWL77sedacosnjJ7/BGo3UefuccHlOahGb+2btfyoX362YwAw9d h9NUmhwH6cJ3Bpb/pyjbRP22gPuqWrY1EWPgNAGw95E+ldGePtgh4rRDMlrtUnvfYobw kJew== X-Gm-Message-State: AFeK/H0TL7t/XlXTbL5N0923ZXvBiNVzlQa8NVFQQ30MJffAMAtdZijS0pnA1uJe68dtrw== X-Received: by 10.98.95.197 with SMTP id t188mr26048051pfb.150.1490141072190; Tue, 21 Mar 2017 17:04:32 -0700 (PDT) Received: from ?IPv6:2601:600:9000:d69e:f8b5:15fb:e8cf:c9cb? ([2601:600:9000:d69e:f8b5:15fb:e8cf:c9cb]) by smtp.gmail.com with ESMTPSA id c22sm41980179pgn.43.2017.03.21.17.04.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Mar 2017 17:04:31 -0700 (PDT) References: <7c5020dd-5259-9954-7bf1-06fa98124f8f@voskuil.org> To: Bitcoin Protocol Discussion From: Eric Voskuil X-Forwarded-Message-Id: <7c5020dd-5259-9954-7bf1-06fa98124f8f@voskuil.org> Message-ID: Date: Tue, 21 Mar 2017 17:04:47 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <7c5020dd-5259-9954-7bf1-06fa98124f8f@voskuil.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 22 Mar 2017 01:06:42 +0000 Subject: Re: [bitcoin-dev] Unique node identifiers 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, 22 Mar 2017 00:04:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Reposting this response since this made it neither to distribution nor to the moderation archive. - -------- Forwarded Message -------- Subject: Re: [bitcoin-dev] Unique node identifiers Date: Wed, 8 Mar 2017 18:59:42 -0800 From: Eric Voskuil To: Pieter Wuille CC: Jonas Schnelli , Bitcoin Protocol Discussion , Libbitcoin Development On 03/08/2017 05:55 PM, Pieter Wuille wrote: > On Wed, Mar 8, 2017 at 5:16 PM, Eric Voskuil > wrote: >> On 03/08/2017 03:12 PM, Pieter Wuille wrote: >>> In that way, I see BIP150 as an extension of IP addresses, >>> except more secure against network-level attackers. If you >>> believe the concept of people establishing links along existing >>> trust lines is a problem, you should be arguing against >>> features in Bitcoin software that allows configuring preferred >>> IP addresses to connect to as well (-addnode and -connect in >>> Bitcoin Core, for example). >> >> Weak identity is insufficient to produce the problem scenario >> that is at the heart of my concern (excluding people). It is this >> "[same] except more secure" distinction that is the problem. You >> brush past that as if it did not exist. > > So you're saying that a -onlyacceptconnectionsfrom=IP option > wouldn't be a concern to you because it can't exclude people? Of > course it can exclude people - just not your ISP or a state-level > attacker. You seem to look at this from only one perspective. Put yourself on the other end of the wire (web wallets, APIs, exchanges, miners). Is an IP address strong enough for them to prove to the state that they are getting connections only from authorized "customers" that they know? Is it sufficient for them that they may think they know their customer but in reality it may be some ISP spoofing their customer (or some state)? Obviously it is not sufficient, which is why IP addresses do not produce this problem. They will need another mechanism, and BIP150 just happens to be it. > Please, Eric. I think I understand your concern, I assume you do. The question is ultimately whether the P2P protocol is an anonymous network of public information or it is a private network (of private information). Too many arguments have been based on the idea that the information is private (bloom filters, tainting). There are anonymizing networks, Bitcoin P2P is not one of them. Consensus rules exist to validate information obtained from the anonymous public. That includes your ISP and the state. The rules validate everything that matters except whether there is a stronger chain - and seeing the strongest chain cannot be guaranteed by encryption, unless of course we are all strongly tied to the majority hash power and trust them. Making the network private so that we can detect denial/disruption of service is pointless if the the only threat is your own ISP or the state . > but this argument isn't constructive either. I don't need to continue it, I've made my case. It's up to others to decide whether it has been constructive and what to do with it. I hope it is understood that I do not question the motivation of anyone involve d. > The proposal here is to introduce visible node identities on the > network. I think that's misguided as node count is irrelevant and > trivial to fake anyway. Agreed. > I know that you equate the concept of having verifiable identity > keys in the P2P with a step towards making every node > identifiable, There is no question that is a step toward making every person who connects to the more centralized network identifiable. The next step doesn't even require a software change. A "bitcoin provider" will only need to provide you a secret to use when connecting. And they have every reason to want to control this access. e -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJY0b+SAAoJEDzYwH8LXOFOzskH/Ak4xTVWuY02dpA7Xcna0/lG pLCYz5aFOoCRDokHf2uxtZptNaXMcz5eNBwhxRyXL9cMQ1ewME9nWDiM0x7Is0zC 0haiFW1bi81Tak6ELhA7+BwCQNYH4MBWirFo/T91veiaOx3Ttn5Nf8p+kYfbcvCC eANxCsPM8s9ul7CzpfDtO+K7S9rV/mEZYDsogKT7P3JPbgH4kRWcyt1AcFfw74LU Z68XkZL6aCl+nymupZR72z/oxykljjPegkZxIkoguNSybZR9dOLRRmkyiPplX+OU szOlGnwuePxOq/BQE8ouAlfSgAmBHqMj6lnYCgbBUIWrTzjYlpZVA4dWTj/FVCM= =um+z -----END PGP SIGNATURE-----