比特幣如何通過 addr p2p 消息類型防止 DDoS 放大？
如果我沒記錯的話，主線 bitcoind 將接受未經請求的
addr消息，並且在收到此消息後 - 結構被反序列化，然後驗證來自未經請求的發件人的每個地址。該addr結構允許多達 1,000 個任意addresses:port元組，並且沒有埠限制……那麼究竟是什麼阻止了攻擊者將 100k 左右的 Bitciond 節點與地址氾濫到 80 和 443 上的某些目標 Web 伺服器？…為了使事情更容易被濫用，客戶端會在知情的情況下接受未來起草的資訊，並且無論錯誤如何都會重試 3 次——即使是協議不匹配也是如此。這意味著泛洪控制平面服務（如 sshd 或 vpn 甚至整個 IP 範圍的服務）可能會給網路覆蓋範圍大的目標實體帶來很多問題。
在DC++ 網路上利用了與此類似的問題。
很長一段時間以來，強烈傾向於連接到具有埠 8333 的地址的限制。最近在PR 23542和PR 23306中刪除了此限制，儘管引入了比特幣核心節點仍會避免連接的“壞埠”列表至。
如果您向節點發送地址，它通常會將其保存在 AddrMan 數據庫的新表中（如果與現有表沒有衝突），但不會自動連接到它。當他們的出站連接少於預設的 10 個並且因此需要更多時，或者當他們進行定期的試探連接時，這可能會在稍後發生。但是由於地址一直在比特幣網路上被八卦，他們會知道成千上萬個潛在的對等方，所以他們只會以很低的機率連接到受害者的特定地址。
因此，即使您將受害者的地址發送到所有比特幣節點，這並不意味著它們會收到如此多的連接，從而構成 DoS 攻擊。vasild在這篇文章中進行了粗略的計算，得出的結論是，即使在節點一直建立新連接的不切實際的情況下，受害者將接收到的連接嘗試次數約為每秒 2 次。實際上，它應該少得多，因為節點不會一直建立連接——受害者可能會偶爾從比特幣節點獲得連接嘗試，但沒有任何東西可以被視為 DDoS 攻擊。
另請注意，您來自 OP的驗證連結
AddrMan::Unserialize()是該功能的一部分，僅用於在啟動時從 peers.dat 文件中載入保存的地址，AddrMan 中從對等方接收地址時執行的功能是AddrMan::Add().