< meshcollider> sipa: we do
< meshcollider> fanquake removes them whenever he sees them
< sipa> oh cool
< fanquake> Yea if you see I’ve edited a PR body, it’s generally either for that, or to fix up the issue auto-closing syntax.
< provoostenator> sipa: I generally don't do that, where did that happen?
< provoostenator> Auto-removing them from descriptions during merge makes sense. It would get awkward having to avoid tagging people in the description too.
< hebasto> fanquake: is Mine8801's activity in the bitcoin repo needed to be moderated?
< gleb> It seems like we currently dedicate 16 network groups to various Tor addresses. This means that we can end up exclusively connecting to 8 tor-routed AWS nodes. Am I correct? Should we reduce groups to 4 so that this can't happen? sipa
< bitcoin-git> [bitcoin] hebasto opened pull request #16643: doc: Add ZMQ dependencies to the Fedora build instructions (master...20190818-doc-fedora-zmq) https://github.com/bitcoin/bitcoin/pull/16643
< fanquake> hebasto: thanks, cleaned it up.
< sipa> provoostenator: yeah sorry for calling you out; it was only indirectly through PR description
< sipa> gleb: tor is annoying
< sipa> 16 is a lot for sure
< sipa> but if there are only 4, what happens if you're only able to make hidden service connections?
< gleb> Currently we would end up connecting to just 4 peers in that case. But it seems simple to adjust the code so that in this particular case we connect to as many as needed (8 or nMaxOutbound)
< gleb> Not sure if the problem is worth adding code.
< gleb> By currently I meant with 4 groups instead of 16.
< bitcoin-git> [bitcoin] GChuf opened pull request #16644: scripts: attempt to fix some translations in update-translations.py (master...patch-1) https://github.com/bitcoin/bitcoin/pull/16644
< sipa> gleb: i mean, say you only have onion addresses in addrman, what would happen?
< sipa> worst case it goes into an infinite loop
< sipa> best case it evetually ignores the grouping limit, and makes 8 outgoing connections still
< gleb> Yes, I think I know how to add couple lines to achieve the best case while limiting tor groups to 4
< sipa> gleb: it could even be progressive
< sipa> say you avtually make all of tor one group
< sipa> and initially limit to 1, but after a few failed attempts allow 2, etc
< gleb> Yeah, but I think it would be harder to diversify tor connections then lol
< sipa> i agree
< sipa> i don't know how to deal with it well
< sipa> but making tor 4 groups or 16, or whatever number different from 1 is artificial
< sipa> as spinning up infinity tor hidden services is cheap, regardless of what group they are in
< gleb> I still think that 4 is better than 16, but yeah, progressive is better than both. I’ll see how much code complexity is that tomorrow.
< achow101> Mine8801 is spamming the repo
< sipa> achow101: blocked
< emilengler> Is the blockchain download being done with multiple threads?
< sipa> yes and no
< sipa> p2p traffic is handled by one thread
< sipa> and processing and sending of protocol messages is done in one thread (but a different one from the p2p one)
< sipa> and script validation is done in multiple separate threads
< emilengler> sipa, By processing, do you mean writing to the disk as well?
< luke-jr> writing to the disk doesn't really benefit from multiple threads..
< emilengler> luke-jr, I was referring to the thread where it being done, in this case if it counts as processing
< sipa> "it" is multipke things
< sipa> block processing as a whole is single threaded
< sipa> but script validation is outsourced to separate script validation threads
< emilengler> Ok, I'm still a bit confused at the part where it writes the blocks to the disk. I still don't get which function is exactly responsible for this, there are so many (AcceptBlock, FlushStateToDisk, WriteBlockToDisk)
< sipa> writeblocktodisk writes a block to disk
< sipa> flushstatetodisk causes the chainstate to be written to disk
< sipa> acceptblock is a lot more high level; it deals with all parts of accepting a new block from anywhere
< sipa> in particular, acceptblock can deal with invalid blocks
< emilengler> sipa: Wow, thanks for this detailed answer :)
< kakobrekla> why can P2SH address can be equal length to P2PKH, but P2WSH not to P2WPKH
< harding> kakobrekla: that question (and any followups you have) may be better asked in #bitcoin. The answer is that P2WPKH uses a 20-byte hash RIPEMD(SHA256()) and P2WSH uses a 32-byte hash SHA256(). For details, see https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#P2WSH
< kakobrekla> tyvm
< bitcoin-git> [bitcoin] meshcollider pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/1124be6111d6...e8a6d5272465
< bitcoin-git> bitcoin/master c325f61 Andrew Chow: Return an error from descriptor Parse that gives more information about wh...
< bitcoin-git> bitcoin/master 625534d Andrew Chow: Give more errors for specific failure conditions
< bitcoin-git> bitcoin/master 6e1ae58 Andrew Chow: Check error messages in descriptor tests
< bitcoin-git> [bitcoin] meshcollider merged pull request #16542: Return more specific errors about invalid descriptors (master...descriptor-errors) https://github.com/bitcoin/bitcoin/pull/16542
< bitcoin-git> [bitcoin] jonatack opened pull request #16645: doc: initial RapidCheck property-based testing documentation (master...rapidcheck-documentation) https://github.com/bitcoin/bitcoin/pull/16645