< bitcoin-git>
[bitcoin] robot-dreams closed pull request #19968: doc: make it easier to work out size of bloom filter (master...bloom-doc) https://github.com/bitcoin/bitcoin/pull/19968
< bitcoin-git>
[bitcoin] robot-dreams reopened pull request #19968: doc: make it easier to work out size of bloom filter (master...bloom-doc) https://github.com/bitcoin/bitcoin/pull/19968
< bitcoin-git>
bitcoin/master 7eab781 Wladimir J. van der Laan: rpc: Set HTTP Content-Type in bitcoin-cli
< bitcoin-git>
bitcoin/master 60ec57b fanquake: Merge #20055: rpc: Set HTTP Content-Type in bitcoin-cli
< bitcoin-git>
[bitcoin] fanquake merged pull request #20055: rpc: Set HTTP Content-Type in bitcoin-cli (master...2020_10_cli_contenttype) https://github.com/bitcoin/bitcoin/pull/20055
< vasild>
it just occurred to me that when -bind=127.0.0.1:1234 is specified (port is present, no -port= is given), then GetListenPort() will wrongly return 8333
< vasild>
in this case nobody is listening on 8333, but we do AddLocal() and tor's ADD_ONION with 8333
< hebasto>
vasild: on master?
< vasild>
yes, on master
< sipa>
vasild: just because the port part of -bind is ignored?
< vasild>
sipa: ignored by GetListenPort(), but not by the binding code which will actually correctly bind to 1234
< vasild>
ok, AddLocal() will do nothing with 127.0.0.1, but same applies for a routable address, e.g. --bind=15.16.17.18:1234 will advertise himself to peers as 15.16.17.18:8333 where nobody is listening
< vasild>
bitcoind --bind=127.0.0.1:1234
< vasild>
...
< vasild>
2020-10-02T09:13:44Z tor: Got service ID izwdtn2vqpviyyqmhopz5yxstnq62vlhzpbcx5oexjoo4lf2bhwxulqd, advertising service izwdtn2vqpviyyqmhopz5yxstnq62vlhzpbcx5oexjoo4lf2bhwxulqd.onion:8333
< wumpus>
yes, i think the thing is that -port is a leftover from when it was only possible to bind to one address, when you bind to a series of addresses there is no "GetListenPort" but multiple so the concept doesn't make that much sense
< wumpus>
as i understand it it's kind of a default
< wumpus>
but it's definitely possible something goes wrong with advertising those; it's *very* uncommon to listen on non-standard ports, let alone multiple different ports, wouldn't imagine it's a very well tested scenario
< hebasto>
windows shutdown issue #20052 seems being resolved
< wumpus>
hebasto: great! i think the remaining question is 'can we do anything to make it work for shutdown /s', or is it some kind of forced emergency shutdown that intentionally bypasses running applications
< wumpus>
in any case good to know it isn't a regression!
< hebasto>
`shutdown /s` warns user rather apps :)
< wumpus>
oh!
< wumpus>
in that case I agree the issue is resolved
< hebasto>
wumpus: begging for re-reviewing #19991
< bitcoin-git>
[bitcoin] laanwj merged pull request #19991: net: Use alternative port for incoming Tor connections (master...200922-tor) https://github.com/bitcoin/bitcoin/pull/19991
< hebasto>
wumpus: ^ thank you!
< wumpus>
thank you for working on it, it has been on my list for so long
< ariard>
#19871 might be rfm, it's a doc-fix, has 2 ACKs and all tests okay
< gribble>
https://github.com/bitcoin/bitcoin/issues/19871 | doc: Clarify scope of eviction protection of outbound block-relay peers by ariard · Pull Request #19871 · bitcoin/bitcoin · GitHub
< wumpus>
ariard: thanks, will take a look
< ariard>
thanks you
< vasild>
gleb: sipa: what is your opinion on https://github.com/bitcoin/bitcoin/pull/19043#issuecomment-702740744 ? Short story - currently we relay routable addresses (reachable or not) and add to addrman reachable addresses (routable or not) (huh!?). Should we do the same with I2P addresses in 0.21? They will be routable and not reachable.
< instagibbs>
hebasto, github deemed a money service business, sad
< hebasto>
there was a recent change that could be related #19960
< gribble>
https://github.com/bitcoin/bitcoin/issues/19960 | build: The vcpkg tool has introduced a proper way to use manifests by sipsorcery · Pull Request #19960 · bitcoin/bitcoin · GitHub
< dhruvm>
Is there any downside to disabling DNS seeds(it is only soft disabled today) altogether when a node is using -connect?
< dhruvm>
So if the user specifies `-connect -dnsseed=1`, the dns seeds are still exercised but addrman will not be used.
< wumpus>
true, but there's probably a zillion different combinations of options that don't make, or don't seem to make sense, I don't think there's any reason to prevent a user from doing that if they really want to. As you say the default is already to disable it...
< dhruvm>
wumpus: ok, thanks
< amiti>
wumpus: you think its valuable to keep kinda-nonsensical combinations of init options around for users incase they _really_ want to? I tend towards valuing simplification / usability. ofc whether or not its a worthwhile PR to propose is a separate question.
< amiti>
I personally feel like it'd be nice to move towards simplifying options for node operators as we make other changes over time
< instagibbs>
amiti, most people run defaults, for those who want to twiddle, we should let them unless it's an inherently dangerous combination?
< instagibbs>
sensible defaults are another argument, but if users are explicitly asking for it...
< fjahr>
Brief note that there is a new label called "Good first review" now. Rationale can be found in the corresponding issue: #19941