< jnewbery>
Error is "ERROR: Qt binary download did not match the expected hash.". Is there some fix we need to backport to 0.20?
< aj>
jnewbery: i think that's an appveyor caching bug that just happens occassionally, and goes away about a day later? not sure
< wumpus>
oh no not appveyor caching problems again, I'm not aware of any recent patches in that regard no
< wumpus>
taking a look
< wumpus>
the last appveyor-related commit we backported to 0.20 was 961e667600441c35845fcb36b120500c813cd3ed, which removed most of the caching. There have been two other commits since: 3ec8f4c080eab61563f11659c5f1370a34b77dc5 and a104caeb4008a6e0726ba604ece6f53549110354.
< wumpus>
the first changes the version of VC used to the previous version, the other changes it back to the current one (as well as updates VCPKG_COMMIT_ID)
< wumpus>
I guess you could try backporting the combination of those (e.g. keep the VC version the same butchange VCPKG_COMMIT_ID), the reason to do it was unrelated to qt though
< wumpus>
but maybe it influences that too I don't know
< bitcoin-git>
[bitcoin] practicalswift opened pull request #20001: net: Use default proxy server (127.0.0.1:9050) if -proxy is specified without arguments (instead of continuing without proxy server) (master...use-localhost-instead-of-silently-skipping-proxy) https://github.com/bitcoin/bitcoin/pull/20001
< bitcoin-git>
[bitcoin] jonatack opened pull request #20002: net, rpc, cli: expose CNetAddr::GetNetClass in getpeerinfo, use in -netinfo (master...getpeerinfo-GetNetClass) https://github.com/bitcoin/bitcoin/pull/20002
< bitcoin-git>
[bitcoin] practicalswift closed pull request #20001: net: Use proxy server 127.0.0.1 if -proxy is specified without arguments (instead of continuing without proxy server) (master...use-localhost-instead-of-silently-skipping-proxy) https://github.com/bitcoin/bitcoin/pull/20001
< bitcoin-git>
[bitcoin] practicalswift opened pull request #20003: net: Print error message if -proxy is specified without arguments (instead of continuing without proxy server) (master...error-on-empty-proxy) https://github.com/bitcoin/bitcoin/pull/20003
< jnewbery>
aj wumpus: thanks! I'll try adding those commits to the backport PR. If it fixes the issue then I'll open a PR to backport them separately.
< vasild>
What are the benefits of configuring the tor hidden service in torrc instead of leaving bitcoind to automatically create it via tor-control?
< wumpus>
vasild: I don't know, it was the old way to do it, but I don't see much benefit--apart from transparency from the sysadmin side maybe (less moving parts, all configuration in one place), if you're configuring Tor for other things too
< wumpus>
jnewbery: ok, hope it helps
< wumpus>
vasild: in any case that's very much an edge case
< vasild>
hmm, if configured via torrc then bitcoind need not be supplied with tor-control auth
< vasild>
these tor-control credentials can do much more to the tor daemon than ask it to create a hidden service - shutdown or arbirary change of the configuration (like editing torrc)
< wumpus>
right
< vasild>
so, maybe not giving tor-control auth to bitcoind could be considered as a benefit
< wumpus>
yes, for advanced users
< wumpus>
I still think creating an onion service automatically is a good default though
< wumpus>
when bitcoind has those permissions
< wumpus>
but the manual way should keep being supported, if that's what you mean
< vasild>
hebasto: so, I think that if the option to specify the bind address is added to 19991 (and this also supplied to ADD_ONION of course), then 19991 will supersede #19043
< vasild>
-onionservicetarget=addr:port hmm, that is just another bind + a tag "anything incoming to this addr:port is incoming tor"
< vasild>
right?
< hebasto>
right
< vasild>
what about extending the -bind=addr:port option to something like -bind=addr:port[=tor], for example: -bind=1.2.3.4:8333 -bind=1.2.3.4:8334=tor
< vasild>
instead of adding a new option -onionservicetarget= ?
< wumpus>
making it an attribute makes sense
< wumpus>
(of the bind)
< vasild>
I don't know yet how i2p works, but if it works in a similar way (the i2p daemon connects to us, like in tor) then for i2p that would mean just recognizing =i2p in addition to recognizing =tor, instead of adding new option -i2pservicetarget=addr:port
< wumpus>
right, it's elegant way to think about it and allows for extensibility
< instagibbs>
anyone else getting noise on unit tests? "Error: Specified -walletdir "/tmp/test_bitcoin/1600886453_943311758/tempdir/path_does_not_exist" does not exist"
< instagibbs>
sounds like it's part of the test, but pretty noisy to print it :shrug:
< sipa>
hi
< sipa>
oh, oops, i thought it was thursday
< sipa>
MarcoFalke: any reason why qa-assets can't be cloned with --depth=1 or so?
< sipa>
that would avoid pulling in all of its history