29:I[49813,["/_next/static/chunks/3fntmmi971322.js","/_next/static/chunks/2z2rzbhvs4alm.js","/_next/static/chunks/2o8aqne6zrjpk.js","/_next/static/chunks/2rt30ysyypg2r.js","/_next/static/chunks/3vwx4w48i_94p.js","/_next/static/chunks/44hzt1esx8oc4.js","/_next/static/chunks/204ajj8ij30o4.js","/_next/static/chunks/12atl0av32l1x.js","/_next/static/chunks/1hqn9gft3gnvj.js"],"CodeWorkspace"] 2a:T48a,Merge bitcoin/bitcoin#36310: rpc: clarify that `getaddrmaninfo` counts unique addresses 0d34b6e9287f523adf1c85a05ada2ba21f0d820c rpc: clarify that getaddrmaninfo counts unique addresses (0xb10c) Pull request description: While using the `getaddrmaninfo` RPC for monitoring the sizes of my address managers, we noticed that it returns the count of unique addresses in the tables. While the addresses in the `tried` table are always unique, the `new` table might contain an address multiple times if we received it from sources in different network groups. I incorrectly assumed the returned values to be the number of address manager slots filled. To make this clearer for the next person, I'm clarifying this in the documentation. The number of filled addrman slots can be derived from the output of the hidden `getrawaddrman` RPC. ACKs for top commit: fjahr: ACK 0d34b6e9287f523adf1c85a05ada2ba21f0d820c stratospher: ACK 0d34b6e. danielabrozzoni: ACK 0d34b6e9287f523adf1c85a05ada2ba21f0d820c Tree-SHA512: 44c607ada730d7264cacd1ba8930cc60d84e59bc92e4e08b98f2453c951f2e0251707cd968bf39d544426a674b78aa5f99b8df08acc06201fceae423ffd814e22b:T22f4,// Copyright (c) 2017-present The Bitcoin Core developers // Distributed under the MIT software license, see the accompanying // file COPYING or http://www.opensource.org/licenses/mit-license.php. #include #include #include #include #include #include #include #include