Crate bitcoin_addrman
source ·Structs
- | Extended statistics about a CAddress |
- | Stochastic address manager | | Design goals: | | - Keep the address tables in-memory, and | asynchronously dump the entire table to | peers.dat. | | - Make sure no (localized) attacker can fill | the entire table with his nodes/addresses. | | To that end: | | Addresses are organized into buckets that can | each store up to 64 entries. | | ————————————— | Addresses to which our node has not | successfully connected go into 1024 “new” | buckets. | | - Based on the address range (/16 for | IPv4) of the source of information, or | if an asmap is provided, the AS it | belongs to (for IPv4/IPv6), 64 buckets | are selected at random. | | - The actual bucket is chosen from one of | these, based on the range in which the | address itself is located. | | - The position in the bucket is chosen | based on the full address. | | - One single address can occur in up to | 8 different buckets to increase | selection chances for addresses that are | seen frequently. The chance for | increasing this multiplicity decreases | exponentially. | | - When adding a new address to an occupied | position of a bucket, it will not | replace the existing entry unless that | address is also stored in another bucket | or it doesn’t meet one of several | quality criteria (see IsTerrible for | exact criteria). | | ————————————— | Addresses of nodes that are known to be | accessible go into 256 “tried” buckets. | | - Each address range selects at random | 8 of these buckets. | | - The actual bucket is chosen from one of | these, based on the full address. | | - When adding a new good address to an | occupied position of a bucket, a FEELER | connection to the old address is | attempted. The old entry is only | replaced and moved back to the “new” | buckets if this attempt was | unsuccessful. | | ————————————— | Bucket selection is based on cryptographic | hashing, using a randomly-generated 256-bit | key, which should not be observable by | adversaries. | | ————————————— | Several indexes are kept for high | performance. Setting m_consistency_check_ratio | with the -checkaddrman configuration option will | introduce (expensive) consistency checks for | the entire data structure.
Enums
- | Serialization versions. |
Constants
- | Maximum allowed number of entries in | buckets for new and tried addresses |
- | How old addresses can maximally be |
- | How many successive failures are allowed | … |
- | … in at least this many days |
- | Maximum number of times an address can | occur in the new table |
- | Over how many buckets entries with new | addresses originating from a single | group are spread |
- | Total number of buckets for new addresses |
- | How recent a successful connection | should be before we allow an address | to be evicted from tried |
- | After how many failed attempts we give | up on a new node |
- | The maximum number of tried addr collisions | to store |
- | The maximum time we’ll spend trying | to resolve a tried table collision, | in seconds |
- | Over how many buckets entries with tried | addresses from a single group (/16 for | IPv4) are spread |
- | Total number of buckets for tried addresses |
- | The maximum format this software knows it | can unserialize. Also, we always serialize | in this format. | | The format (first byte in the serialized | stream) can be higher than this and still | this software may be able to unserialize | the file - if the second byte (see |
lowest_compatible
inUnserialize()
) is | less or equal to this. - | The initial value of a field that is | incremented every time an incompatible | format change is made (such that old | software versions would not be able to | parse and understand the new file | format). This is 32 because we overtook the | “key size” field which was 32 historically. | @note Don’t increment this. Increment |
lowest_compatible
inSerialize()
| instead. - | Default for -checkaddrman |
Functions
- | Returns an error string on failure |
- | Only used by tests. |