💬 ismaelsadeeq commented on pull request "test: add coverage to rpc_scantxoutset.py":
(https://github.com/bitcoin/bitcoin/pull/27422#issuecomment-1500982428)
Yes can be something like
`assert_raises_rpc_error(-8, "Invalid action 'word'", self.nodes[0].scantxoutset, "word")`

🤔 kouloumos reviewed a pull request: "tracing: Only prepare tracepoint arguments when actually tracing"
(https://github.com/bitcoin/bitcoin/pull/26593#pullrequestreview-1376804705)
<details><summary> I've measured the number of executed instructions for each tracepoint based on the current and new implementation and verified that the overhead for tracepoints' arguments preparation - when enabled but not hooked - has been eliminated. Click to expand for details. </summary>
<br/>

master (49b87bfe7e2799d25ce709123ecafa872b36e87a)

Tracepoint|Disabled|Enabled (not hooked)|Enabled (hooked)
:---|:---|:---|:---
mempool:added|1|24|24
mempool:removed|1|136|136
mempool:rep
...

💬 kouloumos commented on pull request "tracing: Only prepare tracepoint arguments when actually tracing":
(https://github.com/bitcoin/bitcoin/pull/26593#discussion_r1161156029)
Regarding listing available tracepoints, there is another addition when using `info probes` in `gdb`, which now also shows semaphores. A snippet from my binary:
```
(gdb) info probes
Type Provider Name Where Semaphore Object
stap net inbound_message 0x00005625b02d4106 0x0000000000ab1724 /src/bitcoind
stap net outbound_message 0x00005625b029f395 0x0000000000ab1722 /src/bitcoind
stap validation block_connected 0x00005625b04b914d 0x00000000
...

💬 kouloumos commented on pull request "tracing: Only prepare tracepoint arguments when actually tracing":
(https://github.com/bitcoin/bitcoin/pull/26593#discussion_r1161158136)
I see that there is a `PASTE` macro that can be used instead of directly using the token-pasting operator (##), but I can't figure out why it exists and if it offers any advantage.
https://github.com/bitcoin/bitcoin/blob/db720b5a703c90625fa7a4773bd2db5672427cbe/src/util/macros.h#L8

💬 dhruv commented on pull request "rpc: simpler setban and new ban manipulation commands":
(https://github.com/bitcoin/bitcoin/pull/19825#issuecomment-1501027430)
I'm ok with marking this up for grabs or closing it.

✅ dhruv closed a pull request: "rpc: simpler setban and new ban manipulation commands"
(https://github.com/bitcoin/bitcoin/pull/19825)

📝 fanquake opened a pull request: "contrib: followups to #27358 (verify-binaries)"
(https://github.com/bitcoin/bitcoin/pull/27440)
Followup to #27358, fixing up the example command docs and other requests. See https://github.com/bitcoin/bitcoin/pull/27358#issuecomment-1500389847.

💬 fanquake commented on pull request "contrib: allow multi-sig binary verification v2":
(https://github.com/bitcoin/bitcoin/pull/27358#discussion_r1161264962)
See 27440.

💬 fanquake commented on pull request "contrib: allow multi-sig binary verification v2":
(https://github.com/bitcoin/bitcoin/pull/27358#discussion_r1161264975)
done in 27440

💬 fanquake commented on pull request "contrib: allow multi-sig binary verification v2":
(https://github.com/bitcoin/bitcoin/pull/27358#discussion_r1161264990)
added to 27440.

💬 fanquake commented on pull request "contrib: allow multi-sig binary verification v2":
(https://github.com/bitcoin/bitcoin/pull/27358#issuecomment-1501099918)
Covered most of the followup requests in #27440.

📝 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
...