💬 faca5 commented on issue "dumpprivkey - This type of wallet does not support this command (code -4)":
(https://github.com/bitcoin/bitcoin/issues/27693#issuecomment-1552713353)
Yes. It show list of descriptors.

⚠️ GregTonoski opened an issue: "QStandardPaths: runtime directory '/mnt/wslg/runtime-dir' is not owned by UID 0"
(https://github.com/bitcoin/bitcoin/issues/27694)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

There is the message after launching bitcoin-qt in Windows Subsystem for Linux:
```
# /usr/local/bin/b25/bitcoin-qt
QStandardPaths: runtime directory '/mnt/wslg/runtime-dir' is not owned by UID 0, but a directory permissions 0700 owned by UID 1000 GID 1000
```

Bitcoin-qt is launched successfully and runs smoothly despite the message.

### Expected behaviour

There isn't the unexpect
...

🤔 dergoegge reviewed a pull request: "fuzz: Print error message when FUZZ is missing"
(https://github.com/bitcoin/bitcoin/pull/27672#pullrequestreview-1432271319)
Concept ACK

💬 dergoegge commented on pull request "fuzz: Print error message when FUZZ is missing":
(https://github.com/bitcoin/bitcoin/pull/27672#discussion_r1197545568)
nit: Would it be good to hint at `PRINT_ALL_FUZZ_TARGETS_AND_ABORT=1` in the message?

💬 ajtowns commented on pull request "p2p: Stop relaying non-mempool txs":
(https://github.com/bitcoin/bitcoin/pull/27625#issuecomment-1552718608)
> How would you judge "relevant"? I presume you are looking for rbf'd transactions that were requested from mapRelay and ended up in a block, but the block was not yet available to you?

I'm still tweaking the logging, but so far what I'm seeing seems like roughly:

* 95% relay from the mempool
* of the 5% that don't:
* 87% are recent txs included in the most recent block (so would also be available via mapRelay)
* 12% are recent txs not in the most recent block, so only via mapRe
...

💬 GregTonoski commented on issue "dumpprivkey - This type of wallet does not support this command (code -4)":
(https://github.com/bitcoin/bitcoin/issues/27693#issuecomment-1552718812)
You will find the information about how to use the command at https://bitcoin.stackexchange.com/ and https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md
It is not simple enough to summarize in a sentence or two here.

💬 faca5 commented on issue "dumpprivkey - This type of wallet does not support this command (code -4)":
(https://github.com/bitcoin/bitcoin/issues/27693#issuecomment-1552722538)
Thank you.

✅ faca5 closed an issue: "dumpprivkey - This type of wallet does not support this command (code -4)"
(https://github.com/bitcoin/bitcoin/issues/27693)

💬 MarcoFalke commented on issue "QStandardPaths: runtime directory '/mnt/wslg/runtime-dir' is not owned by UID 0":
(https://github.com/bitcoin/bitcoin/issues/27694#issuecomment-1552733362)
https://stackoverflow.com/questions/72733724/qstandardpaths-runtime-directory-run-user-1000-is-not-owned-by-uid-0-but-a#comment131102495_72733724

💬 fanquake commented on issue "QStandardPaths: runtime directory '/mnt/wslg/runtime-dir' is not owned by UID 0":
(https://github.com/bitcoin/bitcoin/issues/27694#issuecomment-1552735362)
Should also be moved to the GUI repo.

✅ fanquake closed an issue: "QStandardPaths: runtime directory '/mnt/wslg/runtime-dir' is not owned by UID 0"
(https://github.com/bitcoin/bitcoin/issues/27694)

🤔 dergoegge reviewed a pull request: "ci: Add test coverage job"
(https://github.com/bitcoin/bitcoin/pull/27547#pullrequestreview-1432356263)
Concept ACK

Thank you for working on this, I think this would be valuable to have.

It seems like it would be easy to replace codecov with something we could host on our own infra (should that become necessary). For now codecov seems fine to me though.

> Read and write access to ... pull requests

Does this mean codecov can push changes to pull request or just that it can comment?

💬 dergoegge commented on pull request "ci: Add test coverage job":
(https://github.com/bitcoin/bitcoin/pull/27547#discussion_r1197600768)
Maybe add an option to skip this step? then devs could run this job locally, without it failing to upload the reports.

📝 MarcoFalke opened a pull request: " test: Add test to check tx in the last block can be downloaded "
(https://github.com/bitcoin/bitcoin/pull/27695)
If a peer received an `inv` about a transaction, which was included in a block before receiving the corresponding `getdata`, it can be beneficial to send this transaction to the peer to aid compact block relay.

Add a test for this to avoid breaking it in the future.

📝 hebasto opened a pull request: "build: Do not define `ENABLE_ZMQ` when ZMQ is not available"
(https://github.com/bitcoin/bitcoin/pull/27696)
A new behavior is consistent with the other optional dependencies.

The source code contains `#if ENABLE_ZMQ` lines only:
```
$ git grep ENABLE_ZMQ -- src/*.cpp
src/init.cpp:#if ENABLE_ZMQ
src/init.cpp:#if ENABLE_ZMQ
src/init.cpp:#if ENABLE_ZMQ
src/init.cpp:#if ENABLE_ZMQ
src/init.cpp:#if ENABLE_ZMQ
```

Change in description line -- "Define to 1..." --> "Define this symbol.." -- is motivated by the fact that the actual value of the defined `ENABLE_ZMQ` macro does not matter at all.
...

🚀 fanquake merged a pull request: "build: Bump minimum supported Clang to clang-10"
(https://github.com/bitcoin/bitcoin/pull/27682)

💬 fanquake commented on pull request "build: Bump minimum supported GCC to g++-9":
(https://github.com/bitcoin/bitcoin/pull/27662#issuecomment-1552830486)
Ok. Lets kill `l_filesystem.m4`.

💬 MarcoFalke commented on pull request "p2p: Stop relaying non-mempool txs":
(https://github.com/bitcoin/bitcoin/pull/27625#issuecomment-1552831521)
> I think I agree with https://github.com/bitcoin/bitcoin/pull/27625#issuecomment-1544047433 that we should ensure we serve any txs in the most recent block

Added a test for this in https://github.com/bitcoin/bitcoin/pull/27695, which should fail on this pull as is. I think the test only checks for `sendcmpct 0` (low bandwidth) behavior. And only for the case where the `tx`-`getdata` was already sent on the wire, because otherwise Bitcoin Core on current `master` would queue it behind the `cm
...

💬 brunoerg commented on pull request "fuzz: net, add `recv_flood_size`, `prefer_evict` in `ConsumeNode`":
(https://github.com/bitcoin/bitcoin/pull/27678#issuecomment-1552835319)
I noticed they were missing while working on net fuzzing improvement, so would be better to add them just when adding coverage for functions that use them?

💬 dergoegge commented on pull request "fuzz: net, add `recv_flood_size`, `prefer_evict` in `ConsumeNode`":
(https://github.com/bitcoin/bitcoin/pull/27678#issuecomment-1552837477)
> so would be better to add them just when adding coverage for functions that use them?

Yes I think that would be better, otherwise there is no need to add them.