Ali Sherief [ARCHIVE] on Nostr: š Original date posted:2021-07-12 š Original message:This is an interesting ...
š
Original date posted:2021-07-12
š Original message:This is an interesting read: https://bitcointalk.org/index.php?topic=5348856.0
So according to this, somebody is spamming the bitcoin network with addr message pointing to invalid addresses and ports, which bloats the peers.dat and corresponding structure in memory.
Since peers.dat uses a custom record type which I don't know how to parse, I wasn't able to check specifics of IP addresses listed in there, but I believe I have a workaround to prevent this kind of thing from happening. Exactly how easy or difficult it will be to implement this change I don't know.
- Change the AddrDb updating functionality so that it does not add nodes that are unreachable. Not unreachable by timeout, but "connection refused" kind of errors.
Such addresses can either be stored in a new, separate database-like file such as "ignore.dat", or they can be augmented in the peers.dat file under a new entry type (I'm not sure if this is even possible). In both cases the invalid nodes can be immediately flushed from memory to avoid processing them.
-- This is only done the first time the node is seen in the wild. To avoid blocking nodes which happened to go offline, the check won't be made if it's already in the buckets. So it won't clean up an attack like this (meaning peers.dat files have to be recreated to fix this) but it will prevent another in the future.
- In order to facilitate other nodes discovering blocked nodes, a new ZMQ message can be made that sends the node's list of ignored addresses. Since I haven't used ZMQ much I don't know the specifics of how to do this.
- Introduce a new file or command-line/config option called "ignorelist" or something with a list of subnets that will *not* be read into the AddrDB buckets in any case.
It will work differently from the banlist, whose primary job is to block peers that send invalid messages, not peers that are not, and cannot, be unreachable in the first place.
- Ali Sherief
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210712/0c857f86/attachment.html>;
š Original message:This is an interesting read: https://bitcointalk.org/index.php?topic=5348856.0
So according to this, somebody is spamming the bitcoin network with addr message pointing to invalid addresses and ports, which bloats the peers.dat and corresponding structure in memory.
Since peers.dat uses a custom record type which I don't know how to parse, I wasn't able to check specifics of IP addresses listed in there, but I believe I have a workaround to prevent this kind of thing from happening. Exactly how easy or difficult it will be to implement this change I don't know.
- Change the AddrDb updating functionality so that it does not add nodes that are unreachable. Not unreachable by timeout, but "connection refused" kind of errors.
Such addresses can either be stored in a new, separate database-like file such as "ignore.dat", or they can be augmented in the peers.dat file under a new entry type (I'm not sure if this is even possible). In both cases the invalid nodes can be immediately flushed from memory to avoid processing them.
-- This is only done the first time the node is seen in the wild. To avoid blocking nodes which happened to go offline, the check won't be made if it's already in the buckets. So it won't clean up an attack like this (meaning peers.dat files have to be recreated to fix this) but it will prevent another in the future.
- In order to facilitate other nodes discovering blocked nodes, a new ZMQ message can be made that sends the node's list of ignored addresses. Since I haven't used ZMQ much I don't know the specifics of how to do this.
- Introduce a new file or command-line/config option called "ignorelist" or something with a list of subnets that will *not* be read into the AddrDB buckets in any case.
It will work differently from the banlist, whose primary job is to block peers that send invalid messages, not peers that are not, and cannot, be unreachable in the first place.
- Ali Sherief
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210712/0c857f86/attachment.html>;