From: Pieter Wuille <pieter.wuille@gmail•com>
To: Eric Voskuil <eric@voskuil•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 151
Date: Wed, 31 Aug 2016 16:29:53 +0200 [thread overview]
Message-ID: <CAPg+sBhZaSkRc9yDKHYPjq3oD_bXZ1GsBgzgqOV_Dcd-LZY3BA@mail.gmail.com> (raw)
In-Reply-To: <0932A659-6BE0-441F-AD05-ED846BBE7C80@voskuil.org>
Hello Eric,
I felt like I still owed you a response to the points below.
On Thu, Jun 30, 2016 at 5:10 PM, Eric Voskuil <eric@voskuil•org> wrote:
> Pieter, these are in my opinion very reasonable positions. I've made some observations inline.
>
>> On Jun 30, 2016, at 3:03 PM, Pieter Wuille <pieter.wuille@gmail•com> wrote:
>>
>> On Thu, Jun 30, 2016 at 11:57 AM, Eric Voskuil via bitcoin-dev
>> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>> The proliferation of node identity is my primary concern - this relates to privacy and the security of the network.
>>
>> I think this is a reasonable concern.
>>
>> However, node identity is already being used widely, and in a very
>> inadvisable way:
>> * Since forever there have been lists of 'good nodes' to pass in
>> addnode= configuration options.
>> * Various people run multiple nodes in different geographic locations,
>> peering with each other.
>> * Various pieces of infrastructure exist that relies on connecting to
>> well-behaving nodes (miner relay networks, large players peering
>> directly with each other, ...)
>
> Yes, libbitcoin also provides these options on an IP basis.
>
>> * Several lightweight clients support configuring a trusted host to connect to.
>
> I explicitly exclude client-server behavior as I believe the proper resolution is to isolate clients from the P2P protocol. Libbitcoin does this already.
I think that's a false dichotomy. There is no reason why the P2P
network consists of purely servers (full nodes) and clients
(lightweight nodes). Where does a client fit that is SPV at startup,
but upgrades in the background to a full node? It seems strange that
such a client would use a 'client protocol' for initial connections,
but the P2P protocol for syncing with history, when both come from the
same peers, and transmit the same kind of information.
What would make sense IMHO is a protocol split between the different
kinds of transmission:
1) Historical block download
2) Block synchronization at the tip
3) Transaction relay
...
(1) prefers high bandwidth, has no connectivity concerns, and does not
care about latency and has no privacy concerns. (2) needs
partition-resistance, low latency and has also no privacy concerns.
(3) needs moderate latency, reliability of propagation and privacy.
If there were to be separate protocols for these, I would argue that
(3) should use opportunistic encryption always to increase transaction
source privacy, and (2) and (3) need authentication when one of the
peers is not fully validating.
BIP 150/151 give the tools to construct these.
>> Perhaps you deplore that fact, but I believe it is inevitable that different pieces of the network will make different choices here. You can't prevent people from create connections along preexisting trust lines. That does not mean that the network as a whole relies on first establishing trust everywhere.
>
> Of course, the network operates just fine without universal trust. My concern is not that it is required, but that it may grow significantly and will have a tendency to gravitate towards more effective registration mechanisms for what is a "good" peer. Even an informal but pervasive web of trust may make it difficult for untrusted parties to connect.
Maybe, but I'm very unconvinced that that will happen more than how
today IP and DNS-based "authentication" is used already (in very
inadvisable ways).
>> And I do think there are advantages.
>>
>> BIP 151 on its own gives you opportunistic encryption. You're very right to point out that this does not give you protection from active attackers, and that active attacking is relatively easy through sybil attacks. I still prefer my attacker to actually do that over just listening in on my connection.
> I agree, and I doubt this proposal will have much impact on an advanced persistent threat, or even lesser threats. People should understand that there is both a risk and a limited benefit to this proposal.
I believe the risk is only in misunderstanding what it is good for,
and there significant benefits to a network that encrypts connections
by default, as it excludes purely passive attackers.
> I believe you have misinterpreted my comments on distributed anonymous credentials (and the like) as commentary on the construction of BIP151 (and a subsequent auth proposal). As such your observation that it is exaggerated would make sense, but it is not what I intended. Encryption and auth are straightforward. Preventing bad nodes from participating in an anonymous distributed system is not.
Preventing bad nodes from participating is a very hard problem, if not
impossible. That doesn't mean we can't improve the current situation:
people are relying on node identity already, and doing so in ways that
have unclear attack vectors (IP spoofing, DNS poisoning, BGP routing
attacks). Adding optional and non-discoverable cryptographic
identities can improve this.
--
Pieter
next prev parent reply other threads:[~2016-08-31 14:29 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-28 2:31 [bitcoin-dev] BIP 151 use of HMAC_SHA512 Rusty Russell
2016-06-28 7:17 ` [bitcoin-dev] BIP 151 Eric Voskuil
2016-06-28 8:26 ` Jonas Schnelli
2016-06-28 16:45 ` Eric Voskuil
2016-06-28 18:22 ` Peter Todd
2016-06-28 18:35 ` Eric Voskuil
2016-06-28 20:14 ` Peter Todd
2016-06-28 20:29 ` Eric Voskuil
2016-06-28 20:36 ` Peter Todd
2016-06-28 21:22 ` Eric Voskuil
2016-06-28 21:36 ` Gregory Maxwell
2016-06-28 21:40 ` Cameron Garnham
2016-06-28 22:07 ` Eric Voskuil
2016-06-28 22:33 ` Cameron Garnham
2016-06-28 23:29 ` Eric Voskuil
2016-06-29 0:06 ` Nick ODell
2016-06-28 21:59 ` Eric Voskuil
[not found] ` <CAAS2fgQ0Ocs8hF+pf+fWfkKKhQwxNKpY=JHpb_bwua7neVO8tg@mail.gmail.com>
2016-06-28 23:34 ` Eric Voskuil
2016-06-28 20:06 ` Jonas Schnelli
2016-06-28 23:31 ` Eric Voskuil
2016-06-29 11:17 ` Alfie John
2016-06-30 11:56 ` Eric Voskuil
2016-06-30 12:20 ` Jonas Schnelli
2016-06-30 12:27 ` Eric Voskuil
2016-06-30 12:43 ` Jonas Schnelli
2016-06-30 15:22 ` Eric Voskuil
2016-06-30 16:52 ` Peter Todd
2016-06-30 18:25 ` Eric Voskuil
2016-06-30 19:06 ` Peter Todd
2016-06-30 20:26 ` Eric Voskuil
2016-06-28 19:55 ` Gregory Maxwell
2016-06-28 23:33 ` Eric Voskuil
2016-06-29 1:01 ` Gregory Maxwell
2016-06-30 9:57 ` Eric Voskuil
2016-06-30 13:03 ` Pieter Wuille
2016-06-30 15:10 ` Eric Voskuil
2016-08-31 14:29 ` Pieter Wuille [this message]
2016-06-30 13:36 ` Erik Aronesty
2016-06-30 14:47 ` Alfie John
2016-07-02 9:44 ` Chris Priest
2016-06-28 12:13 ` Jonas Schnelli
2016-06-28 17:39 ` Eric Voskuil
2016-06-28 7:19 ` [bitcoin-dev] BIP 151 use of HMAC_SHA512 Jonas Schnelli
2016-06-28 8:31 ` Arthur Chen
2016-06-29 18:34 ` Jonas Schnelli
2016-06-29 20:13 ` Peter Todd
2016-06-29 20:31 ` Jonas Schnelli
2016-06-29 1:00 ` Rusty Russell
2016-06-29 1:38 ` Arthur Chen
2016-06-29 1:56 ` Ethan Heilman
2016-06-29 6:58 ` Pieter Wuille
2016-06-29 14:38 ` Ethan Heilman
2016-06-29 18:46 ` Jonas Schnelli
2016-07-01 3:25 ` Rusty Russell
2016-07-01 22:42 ` Zooko Wilcox
2016-07-04 1:23 ` Arthur Chen
2016-07-04 1:44 ` Arthur Chen
2016-07-04 6:47 ` Jonas Schnelli
2016-07-04 6:37 ` Jonas Schnelli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPg+sBhZaSkRc9yDKHYPjq3oD_bXZ1GsBgzgqOV_Dcd-LZY3BA@mail.gmail.com \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=eric@voskuil$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox