Author: Andy Schroder 2016-08-08 17:09:45
Published on: 2016-08-08T17:09:45+00:00
In a bitcoin-dev post, Jonas Schnelli expressed concerns about the current format of known-peers and authorized-peers files. He is unsure about strictly tying identity-public-keys with network identifiers as it has its flaws; an attacker could always spoof the original network identifier anyway. Furthermore, if one runs their Bitcoin node on an internet connection that does not guarantee a static IP address, they may want to make secure connections back to their own node even if the IP address may change from time to time. A strict check option where the identity-public-keys must optionally match a specific network identifier or a wildcard option could be a compromise. For local identity key management, each peer can configure one identity key per listening network interface, but it is unclear whether one can have a different identity-key for each IPv4 interface. One proposed solution is to run two instances of bitcoind and pairing the two over a local network. The disadvantage mentioned is that 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.
Updated on: 2023-06-11T19:22:51.433656+00:00