< bitcoin-git>
[bitcoin] jnewbery opened pull request #20599: [net processing] Tolerate sendheaders and sendcmpct messages before verack (master...2020-12-tolerate-early-send-messages) https://github.com/bitcoin/bitcoin/pull/20599
< vasild>
What about a rpc to retrieve the contents of addrman (all usually 50k+ addresses)?
< wumpus>
it would be kind of memory inefficient, there's not really a good way to do streaming data unfortunately, I tried this with the utxo set once but ran into issues with evhttp, that said, addrman data is smaller than that
< vasild>
yeah, it is going to be a hog
< vasild>
another option is to devise a standalone tool that parses and prints the contents of peers.dat (would be good enough for debugging purposes and answering "how many torv3 addresses does my node know about?")
< wumpus>
we don't have any RPC methods athat return a lot of data, you wouldn't anyone to e.g. run it accidentally run it in the qt console...
< wumpus>
maybe a RPC that returns addrman *statistics*?
< wumpus>
I agree if you want to do processing with the raw data, might as well use an external tool
< vasild>
yes, statistics/summarized data seems to be more of something that could be generally useful to wider audience
< vasild>
right now I have a very simple/crude patch that prints all the addresses to stdout during startup
< jnewbery>
vasild: You're looking for getnodeaddresses. It's allowed fetching all addrman addresses since #19658
< gribble>
https://github.com/bitcoin/bitcoin/issues/19658 | [rpc] Allow RPC to fetch all addrman records and add records to addrman by jnewbery · Pull Request #19658 · bitcoin/bitcoin · GitHub
< jnewbery>
vasild: this is old and hasn't been updated in a long time, but it used to be able to parse peers.dat files: https://github.com/jnewbery/bitcointools . Doesn't support addrv2, but PRs are welcome
< jonatack>
vasild: yes, the only tor v3 peers i have are the half-dozen i manually connect to
< jonatack>
maybe there aren't any others
< vasild>
hmm
< jonatack>
(i tried to promote testing rc2 on twitter over the weekend, and specifically mentioned testing tor v3 among other things, but there was not a big reaction. jarolrod and hebasto exchanged tor v3 addrs with me.)
< vasild>
unless my node is connected directly to some addrv2-supporting node, there is no chance it would get any torv3 addresses
< vasild>
I guess this issue will dissapear by itself in a few years...
< wumpus>
I don't think it'll take so long, I mean, everyone using tor will have to upgrade at least
< jonatack>
yes
< vasild>
yeah, I was half joking
< wumpus>
heh
< bitcoin-git>
[bitcoin] jarolrod opened pull request #20601: doc: Update for FreeBSD 12.2, add GUI Build Instructions (master...master) https://github.com/bitcoin/bitcoin/pull/20601
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #20602: util: Allow use of C++14 chrono literals (master...2012-chronoLiterals) https://github.com/bitcoin/bitcoin/pull/20602
< queip>
some users looking at bitcoin-qt have a feeling that node "is stuck". Perhaps GUI is not re-assuring enough progress is happening. This leads to second problem: "bored" users then look into debug.log and some of normal messages look "worrying" like the ones with invalid blocks, rejected peers (result of forkcoin peers). Apparently some users think node is not working and seek help then
< queip>
I wonder if some GUI change, and warning message wording, could be helpful. Myself I was a bit concerned with some of the warnings before, with unknown bits (signaling?) hmm
< sipa>
i think there is some work on reducing the default log output for innocent situations