summaryrefslogtreecommitdiff
path: root/16
diff options
context:
space:
mode:
authorNick ODell <nickodell@gmail.com>2016-06-28 18:06:41 -0600
committerbitcoindev <bitcoindev@gnusha.org>2016-06-29 00:06:43 +0000
commit5fb93b2f653b9fb31075d839949739738231408c (patch)
treeeb2811c925eeab87dbaee611f9fc39be4b9749eb /16
parent98fb54c6bbba35177c32cd95f3666e41b81f4d47 (diff)
downloadpi-bitcoindev-5fb93b2f653b9fb31075d839949739738231408c.tar.gz
pi-bitcoindev-5fb93b2f653b9fb31075d839949739738231408c.zip
Re: [bitcoin-dev] BIP 151
Diffstat (limited to '16')
-rw-r--r--16/3f375f64b417c0bb94166ac983f2cc0cfeb250204
1 files changed, 204 insertions, 0 deletions
diff --git a/16/3f375f64b417c0bb94166ac983f2cc0cfeb250 b/16/3f375f64b417c0bb94166ac983f2cc0cfeb250
new file mode 100644
index 000000000..c38b646a7
--- /dev/null
+++ b/16/3f375f64b417c0bb94166ac983f2cc0cfeb250
@@ -0,0 +1,204 @@
+Return-Path: <nickodell@gmail.com>
+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
+ [172.17.192.35])
+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 39ADDA55
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 29 Jun 2016 00:06:43 +0000 (UTC)
+X-Greylist: whitelisted by SQLgrey-1.7.6
+Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com
+ [209.85.214.177])
+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9119319B
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 29 Jun 2016 00:06:42 +0000 (UTC)
+Received: by mail-ob0-f177.google.com with SMTP id xn17so3474945obc.0
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Tue, 28 Jun 2016 17:06:42 -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;
+ bh=2VFw/RsuoZpzBdOaOuI6B4TJTnfWyju9pz4L8cnk3wI=;
+ b=hZvs430K30QdE7X55udG4AaVimNQZf/B8B4slbd7dwoKZlWHAstDcC8MVLSCotLvw9
+ EnF92TSaE+jQn1uci18SDaA2cS+h4sz2AX3MBYcz2Oxgg4iUupkHuAxlGzSjwvBTLI/h
+ JCqfSvRq1vjQIF96GRa9FUfI7d0nn+bfje/f4JXRc3wyaYFaaS8ZgfyZYvwv8m6SqtiK
+ eEWNYnTz+LMZZeqxDrWUyPOYqh0afXSfs9AoF3G6FybAhzrAxhvM7J9ZTye52Mqch7E4
+ T66thexDQjAABp1csvFT25nhlpcvDa5QjhAnpGqN0MwFj23CRxHgbHKyDnsSDYzk2SKB
+ 6BQQ==
+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;
+ bh=2VFw/RsuoZpzBdOaOuI6B4TJTnfWyju9pz4L8cnk3wI=;
+ b=YLfWIfMU9drTufAvyNw+hXjhfQE6RUs+J5SBr5lHhU+YGdIAYDMfHdwGTtQc60z41L
+ eu9jlTs2vRSGZNhWaWPODPTx3eZQ0DsgeKXnDPI2mo5+j3oWJP5KYSKLBeUnRCJk0Mh9
+ PnKhZrRS/Z85Gr5L9MrQn3LwrMhWeyz/BMIoqo4vv2PG78YAB20+M63/31eYAfT4vFSv
+ tlNqe9NBmsD0PwsqBZE8LJ550woaNjP3JeaYKP7jT6qfN1HV+DiIt9rVVVUvNgHuFQMK
+ p9rDpg9uETRXUDGjKP1HZ3cGjY4DbO3zDwNNgCRKErF7+UxpmkIM+suSSTGMa9h+D8EE
+ z8ig==
+X-Gm-Message-State: ALyK8tJeq6vRQTYhSx1EIGMFJRU0KUhHgQXdOjopVgBQVa78Ab3Q7zlxfiLNUjXqFAFSKCk40V77ncaH+4T6kg==
+X-Received: by 10.157.1.107 with SMTP id 98mr3851170otu.17.1467158801795; Tue,
+ 28 Jun 2016 17:06:41 -0700 (PDT)
+MIME-Version: 1.0
+Received: by 10.182.217.106 with HTTP; Tue, 28 Jun 2016 17:06:41 -0700 (PDT)
+In-Reply-To: <2DC6C84C-5FE1-4908-B50B-47C6BF928A1C@voskuil.org>
+References: <87h9cecad5.fsf@rustcorp.com.au>
+ <1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
+ <577234A4.3030808@jonasschnelli.ch>
+ <360EF9B8-A174-41CA-AFDD-2BC2C0B4DECB@voskuil.org>
+ <20160628182202.GA5519@fedora-21-dvm>
+ <D40F9E9D-DB6C-4083-A9E8-C5EBC363DB30@voskuil.org>
+ <20160628201447.GA1148@fedora-21-dvm>
+ <4DCF7DD2-6533-4F79-8CA1-871B67C01BDA@voskuil.org>
+ <20160628203605.GA1328@fedora-21-dvm>
+ <E8335291-7142-4E21-A1E2-76F387426741@voskuil.org>
+ <CAAS2fgRGbnH-NtPRdLe0yhFSoqJ7b6O25LfyGv_ULHhy8bBSpg@mail.gmail.com>
+ <B1AF0E38-522E-4EC7-8595-92972D658430@gmail.com>
+ <A74C9C1E-07CE-4769-85BA-AA97F55167EC@voskuil.org>
+ <E1CB43A4-F13D-4109-AB05-DDD650FEC0C9@gmail.com>
+ <2DC6C84C-5FE1-4908-B50B-47C6BF928A1C@voskuil.org>
+From: Nick ODell <nickodell@gmail.com>
+Date: Tue, 28 Jun 2016 18:06:41 -0600
+Message-ID: <CANN4kmfqbWwPhD1kyWMsrRhDJaniu3f3Ca_-LSuNawDwY1_uvw@mail.gmail.com>
+To: Eric Voskuil <eric@voskuil.org>,
+ Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
+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 <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: Wed, 29 Jun 2016 00:06:43 -0000
+
+>They both require authentication,
+
+Yeah, but not the same *sort* of authentication. As a trivial example,
+you could have ten servers that sign long-term keys for nodes. All
+that they need to check is that the node requesting a signature owns
+the corresponding IP address. On the other hand, 'evil nodes' is a
+subjective quality that is hard to assess automatically.
+
+>and if you intend to connect to potentially evil nodes you aren't securing anything
+
+Bitcoin is designed with the assumption that some of the nodes you
+connect to might be evil. Sure, if 100% of the nodes you're connected
+to are evil, you're screwed. However, we shouldn't avoid protecting
+people from someone on the same coffee-shop network, just because the
+same mitigation won't work against a nation-state.
+
+On Tue, Jun 28, 2016 at 5:29 PM, Eric Voskuil via bitcoin-dev
+<bitcoin-dev@lists.linuxfoundation.org> wrote:
+> Your description of the two scenarios reduces to one. They both require
+> authentication, and if you intend to connect to potentially evil nodes you
+> aren't securing anything with link level security except the knowledge that
+> your potentially evil node connection remains so.
+>
+> e
+>
+> On Jun 29, 2016, at 12:33 AM, Cameron Garnham <da2ce7@gmail.com> wrote:
+>
+>
+> There are two different topics mixed up here.
+>
+> 1. Link-level security (secure connection to the node we intended to connect
+> to).
+>
+> 2. Node-level security (aka; don't connect to a 'evil node').
+>
+> The fist requires link-level encryption and authentication.
+>
+> The second requires identity authentication.
+>
+> You described the 'evil node' attack; that indeed needs an identity system
+> to stop. However BIP151 doesn't intend to protect against connecting to evil
+> Bitcoin Nodes.
+>
+> It is important not to mixup link-level authentication and node-level
+> authentication.
+>
+> When your client picks random nodes to connect to, you are not considered
+> whom in particular runs them. (Rather that you have a good random sample of
+> the network).
+>
+> If you manually add a friends node; at this point you wish to have
+> node-level authentication. However, this may (and probably should) happen
+> out-of-band.
+>
+>
+> Sent from my iPhone
+>
+> On 29 Jun 2016, at 01:07, Eric Voskuil <eric@voskuil.org> wrote:
+>
+> Hi Cameron, good to hear from you!
+>
+> On Jun 28, 2016, at 11:40 PM, Cameron Garnham <da2ce7@gmail.com> wrote:
+>
+> Unauthenticated link level encryption is wonderful! MITM attacks are
+> overrated; as they require an active attacker.
+>
+>
+> This is not really the case with Bitcoin. A MITM attack does not require
+> that the attacker find a way to inject traffic into the communication
+> between nodes. Peers will connect to the attacker directly, or accept
+> connections directly from it. Such attacks can be easier than even passive
+> attacks.
+>
+> Stopping passive attacks is the low hanging fruit. This should be taken
+> first.
+>
+> Automated and secure peer authentication in a mesh network is a huge topic.
+> One of the unsolved problems in computer science.
+>
+> A simple 'who is that' by asking for the fingerprint of your peers from your
+> other peers is a very simple way to get 'some' authentication. Semi-trusted
+> index nodes also is a low hanging fruit for authentication.
+>
+>
+> It is the implication of widespread authentication that is at issue. Clearly
+> there are ways to implement it using a secure side channels.
+>
+> However, let's first get unauthenticated encryption. Force the attackers to
+> use active attacks. (That are thousands times more costly to couduct).
+>
+> Sent from my iPhone
+>
+> On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin-dev
+> <bitcoin-dev@lists.linuxfoundation.org> wrote:
+>
+> On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev
+> <bitcoin-dev@lists.linuxfoundation.org> wrote:
+>
+> An "out of band key check" is not part of BIP151.
+>
+>
+> It has a session ID for this purpose.
+>
+> It requires a secure channel and is authentication. So BIP151 doesn't
+> provide the tools to detect an attack, that requires authentication. A
+> general requirement for authentication is the issue I have raised.
+>
+>
+> One might wonder how you ever use a Bitcoin address, or even why we
+> might guess these emails from "you" aren't actually coming from the
+> NSA.
+> _______________________________________________
+> bitcoin-dev mailing list
+> bitcoin-dev@lists.linuxfoundation.org
+> 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
+>
+