> 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 ju
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
>> wou
On 08/08/2016 01:42 PM, Gregory Maxwell wrote:
On Mon, Aug 8, 2016 at 5:09 PM, Andy Schroder via bitcoin-dev
wrote:
I have mixed feelings about strictly tying the identity-public-keys with a
[...]
guaranteed static IP address. The second reason is because the DNS PTR
I don't see any reason
On Mon, Aug 8, 2016 at 5:09 PM, Andy Schroder via bitcoin-dev
wrote:
> I have mixed feelings about strictly tying the identity-public-keys with a
[...]
> guaranteed static IP address. The second reason is because the DNS PTR
I don't see any reason that it couldn't also accept a DNS name there.
T
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
Hi
As already mentioned in the recent BIP151 thread
(https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-June/012826.html),
I propose the following authentication scheme to basically allow MITM
detection and rejection in conjunction with BIP151.
The proposed authentication BIP does requi
