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, ...) * Several lightweight clients support configuring a trusted host to connect to. Perhaps you deplore that fact, but I believe it is inevitable that different pieces of the network will make different choices here. You can'tg 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. 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. And yes, we should also work on improving the privacy nodes and wallets have orthogonal to encryption, but nothing will make everything perfectly private. 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. 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, 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. 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. > 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. -- Pieter _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
