📅 Original date posted:2015-03-05
📝 Original message:Bitcoind protects against this by storing the addresses it has learned
about in buckets. The bucket an address is stored in is chosen based on the
IP of the peer that advertised the addr message, and the address in the
addr message itself. The idea is that the bucketing is done in a randomized
way so that no attacker should be able to fill your database with his or
her own nodes.
>From addrman.h
<https://github.com/bitcoin/bitcoin/blob/master/src/addrman.h>;:
/** Stochastic address manager
*
* Design goals:
* * Keep the address tables in-memory, and asynchronously dump the entire
to able in peers.dat.
* * Make sure no (localized) attacker can fill the entire table with his
nodes/addresses.
*
* To that end:
* * Addresses are organized into buckets.
* * Address that have not yet been tried go into 256 "new" buckets.
* * Based on the address range (/16 for IPv4) of source of the
information, 32 buckets are selected at random
* * The actual bucket is chosen from one of these, based on the range
the address itself is located.
* * One single address can occur in up to 4 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 a full bucket, a randomly chosen
entry (with a bias favoring less recently seen
* ones) is removed from it first.
* * Addresses of nodes that are known to be accessible go into 64
"tried" buckets.
* * Each address range selects at random 4 of these buckets.
* * The actual bucket is chosen from one of these, based on the full
address.
* * When adding a new good address to a full bucket, a randomly
chosen entry (with a bias favoring less recently
* tried ones) is evicted from it, back to the "new" buckets.
* * 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. Defining
DEBUG_ADDRMAN will introduce frequent (and expensive)
* consistency checks for the entire data structure.
*/
On Wed, Mar 4, 2015 at 5:40 PM, Thy Shizzle <thashiznets at yahoo.com.au>
wrote:
> Hi, so just a thought as my node relays addresses etc. If I wanted to
> really slow down communication over the P2P network, what's stopping me
> from popping up a heap of dummy nodes that do nothing more than exchange
> version and relay addresses, except I send addr messages with all 1000
> addresses pointing to my useless nodes that never send invs or respond to
> getdata etc so clients connect to my dumb nodes instead of legit ones. I'm
> thinking that if I fill up their address pool with enough addresses to dumb
> nodes and keep them really fresh time wise, it could have a bit of an
> impact especially if all 8 outbound connections are used up by my dumb
> nodes right?
>
> I don't want to do this obviously, I'm just thinking about it as I'm
> building my node, what is there to stop this happening?
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150304/536a50fe/attachment.html>;
Kevin Greene [ARCHIVE] /
npub1l3…hwq5p
2023-06-07 15:31:44
in reply to nevent1q…8nrs
Author Public Key
npub1l3sj8amnurgf3cu3p2hhcaham90khafc4vgsmymqdnn0k3kanulsghwq5pPublished at
2023-06-07 15:31:44Event JSON
{
"id": "a11ce0e1a8efb0ab28e38a2ff2be21eab2d5e7e9926daabc24cde94673d51a8e",
"pubkey": "fc6123f773e0d098e3910aaf7c76fdd95f6bf538ab110d93606ce6fb46dd9f3f",
"created_at": 1686151904,
"kind": 1,
"tags": [
[
"e",
"2b67bf8a19b63ad2eea85d89cf4792646f434f945f648230540eed45f2507167",
"",
"root"
],
[
"e",
"c5c8569a25a057905f4c2e773f25ce7d70566fcf66fc67094ec7b2ddefef9ab3",
"",
"reply"
],
[
"p",
"3c7421b6a5b9065ef5ba5b113416bc212a389a58853f668baffb4a8a04f2b35f"
]
],
"content": "📅 Original date posted:2015-03-05\n📝 Original message:Bitcoind protects against this by storing the addresses it has learned\nabout in buckets. The bucket an address is stored in is chosen based on the\nIP of the peer that advertised the addr message, and the address in the\naddr message itself. The idea is that the bucketing is done in a randomized\nway so that no attacker should be able to fill your database with his or\nher own nodes.\n\n\u003eFrom addrman.h\n\u003chttps://github.com/bitcoin/bitcoin/blob/master/src/addrman.h\u003e:\n\n/** Stochastic address manager\n *\n * Design goals:\n * * Keep the address tables in-memory, and asynchronously dump the entire\nto able in peers.dat.\n * * Make sure no (localized) attacker can fill the entire table with his\nnodes/addresses.\n *\n * To that end:\n * * Addresses are organized into buckets.\n * * Address that have not yet been tried go into 256 \"new\" buckets.\n * * Based on the address range (/16 for IPv4) of source of the\ninformation, 32 buckets are selected at random\n * * The actual bucket is chosen from one of these, based on the range\nthe address itself is located.\n * * One single address can occur in up to 4 different buckets, to\nincrease selection chances for addresses that\n * are seen frequently. The chance for increasing this multiplicity\ndecreases exponentially.\n * * When adding a new address to a full bucket, a randomly chosen\nentry (with a bias favoring less recently seen\n * ones) is removed from it first.\n * * Addresses of nodes that are known to be accessible go into 64\n\"tried\" buckets.\n * * Each address range selects at random 4 of these buckets.\n * * The actual bucket is chosen from one of these, based on the full\naddress.\n * * When adding a new good address to a full bucket, a randomly\nchosen entry (with a bias favoring less recently\n * tried ones) is evicted from it, back to the \"new\" buckets.\n * * Bucket selection is based on cryptographic hashing, using a\nrandomly-generated 256-bit key, which should not\n * be observable by adversaries.\n * * Several indexes are kept for high performance. Defining\nDEBUG_ADDRMAN will introduce frequent (and expensive)\n * consistency checks for the entire data structure.\n */\n\nOn Wed, Mar 4, 2015 at 5:40 PM, Thy Shizzle \u003cthashiznets at yahoo.com.au\u003e\nwrote:\n\n\u003e Hi, so just a thought as my node relays addresses etc. If I wanted to\n\u003e really slow down communication over the P2P network, what's stopping me\n\u003e from popping up a heap of dummy nodes that do nothing more than exchange\n\u003e version and relay addresses, except I send addr messages with all 1000\n\u003e addresses pointing to my useless nodes that never send invs or respond to\n\u003e getdata etc so clients connect to my dumb nodes instead of legit ones. I'm\n\u003e thinking that if I fill up their address pool with enough addresses to dumb\n\u003e nodes and keep them really fresh time wise, it could have a bit of an\n\u003e impact especially if all 8 outbound connections are used up by my dumb\n\u003e nodes right?\n\u003e\n\u003e I don't want to do this obviously, I'm just thinking about it as I'm\n\u003e building my node, what is there to stop this happening?\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Dive into the World of Parallel Programming The Go Parallel Website,\n\u003e sponsored\n\u003e by Intel and developed in partnership with Slashdot Media, is your hub for\n\u003e all\n\u003e things parallel software development, from weekly thought leadership blogs\n\u003e to\n\u003e news, videos, case studies, tutorials and more. Take a look and join the\n\u003e conversation now. http://goparallel.sourceforge.net/\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150304/536a50fe/attachment.html\u003e",
"sig": "2555c7062cb598d99806182e9c9d56338141d854b1046088304a0707668454c0d2b7e3574d4cb84db657a5984d6504bff120807e7116983cfa4de46559399696"
}