Jonas Schnelli [ARCHIVE] on Nostr: 📅 Original date posted:2016-08-09 📝 Original message:Hi Andy >> >>> Does ...
📅 Original date posted:2016-08-09
📝 Original message: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.
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160809/2de7eeaa/attachment.sig>
📝 Original message: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.
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160809/2de7eeaa/attachment.sig>