Hi Andy >> >>> Does openssh have this same problem? >> No. OpenSSH doesn't make an effort to protect the privacy of its users. >> >>> I'm assuming this could be parallelized very easily, so it is not a huge >>> problem? >> It's not a issue because we're not aware of any usecase where a node >> would have a large list of authenticated peers. >> >>> Each peer can configure one identity-key (ECC, 32 bytes) per listening >> network interface (IPv4, IPv6, tor). >> >> I'm not aware of any reason for this limitation to exist. A node >> should be able to have as many listening identities as it wants, with >> a similar cost to having a large authorized keys list. >> > > So you are saying that you agree with me that the original text needs to > be revised slightly or I am just misinterpreting the original text? Yes. I think this limitation could be removed. A responding node can have – in theory – multiple identity-keys per network interface (network interfaces is also confusing, because you could run multiple bitcoind instances on the same interface with different ports). The BIP should just make clear, that it is probably wise, to use different identity-keys for each network interface (ipv4, v6, tor). I'll try to overhaul that part.