< 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