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 A77C6932 for ; Thu, 9 Mar 2017 11:02:01 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7D9F414F for ; Thu, 9 Mar 2017 11:02:00 +0000 (UTC) Received: by mail-wm0-f51.google.com with SMTP id t189so52917351wmt.1 for ; Thu, 09 Mar 2017 03:02:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=fSgFuyrHKWnUgPmxgOpKW/8kQaC0+eQjBeibX+49IjY=; b=T2acPXOgAuc+Maw9aPSyu/BQeSaEeQ4g0lWpdzUQ9DgkhUtJDGfG9WZMJXDdg1gEFW 3WzdckhqZ/jLfj/hBpZRj3hmXrLpXpxG9nn8psMCfsvyiZGzfGWDfQyv8StWuezl7ZpX 4otSlu9uIvBgA5BH4Ij8xs/DlccewPcYFwMqEkJop5yhTErQ1g99PYE3yS3pZt7ImRxf gdwv+l1R5Y6FY5i/U3pkYzTA97Ro3PQvpAQQkxJlDIHYKNOFHPg9vmjZGwtfJ5Z7WKvI BlSNwFj+zGqhGU0kfyrFCccdJPxsTT4aaG7krMAUREUnTpgUaiE5ML0ih8BV6qI5m0k2 mUxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=fSgFuyrHKWnUgPmxgOpKW/8kQaC0+eQjBeibX+49IjY=; b=eUKZBmYLJ8RYeuOSZ6VTMsJ2oyzA1+g6YdBrStHyoZH83H6bio+ivPZjRfh0g8G1Gz vlWRznUWGCDQj/HL7RCah9oQHo41t/Vot3FjhL7SKiUjuoZ17EO2zsDip9BUtKi/SMlI 3Afujdf0tsYNLYYvYSc2VsFa5zMUKHPxt801zGjvjxU3gjiQD0xygu8V/SAKM5SeWK7I 53Kb5LPL4o8xjyZNhIATIdMS8oR5uI5CEHnkVEo9a71i8znJ46SM7E6PqVBpHSiS9NnY 0RnnCmVnbvrn+njYiHqTgq4odCRSBLfC1ZEs5nodpVoIb+ItFd7UrW72Kxuj1nabrMwW pdgg== X-Gm-Message-State: AMke39mghM4BDJss3eR3rMs8WBP1o/e4lyNL+oNSHdhwR1DJwa7pfqGowamox7QlkGM7Yw== X-Received: by 10.28.125.212 with SMTP id y203mr29075725wmc.90.1489057318748; Thu, 09 Mar 2017 03:01:58 -0800 (PST) Received: from [192.168.43.58] ([80.12.63.221]) by smtp.googlemail.com with ESMTPSA id p12sm7860744wrb.46.2017.03.09.03.01.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2017 03:01:57 -0800 (PST) To: bitcoin-dev@lists.linuxfoundation.org References: <30362205-D0CC-46D9-B924-EFA0A6EA1AC9@jonasschnelli.ch> <31FB94D1-5B5B-43EF-AFD8-2A7508464F7C@jonasschnelli.ch> <6a5a6a8f-d689-260a-76a9-a91f6bda56c5@voskuil.org> From: Aymeric Vitte Message-ID: <06ccf31d-c895-4b7c-fc4b-89dad30f524e@gmail.com> Date: Thu, 9 Mar 2017 12:01:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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 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: Thu, 09 Mar 2017 11:02:01 -0000 As stated in this thread and as I see it the use of BIP150 is optional, so if some parties want to trust each others and use it, then they can, if they don't like it and don't want to use it, then they don't use it Unless I misread, some statements in this thread involving the Tor network are wrong, the Tor network is a centralized network, each node (except the bridges) have a long term identity key and have to prove periodically to the authority servers that they are the owners of this key, if not the other nodes will never extend circuits to them, then they will be of course quite difficult to reach Unfortunately the original proposal starting this thread seems to be reinventing this system that probably can only lead to something centralized which cannot apply for the bitcoin network (the Tor network is centralized because the team want to control what is happening: sybils, bugs, attacks, blacklist etc) Unless some peers/nodes have decided to trust each others (BIP150) I don't think it's a good idea at all that bitcoin nodes have anything similar to long term nodeIDs (see https://gist.github.com/Ayms/aab6f8e08fef0792ab3448f542a826bf , already posted, not final, not finished, and the title does not really reflect what would be the proposal today, but it carefully avoids any possibility for a full node to have a long term ID) Le 09/03/2017 à 02:55, Pieter Wuille via bitcoin-dev a écrit : > 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. > > Please, Eric. I think I understand your concern, but this argument > isn't constructive either. > > 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. But you bringing up BIP150 here isn't useful > either. I know that you equate the concept of having verifiable > identity keys in the P2P with a step towards making every node > identifiable, but they are not the same. It's just a cryptographic > tool to keep a certain class of attackers from bypassing restrictions > that people can already make. > -- Peersm : http://www.peersm.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms