From: Eric Voskuil <eric@voskuil•org>
To: Pieter Wuille <pieter.wuille@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 151
Date: Thu, 30 Jun 2016 17:10:52 +0200 [thread overview]
Message-ID: <0932A659-6BE0-441F-AD05-ED846BBE7C80@voskuil.org> (raw)
In-Reply-To: <CAPg+sBigr0BZBiuW9DYpxJ3ytZ4g30k_9B+Eb8QhQv2dC9qQUA@mail.gmail.com>
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.
> 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.
> 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.
We agree, and the ease of this attack must be acknowledged. And given that the protection is weak it is not unreasonable to consider the potential downside of creeping node identity.
> And yes, we should also work on improving the privacy nodes and wallets have orthogonal to encryption, but nothing will make everything perfectly private.
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.
> BIP 151 plus a simple optional pre-shared-secret authentication extension can improve upon pure IP-based authentication, as well as simplify things like SSL tunnels, and onion addresses purely used as identity. This will still require explicit configuration, but not more than now.
I agree - I consider tunneling the legitimate use case for this proposal. Yet when nodes become closely coupled they are not fully independent. I have a concern with these practices being promoted for general use while at the same time being strongly implemented.
> BIP 151 plus a non-leaking public key authentication scheme (where peers can query "are you the peer with pubkey X?" but don't learn anything if the answer is no) with keys specific to the IP addresses can give a TOFU-like security. Nodes already remember IP addresses they've succesfully interacted with in the past, and ban IP addresses that misbehave. Being able to tell whether a node you connect to is the same as one you've connected to before is a natural extension of this,
With this I disagree. There is no way to know that a node is one you have connected to previously unless that node wants you to know (apart from relying on the IP address). This is of no value in detecting misbehaving nodes that do not want to be detected. Ones that don't care (eg broken nodes) can be sufficiently managed by IP address.
> and does not require establishing any real-world identity beyond what we're already implicitly relying on.
>
> Perhaps these use cases and their security assumptions should be spelled out more clearly in the BIP.
Absolutely.
> If there is a misunderstanding, it should be clearly stated that BIP 151 is only a building block for further improvements
>
>> Secondarily I am concerned about users operating under a false assumption about the strength of privacy.
>
> This is a widespread problem, but it exists far outside the scope of this proposal. The privacy properties of Bitcoin are often
> misrepresented and even used as advertizements. The solution is education, not avoiding improvements because they may be misunderstood.
Yes, let's not make it worse. This is a secondary concern. I remain primarily concerned about growth of node identity in a vain attempt to make transaction submission private in the P2P protocol (and to patch the other client-server features, specifically Bloom filters). As you imply, we cannot stop people from turning Bitcoin into a private network - but let's not facilitate it either.
>> The complexity of the proposed construction is comparable to that of Bitcoin itself.
>
> I really think this is an exaggeration. It's a diffie-hellman handshake and a stream cipher (both very common constructions), that apply to individual connections. There are no consensus risks nor a
> requirement for coordinated change through the network. The
> cryptographic code can be directly reused from a well-known project
> (OpenSSH), and is very small in size.
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.
e
next prev parent reply other threads:[~2016-06-30 15:11 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 [this message]
2016-08-31 14:29 ` Pieter Wuille
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=0932A659-6BE0-441F-AD05-ED846BBE7C80@voskuil.org \
--to=eric@voskuil$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pieter.wuille@gmail$(echo .)com \
/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