On 08/08/2016 11:00 AM, Jonas Schnelli via bitcoin-dev wrote:
> # ___known-peers___ contains known identity-public-keys together with a
> network identifier (IP & port), similar to the "known-host" file
> supported by openssh.


I have mixed feelings about strictly tying the identity-public-keys with 
a network identifier. I think the purpose of this is to detect if 
someone has physically stolen and compromised my bitcoin node and placed 
it on another network under control of an attacker. This seems to be a 
bit of a benefit, however, an attacker could always spoof the original 
network identifier anyway.

I run my bitcoin node on an internet connection that does not guarantee 
a static IP address (although it usually stays the same for several 
weeks or months at a time). I'd like to be able to make secure 
connections back to my own node, even if I know the IP address may 
change from time to time. There are several reasons for wanting to this 
with a changing IP. The first is because the bandwidth on my internet 
connection with a guaranteed static IP address is considerably more 
expensive than my internet connection without a guaranteed static IP 
address. The second reason is because the DNS PTR record for my static 
IP address is personally identifiable based on other reasons/services. 
The internet connection that my bitcoin node is using without a 
guaranteed static IP address just has a PTR record that basically 
includes my IP address and ISP name. This isn't much use to the general 
public (although my ISP obviously knows who I am). The third reason is 
that I consider it a good thing from a privacy perspective if my IP 
address changes every once and a while.

Maybe a strict check option where the identity-public-keys must 
optionally match a specific network identifier would be a compromise? 
Maybe this is up to the client implementation to decide, so it should 
just be suggested in the BIP rather than required?




> # ___authorized-peers___ contains authorized identity-public-keys

Is there an option for a wildcard here? Couldn't there be a case where 
the client wants to authenticate, but the bitcoin node does not care who 
it's clients are? This would be similar to many of the http based 
bitcoin block explorer API services that are out there. The API 
operators have built up some reputation, so people use them, but they 
don't necessarily care about who their users are.







> === Local identity key management ===
> Each peer can configure one identity-key (ECC, 32 bytes) per listening
> network interface (IPv4, IPv6, tor).

What if I have bitcoind listening on multiple IPv4 interfaces? Can I 
have a different identity-key for each IPv4 interface?

Also, would it be possible to only allow this authentication on specific 
interfaces? In my example above where I have two internet connections, 
if you don't agree to loosening the tie between the network identifier 
and the identity-public-keys, maybe I would just connect my bitcoin node 
to both internet connections, but only allow a few authorized-peers on 
the static IP (which would be low bandwidth), and then not authenticate 
on the internet connection with the changing IP at all

If you don't want to increase complexity by adding these options, one 
could always accomplish the same thing by runing two instances of 
bitcoind and pairing the two over a local network, it would just be a 
waste of resources.




> == Disadvantages ==
>
> The protocol may be slow if a peer has a large authorized-peers database
> due to the requirement of iterating and hashing over all available
> authorized peers identity-public-keys.


Does openssh have this same problem?

I'm assuming this could be parallelized very easily, so it is not a huge 
problem?