summaryrefslogtreecommitdiff
path: root/f8/1692dd326180cf64a94d94b09adc006b8365f5
diff options
context:
space:
mode:
authorAymeric Vitte <vitteaymeric@gmail.com>2017-03-09 12:01:49 +0100
committerbitcoindev <bitcoindev@gnusha.org>2017-03-09 11:02:01 +0000
commitf7deaddff89f7a2174be976609f5ec751047d042 (patch)
tree9c64960a31f4e4d49f4f80012ae819bd6304abc9 /f8/1692dd326180cf64a94d94b09adc006b8365f5
parent3ca0d425c65b266e24080e709d924c6ea29223e1 (diff)
downloadpi-bitcoindev-f7deaddff89f7a2174be976609f5ec751047d042.tar.gz
pi-bitcoindev-f7deaddff89f7a2174be976609f5ec751047d042.zip
Re: [bitcoin-dev] Unique node identifiers
Diffstat (limited to 'f8/1692dd326180cf64a94d94b09adc006b8365f5')
-rw-r--r--f8/1692dd326180cf64a94d94b09adc006b8365f5145
1 files changed, 145 insertions, 0 deletions
diff --git a/f8/1692dd326180cf64a94d94b09adc006b8365f5 b/f8/1692dd326180cf64a94d94b09adc006b8365f5
new file mode 100644
index 000000000..f36f45884
--- /dev/null
+++ b/f8/1692dd326180cf64a94d94b09adc006b8365f5
@@ -0,0 +1,145 @@
+Return-Path: <vitteaymeric@gmail.com>
+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
+ [172.17.192.35])
+ by mail.linuxfoundation.org (Postfix) with ESMTPS id A77C6932
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ 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 <bitcoin-dev@lists.linuxfoundation.org>;
+ Thu, 9 Mar 2017 11:02:00 +0000 (UTC)
+Received: by mail-wm0-f51.google.com with SMTP id t189so52917351wmt.1
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ 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 <bitcoin-dev@lists.linuxfoundation.org>
+ (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: <BL2PR03MB435C5077E69D91D0A8092B6EE2A0@BL2PR03MB435.namprd03.prod.outlook.com>
+ <CADJgMzvuii8Ww822v3DRa=-Azuqo4va6s32MsNSC-6M9=stm1Q@mail.gmail.com>
+ <BL2PR03MB435029A0856DC7077D4AD68EE2D0@BL2PR03MB435.namprd03.prod.outlook.com>
+ <D4B674DB-8F2E-4AA1-B271-FEE02A62A274@voskuil.org>
+ <30362205-D0CC-46D9-B924-EFA0A6EA1AC9@jonasschnelli.ch>
+ <beed7ade-13be-3a7f-9a4e-99f77378e780@voskuil.org>
+ <31FB94D1-5B5B-43EF-AFD8-2A7508464F7C@jonasschnelli.ch>
+ <CAPg+sBhKMWVRSka+iZvLn1B94eBgrzakw73pX40XHPMH647C7A@mail.gmail.com>
+ <6a5a6a8f-d689-260a-76a9-a91f6bda56c5@voskuil.org>
+ <CAPg+sBg-ihLOi4eq6mCti=bGtbe0sWYv3ScmWoEZ8d=dHDQ5Mw@mail.gmail.com>
+From: Aymeric Vitte <vitteaymeric@gmail.com>
+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: <CAPg+sBg-ihLOi4eq6mCti=bGtbe0sWYv3ScmWoEZ8d=dHDQ5Mw@mail.gmail.com>
+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 <bitcoin-dev.lists.linuxfoundation.org>
+List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
+List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
+List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
+List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
+List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <eric@voskuil.org> 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
+
+