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 072A0258 for ; Wed, 8 Mar 2017 02:01:30 +0000 (UTC) X-Greylist: delayed 00:05:43 by SQLgrey-1.7.6 Received: from cock.li (cock.li [185.100.85.212]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DDC8290 for ; Wed, 8 Mar 2017 02:01:28 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU autolearn=ham version=3.3.1 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cock.lu; s=mail; t=1488938486; bh=x85NMjm1R/JyPf1gEv40xbv9qUxNv8+cDEefVz4evbY=; h=Date:From:To:Subject:In-Reply-To:References:From; b=dc42NPoQp1bH7NquNGkwOjvFvTAzahwYcDS4Ro05MWlaKpJxuxHBgzFnb2fKg2nA7 JNRqssUPqiXqSyDqL3pjanMNwGoKjH4AUqA8BlceUaqlQWU089e9OByHosn7Ay6j66 fTTrNZgbIjwoltL2mvdo0zthQNyHk1s/wUVJ9XlHEUsQBI0F9ocX8EoP5xDqF+qi0H IPqN19vbIawsiDJrzpTh1DQ22U/DsbD0z6x4u1lyXq+Cufkc8J0nilQrYdrhnJcr70 UUJCChNDL98vQLVlG74PqBKiSUUMxJSPSYOMY/nIXpRTf5x0zPDlz6NevQdmJJwzgs E+b6hpXlVxdAQ== Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 08 Mar 2017 13:01:26 +1100 From: bfd@cock.lu To: bitcoin-dev@lists.linuxfoundation.org In-Reply-To: References: Message-ID: <8fdd4680b4ff714cc100236e73fb03f3@cock.lu> X-Sender: bfd@cock.lu User-Agent: Roundcube Webmail/1.2.3 X-Mailman-Approved-At: Wed, 08 Mar 2017 02:37:53 +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, 08 Mar 2017 02:01:30 -0000 >> I feel you're conflating social identifiability with technical >> identifiability. Sure, a node operator must always be able to remain >> anonymous, but nodes themselves require a certain level of >> identifiability otherwise there would be no means to communicate >> between them. Nodes running through networks like cjdns, onion, and i2p can effectively communicate with no knowledge of the counterparty whatsoever. Bitcoin does make an assumption that you are connected to at least one non-partitioned peer, and that there is a cost in having a large number of sybil nodes in many different ranges. Nothing says you have to do your communication exclusively on one network or another, so long as you have *some* source of information which is not partitioned. On 2017-03-08 05:44, Eric Voskuil via bitcoin-dev wrote: > On Mar 5, 2017, at 5:57 AM, John Hardy via bitcoin-dev > wrote: > >>> Nodes are by design not supposed to be identifiable in any way > > This is of course my objection to BIP150 ("a way for peers to ... > guarantee node ownership"). > >> I feel you're conflating social identifiability with technical >> identifiability. Sure, a node operator must always be able to remain >> anonymous, but nodes themselves require a certain level of >> identifiability otherwise there would be no means to communicate >> between them. > > Anonymous node identity is pointless, and is why I object to BIP151. > It provides no actual security/privacy benefit and is a stepping stone > to non-anonymous node identity (e.g. BIP150). > >> I agree that absolute node counts have their limitations, but that >> doesn't stop them being used as a measure and even propaganda tool. >> If something like this is a way to help highlight the latter when it >> is occurring I think it has value. I 'm not convinced that node >> identifiers or identity persistence would have any meaningful impact >> on privacy, though am open to being convinced otherwise. > > Bitcoin does not require node counts, and this proposal is redundant > with BIP150. > > e > >> ------------------------- >> >> FROM: Btc Drak >> SENT: Sunday, March 5, 2017 1:27 PM >> TO: John Hardy; Bitcoin Protocol Discussion >> SUBJECT: Re: [bitcoin-dev] Unique node identifiers >> >> Nodes are by design not supposed to be identifiable in any way, >> including persisting identities across IPs changes or when >> connecting over different networks (e.g. clearnet/tor). Anything >> that makes Bitcoin less private is a step backwards. Also absolute >> node count is pretty meaningless since only fully validating nodes >> that participate in economic activity really matter. >> >> As a side note, this should probably have started out as a >> bitcoin-discuss post. >> >> On Sat, Mar 4, 2017 at 4:04 PM, John Hardy via bitcoin-dev >> wrote: >> >>> The discussion of UASF got me thinking about whether such a method >>> might lead to sybil attacks, with new nodes created purely to >>> inflate the node count for a particular implementation in an >>> attempt at social engineering. >>> I had an idea for an anonymous, opt-in, unique node identification >>> mechanism to help counter this. >>> This would give every node the opportunity to create a node >>> ‘address’/unique identifier. This could even come in the form >>> of a Bitcoin address. >>> The node on first installation generates and backs up a private >>> key. The corresponding public key becomes that node’s unique >>> identifier. If the node switches to a new software version or a >>> new IP, the identifier can remain constant if the node operator >>> chooses. >>> Asking a node for its identifier can be done by sending a message >>> the command ‘identify’ and a challenge. The node can then >>> respond with its unique identifier and a signature for the >>> challenge to prove it. The node can also include what software it >>> is running and sign this information so it can be verified as >>> legitimate by third parties. >>> Why would we do this? >>> Well, it adds a small but very useful piece of data when compiling >>> lists of active nodes. >>> Any register of active nodes can have a record of when a node >>> identifier was “first seen”, and how many IPs the same >>> identifier has broadcast from. Also, crucially, we could see what >>> software the node operator has been seen running historically. >>> This information would make it easy to identify patterns. For >>> example if a huge new group of nodes appeared on the network with >>> no history for their identifier they could likely be dismissed as >>> sybil attacks. If a huge number of nodes that had been reporting >>> as Bitcoin Core for an extended period of time started switching >>> to a rival implementation, this would add credibility but not >>> certainty (keys could be traded), that the shift was more organic. >>> >>> This would be trivial to implement, is (to me?) non-controversial, >>> and would give a way for a node to link itself to a >>> pseudo-anonymous identity, but with the freedom to opt-out at any >>> time. >>> Keen to hear any thoughts? >>> Thanks, >>> John Hardy >>> >>> john@seebitcoin.com >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1] > >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > Links: > ------ > [1] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev