public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Pieter Wuille <bitcoin-dev@wuille•net>
To: Ali Sherief <ali@notatether•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] An idea to block invalid addresses from reaching the peers.dat buckets
Date: Tue, 13 Jul 2021 00:54:29 +0000	[thread overview]
Message-ID: <7onDqKwXHBsQUhahHnz9HH2127d2xdI-r2GgcX1DiOarSlWj9569-lEmppxRkY-aDfGHyqk62_YwxaoAUYAVJfCwK90-khTmPYntT7veF_g=@wuille.net> (raw)
In-Reply-To: <PKeS7M-QWkdvfikZ0M_yH-Gj4t1VlxmSF43XMEuR8aCGps1WAbt-kglEm1ee-YDhsmSIM68G4-_xNMFgOB9u5H6UAT1qow8sW1yt4iaIShI=@notatether.com>

[-- Attachment #1: Type: text/plain, Size: 2259 bytes --]

> 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.

The peers.dat file and the structure in memory have a fixed size, so those are not a problem.

> 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.

The "addrman" database is organized into 1024 buckets with "new" addresses (which we haven't tried to connect to), and 256 buckets with "tried" addresses (which we have connected to ourselves). Each bucket consists of 64 positions, and each of those can hold 1 address. Along with the addresses we remember where we originally heard about them (which IP).

Each group of source IPs (/16s etc) selects a subset of just 64 buckets (salted using a host-specific secret key), and inserts the newly received IPs in a position in a bucket in one of those, if certain criteria are met (the position was empty, or it held an IP address that also occurs elsewhere in the table already). This limits the impact an attacker can have, because they cannot under any circumstances affect IPs in buckets outside of the 64 their group maps to.

This database structure is a design from 2012, which was significantly improved following recommendations in the Eclipse Attacks paper (https://cs-people.bu.edu/heilman/eclipse/).

> - 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.

In a way we have that; there are separate tables in peers.dat for new and tried addresses. I don't think it's feasible to not add untried addresses at all, as our ability to create connections is far too low to try everything we receive. But I think the existing structure should reasonably protect against spam (in terms of database poisoning; there is certainly a processing cost to it).

Cheers,

--
Pieter

[-- Attachment #2: Type: text/html, Size: 2967 bytes --]

      reply	other threads:[~2021-07-13  1:00 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-12 23:33 Ali Sherief
2021-07-13  0:54 ` Pieter Wuille [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='7onDqKwXHBsQUhahHnz9HH2127d2xdI-r2GgcX1DiOarSlWj9569-lEmppxRkY-aDfGHyqk62_YwxaoAUYAVJfCwK90-khTmPYntT7veF_g=@wuille.net' \
    --to=bitcoin-dev@wuille$(echo .)net \
    --cc=ali@notatether$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox