📝 fanquake opened a pull request: "doc: correct sqlite & qrencode versions used in depenendencies.md"
(https://github.com/bitcoin/bitcoin/pull/27441)
Followup to https://github.com/bitcoin/bitcoin/pull/27312 & https://github.com/bitcoin/bitcoin/pull/25378.

💬 josibake commented on pull request "contrib: followups to #27358 (verify-binaries)":
(https://github.com/bitcoin/bitcoin/pull/27440#discussion_r1161266740)
not introduced in this PR, but this is still broken (22.0-rc2)

```
[ERROR] failed to download aarch64-linux-gnu/bitcoin-22.0rc2-aarch64-linux-gnu.tar.gz
wget output:
aarch64-linux-gnu/bitcoin-22.0rc2-aarch64-linux-gnu.tar.gz: No such file or directory
```

💬 fanquake commented on pull request "contrib: followups to #27358 (verify-binaries)":
(https://github.com/bitcoin/bitcoin/pull/27440#discussion_r1161267379)
Looks like this is due to an extra level of nesting in the bitcoincore.org directory structure, which is only present for the 22.0 rc2 bins. Just changed this to rc3, which doesn't have the issue.

💬 josibake commented on pull request "contrib: followups to #27358 (verify-binaries)":
(https://github.com/bitcoin/bitcoin/pull/27440#issuecomment-1501104757)
ACK https://github.com/bitcoin/bitcoin/pull/27440/commits/ad841608d4edf6151b60e483793f60ba9f03cdbf

looks good, ran through the steps in the docs, grepped to make sure there are no references to `verifybinaries`

💬 josibake commented on pull request "contrib: followups to #27358 (verify-binaries)":
(https://github.com/bitcoin/bitcoin/pull/27440#discussion_r1161268754)
ah, so the script is dependent on the folder structure at bitcoincore.org.. @Sjors mentioned maybe adding a domain argument, but that won't work unless all domains use the same folder structures.

⚠️ Farxial opened an issue: "Add parallelism for downloading the blockchain"
(https://github.com/bitcoin/bitcoin/issues/27442)
### Please describe the feature you'd like to see added.

Please add parallelism (at least, multithreading; multithreading + some kind of clustering are better) for downloading blockchain by client/wallet (required by `getblocktemplate`).
**The speed of downloading the blockchain of Bitcoin is very slow, so much time is required, it's absolutely awful. And the further, the worse.**
As I can understand, it happens because of nature of blockchain processing: first, client must check block N cont
...

👍 hebasto approved a pull request: "doc: correct sqlite & qrencode versions used in depenendencies.md"
(https://github.com/bitcoin/bitcoin/pull/27441#pullrequestreview-1376904741)
ACK a12d9cfa46ad5f5a5144daabbc146d0175642c69, I have reviewed the code and it looks OK, I agree it can be merged.

💬 pinheadmz commented on issue "Add parallelism for downloading the blockchain":
(https://github.com/bitcoin/bitcoin/issues/27442#issuecomment-1501139997)
This might be a better question for https://bitcoin.stackexchange.com, I think if you search that knowledgebase for topics like `assumevalid` and `headers first sync` (download blocks from multiple peers) you'll find that IBD already has many optimizations of the kind you are describing. Assume valid in particular is *optional* because it skips validation on most blocks in the chain "even though" that carries a security compromise with it.

💬 sipa commented on issue "Add parallelism for downloading the blockchain":
(https://github.com/bitcoin/bitcoin/issues/27442#issuecomment-1501143631)
There are already two types of parallel processing involved in the initial block download mechanism:
* Blocks are downloaded from multiple peers in parallel, fetching one up to a few blocks per peer at a time, from a moving window of the next 1024 blocks.
* Script validation of blocks is performed in parallel on multiple CPU cores (splitting the work for any one single block). This only has an effect during the final blocks in the chain after the assumevalid point, because before, so script vali
...

👍 vasild approved a pull request: "doc: FreeBSD DataDirectoryGroupReadable Setting"
(https://github.com/bitcoin/bitcoin/pull/26741#pullrequestreview-1376920521)
ACK 499c46439418237a77c2a764cde47ad8dc893b0f

✅ fanquake closed an issue: "Add parallelism for downloading the blockchain"
(https://github.com/bitcoin/bitcoin/issues/27442)

💬 Farxial commented on issue "Add parallelism for downloading the blockchain":
(https://github.com/bitcoin/bitcoin/issues/27442#issuecomment-1501147793)
@pinheadmz
Sometime I tried `assumevalid`, but it didn't help me. May be I tried wrong? OK then, I will try this on next full synching, if you insist. _Does this work with **prune** blockchain synching?_
I can't find how to download from multiple peers on request `headers first sync`. Can you tell a launch option, please?
And, of course, it would be nice to find such an option in the output of `bitcoind --help`.

@sipa
I see...

Thanks for the info both of you.

💬 pinheadmz commented on issue "Add parallelism for downloading the blockchain":
(https://github.com/bitcoin/bitcoin/issues/27442#issuecomment-1501149253)
By default, the first `751565` blocks are assumed valid, without any user setting:

https://github.com/bitcoin/bitcoin/blob/db720b5a703c90625fa7a4773bd2db5672427cbe/src/kernel/chainparams.cpp#L107

Parallel download is also the default, see `FindNextBlocksToDownload()`:

https://github.com/bitcoin/bitcoin/blob/master/src/net_processing.cpp#L1298

💬 sipa commented on issue "anchors.dat doesn't support V2 addresses":
(https://github.com/bitcoin/bitcoin/issues/20511#issuecomment-1501155107)
@pinheadmz I think so.

👍 jarolrod approved a pull request: "doc: correct sqlite & qrencode versions used in depenendencies.md"
(https://github.com/bitcoin/bitcoin/pull/27441#pullrequestreview-1376932590)
ACK a12d9cfa46ad5f5a5144daabbc146d0175642c69

:lock: fanquake locked an issue: "I forgot the password of one of my wallets on Bitcoin Core App"
(https://github.com/bitcoin/bitcoin/issues/27421)

🚀 fanquake merged a pull request: "doc: FreeBSD DataDirectoryGroupReadable Setting"
(https://github.com/bitcoin/bitcoin/pull/26741)

👍 martinus approved a pull request: "refactor: Make `CCheckQueue` RAII-styled"
(https://github.com/bitcoin/bitcoin/pull/26762#pullrequestreview-1377151234)
Code review ACK 51f91c2c5bd, as far as I can say now deadlocks are not possible any more when shutting down. I started an initial sync with `-assumevalid=0` so script checks are done, stopping the process a few times with Ctrl+C, all good; shutdown is still quick. `-par` still works too.

💬 martinus commented on pull request "refactor: Make `CCheckQueue` RAII-styled":
(https://github.com/bitcoin/bitcoin/pull/26762#discussion_r1161479180)
nit, just a thought: maybe it would make sense to have a method like `signalStop()` or similar in `CCheckQueue` that only sets `m_request_stop` to true, and call this as soon as we know we don't need the queue's result any more. That way the threads will stop processing and stop wasting CPU while shutting down.

On the other hand the queue will usually pretty quickly stop working unless it has lots of work items, so I guess in most cases this wouldn't make any difference.

💬 MarcoFalke commented on pull request "test: LLVM/Clang 16 for MSAN jobs":
(https://github.com/bitcoin/bitcoin/pull/27436#discussion_r1161589201)
```suggestion
cmake -B "${BASE_SCRATCH_DIR}"/msan/build/ -DLLVM_ENABLE_RUNTIMES='libcxx;libcxxabi' -DCMAKE_BUILD_TYPE=Release -DLLVM_USE_SANITIZER=MemoryWithOrigins -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=OFF -S "${BASE_SCRATCH_DIR}"/msan/llvm-project/runtimes
```

nit?