✅ achow101 closed an issue: "RPC `getblock` resulted in 500 and ReadBlockFromDisk: OpenBlockFile failed for FlatFilePos(nFile=-1, nPos=0)"
(https://github.com/bitcoin/bitcoin/issues/20978)
(https://github.com/bitcoin/bitcoin/issues/20978)
🚀 achow101 merged a pull request: "rpc, rest: Improve block rpc error handling, check header before attempting to read block data."
(https://github.com/bitcoin/bitcoin/pull/30410)
(https://github.com/bitcoin/bitcoin/pull/30410)
💬 davidgumberg commented on pull request "streams: cache file position within AutoFile":
(https://github.com/bitcoin/bitcoin/pull/30884#discussion_r1761938767)
That makes sense, I didn't consider pipes/fifos.
I agree on this approach given that a bad `m_position` value is only an issue when XOR'ing, and your branch has checks for an unknown `m_position` before any XOR operations. And in general, it seems to me, `ftell`'s are followed by file operations that fail if the `ftell` fails for any reason other than the file being a pipe/fifo (`ESPIPE`).
I think ideally `errno` is checked here for values other than `ESPIPE`, but the current approach is
...
(https://github.com/bitcoin/bitcoin/pull/30884#discussion_r1761938767)
That makes sense, I didn't consider pipes/fifos.
I agree on this approach given that a bad `m_position` value is only an issue when XOR'ing, and your branch has checks for an unknown `m_position` before any XOR operations. And in general, it seems to me, `ftell`'s are followed by file operations that fail if the `ftell` fails for any reason other than the file being a pipe/fifo (`ESPIPE`).
I think ideally `errno` is checked here for values other than `ESPIPE`, but the current approach is
...
💬 sipa commented on pull request "cluster mempool: extend DepGraph functionality":
(https://github.com/bitcoin/bitcoin/pull/30857#issuecomment-2353995596)
Rebased after merge of #30286.
(https://github.com/bitcoin/bitcoin/pull/30857#issuecomment-2353995596)
Rebased after merge of #30286.
💬 jonatack commented on pull request "doc: fixed inconsistencies in documentation between autotools to cmake change":
(https://github.com/bitcoin/bitcoin/pull/30875#discussion_r1761946005)
`s/for a non-debug build by running build with/by building/`
(https://github.com/bitcoin/bitcoin/pull/30875#discussion_r1761946005)
`s/for a non-debug build by running build with/by building/`
💬 jonatack commented on pull request "doc: fixed inconsistencies in documentation between autotools to cmake change":
(https://github.com/bitcoin/bitcoin/pull/30875#discussion_r1761946108)
```suggestion
This can be checked by building the `translate` package with `cmake` ([instructions](translation_process.md)), then verifying that `bitcoin_en.ts` remains unchanged.
```
(nano-nit, "cmake" is written without the backticks in other documents; could be consistent, also regarding referring to it as "cmake" or "CMake")
(https://github.com/bitcoin/bitcoin/pull/30875#discussion_r1761946108)
```suggestion
This can be checked by building the `translate` package with `cmake` ([instructions](translation_process.md)), then verifying that `bitcoin_en.ts` remains unchanged.
```
(nano-nit, "cmake" is written without the backticks in other documents; could be consistent, also regarding referring to it as "cmake" or "CMake")
💬 achow101 commented on pull request "net: call `Select` with reachable networks in `ThreadOpenConnections`":
(https://github.com/bitcoin/bitcoin/pull/29436#issuecomment-2354004288)
ACK e4e3b44e9cc7227b3ad765397c884999f57bac2e
(https://github.com/bitcoin/bitcoin/pull/29436#issuecomment-2354004288)
ACK e4e3b44e9cc7227b3ad765397c884999f57bac2e
💬 jonatack commented on pull request "doc: fixed inconsistencies in documentation between autotools to cmake change":
(https://github.com/bitcoin/bitcoin/pull/30875#discussion_r1761947070)
```suggestion
print("Re-compile with the -DBUILD_DAEMON=ON build option")
```
(https://github.com/bitcoin/bitcoin/pull/30875#discussion_r1761947070)
```suggestion
print("Re-compile with the -DBUILD_DAEMON=ON build option")
```
🚀 achow101 merged a pull request: "net: call `Select` with reachable networks in `ThreadOpenConnections`"
(https://github.com/bitcoin/bitcoin/pull/29436)
(https://github.com/bitcoin/bitcoin/pull/29436)
💬 petertodd commented on issue "Use IPv4-encoded IPv6 address to get IPv4 node address with port number from DNS seeds":
(https://github.com/bitcoin/bitcoin/issues/30900#issuecomment-2354009797)
NACK
The purpose of the DNS seeds is just to find some bootstrap nodes. More addresses are then learned from those bootstrap nodes, and additional connections are made to them. There's no need for the initial bootstrap nodes to be sampled from the entire set of possible nodes.
(https://github.com/bitcoin/bitcoin/issues/30900#issuecomment-2354009797)
NACK
The purpose of the DNS seeds is just to find some bootstrap nodes. More addresses are then learned from those bootstrap nodes, and additional connections are made to them. There's no need for the initial bootstrap nodes to be sampled from the entire set of possible nodes.
💬 furszy commented on pull request "Fix crash when closing wallet":
(https://github.com/bitcoin-core/gui/pull/835#issuecomment-2354051227)
A bit delayed but here. Sorry.
About your fix, I'm not against it at all. Fully agree that is better than mine. Connecting the signal handler lifetime to the object that it deletes it is what we should be doing.
I think removing the wallet from the GUI early in the process is effective, but it doesn't handle failures well, as we'd need to reload all wallet views from scratch. That said, disabling all wallet actions in the GUI might be a bit tricky to implement with the current code. Still
...
(https://github.com/bitcoin-core/gui/pull/835#issuecomment-2354051227)
A bit delayed but here. Sorry.
About your fix, I'm not against it at all. Fully agree that is better than mine. Connecting the signal handler lifetime to the object that it deletes it is what we should be doing.
I think removing the wallet from the GUI early in the process is effective, but it doesn't handle failures well, as we'd need to reload all wallet views from scratch. That said, disabling all wallet actions in the GUI might be a bit tricky to implement with the current code. Still
...
🤔 jonatack reviewed a pull request: "net: call `Select` with reachable networks in `ThreadOpenConnections`"
(https://github.com/bitcoin/bitcoin/pull/29436#pullrequestreview-2307843032)
(Happy to re-review if you squash the minor comments below into https://github.com/bitcoin/bitcoin/pull/30183.)
(https://github.com/bitcoin/bitcoin/pull/29436#pullrequestreview-2307843032)
(Happy to re-review if you squash the minor comments below into https://github.com/bitcoin/bitcoin/pull/30183.)
💬 jonatack commented on pull request "net: call `Select` with reachable networks in `ThreadOpenConnections`":
(https://github.com/bitcoin/bitcoin/pull/29436#discussion_r1761957463)
Missing `#include <unordered_set>` in this file (include what you use)
```
/src/addrman.cpp should add these lines:
#include <algorithm> // for max, min
#include <compare> // for operator<, strong_ordering, operator>, operator<=
#include <iterator> // for advance
#include <ratio> // for ratio
#include <set> // for set, _Rb_tree_const_iterator, operator==
#include <unordered_map> // for un
...
(https://github.com/bitcoin/bitcoin/pull/29436#discussion_r1761957463)
Missing `#include <unordered_set>` in this file (include what you use)
```
/src/addrman.cpp should add these lines:
#include <algorithm> // for max, min
#include <compare> // for operator<, strong_ordering, operator>, operator<=
#include <iterator> // for advance
#include <ratio> // for ratio
#include <set> // for set, _Rb_tree_const_iterator, operator==
#include <unordered_map> // for un
...
💬 jonatack commented on pull request "net: call `Select` with reachable networks in `ThreadOpenConnections`":
(https://github.com/bitcoin/bitcoin/pull/29436#discussion_r1761961810)
```suggestion
for (Network net : ALL_NETWORKS) {
```
(https://github.com/bitcoin/bitcoin/pull/29436#discussion_r1761961810)
```suggestion
for (Network net : ALL_NETWORKS) {
```
💬 jonatack commented on pull request "net: call `Select` with reachable networks in `ThreadOpenConnections`":
(https://github.com/bitcoin/bitcoin/pull/29436#discussion_r1761960091)
A `Network` is a cheaply-copied int enum; no need to use it by reference, unless I'm missing something.
```suggestion
for (Network network : networks) {
```
(https://github.com/bitcoin/bitcoin/pull/29436#discussion_r1761960091)
A `Network` is a cheaply-copied int enum; no need to use it by reference, unless I'm missing something.
```suggestion
for (Network network : networks) {
```
💬 willcl-ark commented on pull request "build: speed up by flattening the dependency graph":
(https://github.com/bitcoin/bitcoin/pull/30911#issuecomment-2354055700)
Concept ACK.
I noticed a bit of a "gap" in our compilation on master the other day."

This PR appears to fix it quite nicely:

I didn't see quite the same speedup as you though, but will investigate and do some more thorough testing/review tomorrow.
These tests were also using a def
...
(https://github.com/bitcoin/bitcoin/pull/30911#issuecomment-2354055700)
Concept ACK.
I noticed a bit of a "gap" in our compilation on master the other day."

This PR appears to fix it quite nicely:

I didn't see quite the same speedup as you though, but will investigate and do some more thorough testing/review tomorrow.
These tests were also using a def
...
💬 jonatack commented on pull request "cli: improve error message on multiwallet and add validation to cli-side commands":
(https://github.com/bitcoin/bitcoin/pull/26990#issuecomment-2354059450)
On my short list to re-review.
(https://github.com/bitcoin/bitcoin/pull/26990#issuecomment-2354059450)
On my short list to re-review.
💬 achow101 commented on pull request "refactor: TxDownloadManager + fuzzing":
(https://github.com/bitcoin/bitcoin/pull/30110#discussion_r1761911213)
In ecbbadf0f79bb32730d9e1400d84b84893e35e56 "[refactor] add TxDownloadManager wrapping TxOrphanage, TxRequestTracker, and bloom filters"
Why have this bloom filter's parameters changed? It was previously `48'000` and `0.000'001`. If this was intentional, it should probably be a separate commit and a rationale provided.
(https://github.com/bitcoin/bitcoin/pull/30110#discussion_r1761911213)
In ecbbadf0f79bb32730d9e1400d84b84893e35e56 "[refactor] add TxDownloadManager wrapping TxOrphanage, TxRequestTracker, and bloom filters"
Why have this bloom filter's parameters changed? It was previously `48'000` and `0.000'001`. If this was intentional, it should probably be a separate commit and a rationale provided.
💬 achow101 commented on pull request "refactor: TxDownloadManager + fuzzing":
(https://github.com/bitcoin/bitcoin/pull/30110#discussion_r1761957878)
In c40cb8565952f62732fa64875c99ef9082b9a6f4 "[refactor] move notfound processing to txdownload"
nit:
```suggestion
for (const auto& txhash : txhashes) {
```
(https://github.com/bitcoin/bitcoin/pull/30110#discussion_r1761957878)
In c40cb8565952f62732fa64875c99ef9082b9a6f4 "[refactor] move notfound processing to txdownload"
nit:
```suggestion
for (const auto& txhash : txhashes) {
```
💬 achow101 commented on pull request "refactor: TxDownloadManager + fuzzing":
(https://github.com/bitcoin/bitcoin/pull/30110#discussion_r1761978429)
In f3cc6322798ca61a31f90b2ad7a0c32471db0410 "[refactor] move new tx logic to txdownload"
nit:
```suggestion
m_txrequest.ReceivedResponse(nodeid, txid);
if (ptx->HasWitness()) m_txrequest.ReceivedResponse(nodeid, wtxid);
```
(https://github.com/bitcoin/bitcoin/pull/30110#discussion_r1761978429)
In f3cc6322798ca61a31f90b2ad7a0c32471db0410 "[refactor] move new tx logic to txdownload"
nit:
```suggestion
m_txrequest.ReceivedResponse(nodeid, txid);
if (ptx->HasWitness()) m_txrequest.ReceivedResponse(nodeid, wtxid);
```