💬 fanquake commented on pull request "build: Introduce CMake-based build system":
(https://github.com/bitcoin/bitcoin/pull/30454#discussion_r1707417887)
I think we can just drop include checks like this (which don't produce defines used anywhere else in the codebase). I realise this kind of check was ported from Autotools, but I no-longer think it's necessary to do. Running a check to see if we can include `string.h`, just to then immediately compile something which includes `string.h`, seems like it should just be collapsed down to the compile. Looks like another one is `check_include_file_cxx(unistd.h HAVE_UNISTD_H)`.
(https://github.com/bitcoin/bitcoin/pull/30454#discussion_r1707417887)
I think we can just drop include checks like this (which don't produce defines used anywhere else in the codebase). I realise this kind of check was ported from Autotools, but I no-longer think it's necessary to do. Running a check to see if we can include `string.h`, just to then immediately compile something which includes `string.h`, seems like it should just be collapsed down to the compile. Looks like another one is `check_include_file_cxx(unistd.h HAVE_UNISTD_H)`.
💬 achow101 commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2273898861)
ACK 6bfa26048dbafb91e9ca63ea8d3960271e798098
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2273898861)
ACK 6bfa26048dbafb91e9ca63ea8d3960271e798098
👍 brunoerg approved a pull request: "fuzz: a target for the block index database"
(https://github.com/bitcoin/bitcoin/pull/28209#pullrequestreview-2225714117)
utACK 86b38529d5014612c3e7bb59fdc4dad3bff2aa64
(https://github.com/bitcoin/bitcoin/pull/28209#pullrequestreview-2225714117)
utACK 86b38529d5014612c3e7bb59fdc4dad3bff2aa64
✅ Quite-my-Tempo closed an issue: ""system_tests/run_command" unit test fails"
(https://github.com/bitcoin/bitcoin/issues/30601)
(https://github.com/bitcoin/bitcoin/issues/30601)
💬 Quite-my-Tempo commented on issue ""system_tests/run_command" unit test fails":
(https://github.com/bitcoin/bitcoin/issues/30601#issuecomment-2273911989)
it worked! thanks!
(https://github.com/bitcoin/bitcoin/issues/30601#issuecomment-2273911989)
it worked! thanks!
🚀 achow101 merged a pull request: "Testnet4 including PoW difficulty adjustment fix"
(https://github.com/bitcoin/bitcoin/pull/29775)
(https://github.com/bitcoin/bitcoin/pull/29775)
🤔 ryanofsky reviewed a pull request: "multiprocess: Add -ipcbind option to bitcoin-node"
(https://github.com/bitcoin/bitcoin/pull/30509#pullrequestreview-2225643495)
Thanks for the review!
Updated efdc120795e7c3ce914ee0677c3b69803ea5de1e -> cf9aaf4b7f27b38bf201aa39c56c9967f3b2a904 ([`pr/ipc-bind.2`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-bind.2) -> [`pr/ipc-bind.3`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-bind.3), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-bind.2..pr/ipc-bind.3)) with suggestions
(https://github.com/bitcoin/bitcoin/pull/30509#pullrequestreview-2225643495)
Thanks for the review!
Updated efdc120795e7c3ce914ee0677c3b69803ea5de1e -> cf9aaf4b7f27b38bf201aa39c56c9967f3b2a904 ([`pr/ipc-bind.2`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-bind.2) -> [`pr/ipc-bind.3`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-bind.3), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-bind.2..pr/ipc-bind.3)) with suggestions
💬 ryanofsky commented on pull request "multiprocess: Add -ipcbind option to bitcoin-node":
(https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1707371794)
re: https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1706754253
> If a relative path is provided, the path of the data directory is appended. If the parent directories in the provided path don't exist, they will be created. Should that be documented here?
Sure added both things.
(https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1707371794)
re: https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1706754253
> If a relative path is provided, the path of the data directory is appended. If the parent directories in the provided path don't exist, they will be created. Should that be documented here?
Sure added both things.
💬 ryanofsky commented on pull request "multiprocess: Add -ipcbind option to bitcoin-node":
(https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1707372358)
re: https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1706754253
> Nit: Could be declared `static`?
Sure, added static
(https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1707372358)
re: https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1706754253
> Nit: Could be declared `static`?
Sure, added static
💬 ryanofsky commented on pull request "multiprocess: Add -ipcbind option to bitcoin-node":
(https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1707372573)
re: https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1706927164
> Nit (personal style opinion): I feel like this (and the other functions in this file) would be a bit easier to read if the error conditions would return early. Then all this logic would not have to be indented and the final return of the function would carry the "good" value.
I could be missing something, but I think all the functions in this file are returning or throwing as soon as there is an error.
In this ca
...
(https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1707372573)
re: https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1706927164
> Nit (personal style opinion): I feel like this (and the other functions in this file) would be a bit easier to read if the error conditions would return early. Then all this logic would not have to be indented and the final return of the function would carry the "good" value.
I could be missing something, but I think all the functions in this file are returning or throwing as soon as there is an error.
In this ca
...
💬 ryanofsky commented on pull request "multiprocess: Add -ipcbind option to bitcoin-node":
(https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1707373325)
re: https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1707288885
> Since multiple binds are supported, I would suggest to add a test case for binding and connecting on different addresses in the same process.
Thanks, added
(https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1707373325)
re: https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1707288885
> Since multiple binds are supported, I would suggest to add a test case for binding and connecting on different addresses in the same process.
Thanks, added
💬 ryanofsky commented on pull request "multiprocess: Add -ipcbind option to bitcoin-node":
(https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1707372017)
re: https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1707213519
> Just a question: Intuitively I was under the impression that only the node should be listening. In which scenario should the gui be able to listen as well? Do we need a bi-directional connection here for some callbacks?
Added comment. You are right that gui does not listen on a socket, but `bitcoin-gui` accepts all the same arguments `bitcoin-node` does and more. If `bitcoin-gui` is started and a node processs is no
...
(https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1707372017)
re: https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1707213519
> Just a question: Intuitively I was under the impression that only the node should be listening. In which scenario should the gui be able to listen as well? Do we need a bi-directional connection here for some callbacks?
Added comment. You are right that gui does not listen on a socket, but `bitcoin-gui` accepts all the same arguments `bitcoin-node` does and more. If `bitcoin-gui` is started and a node processs is no
...
💬 ryanofsky commented on pull request "multiprocess: Add -ipcbind option to bitcoin-node":
(https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1707373805)
re: https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1707289963
> Is there a reason for manually resetting these here? I guess in the other test resetting is required, because otherwise the thread will never join.
Nice catch, these are not needed. An initial version of this test did use a thread but it's gone and these are no longer necessary.
(https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1707373805)
re: https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1707289963
> Is there a reason for manually resetting these here? I guess in the other test resetting is required, because otherwise the thread will never join.
Nice catch, these are not needed. An initial version of this test did use a thread but it's gone and these are no longer necessary.
💬 TheCharlatan commented on pull request "multiprocess: Add -ipcbind option to bitcoin-node":
(https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1707536386)
Typo nit: s/if a relative paths are/if relative paths/
(https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1707536386)
Typo nit: s/if a relative paths are/if relative paths/
💬 TheCharlatan commented on pull request "multiprocess: Add -ipcbind option to bitcoin-node":
(https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1707538495)
Ah, that makes sense, I did not think about this function being expanded over time.
(https://github.com/bitcoin/bitcoin/pull/30509#discussion_r1707538495)
Ah, that makes sense, I did not think about this function being expanded over time.
💬 davidgumberg commented on pull request "Don't empty dbcache on prune flushes: >30% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/28280#discussion_r1707541879)
I think this is right, just wanted to make a note that I believe @mzumsande earlier [comment](https://github.com/bitcoin/bitcoin/pull/28280#discussion_r1655477509) is relevant here. Namely, that it's not necessary to check for freshness here if we cannot have fresh-but-not-dirty entries, and even if we could, I'm not sure why we wouldn't remove them from the cache in this instance. But I think this should be addressed by any revival of #18746.
(https://github.com/bitcoin/bitcoin/pull/28280#discussion_r1707541879)
I think this is right, just wanted to make a note that I believe @mzumsande earlier [comment](https://github.com/bitcoin/bitcoin/pull/28280#discussion_r1655477509) is relevant here. Namely, that it's not necessary to check for freshness here if we cannot have fresh-but-not-dirty entries, and even if we could, I'm not sure why we wouldn't remove them from the cache in this instance. But I think this should be addressed by any revival of #18746.
💬 mzumsande commented on pull request "p2p: For assumeutxo, download snapshot chain before background chain":
(https://github.com/bitcoin/bitcoin/pull/29519#issuecomment-2274027378)
> Is there another crash you were referring to? The first commit message says:
We'd also crash trying to reorg because this scenario is not handled.
I didn't mean an assert with that, just a shutdown with a fatal error. I tested this in a functional test, if I recall correctly the following happened:
After loading the snapshot, I would connect a peer with a higher-work tip branching off below the snapshot height. On master we'd download blocks from this peer, and as soon as we'd have a an
...
(https://github.com/bitcoin/bitcoin/pull/29519#issuecomment-2274027378)
> Is there another crash you were referring to? The first commit message says:
We'd also crash trying to reorg because this scenario is not handled.
I didn't mean an assert with that, just a shutdown with a fatal error. I tested this in a functional test, if I recall correctly the following happened:
After loading the snapshot, I would connect a peer with a higher-work tip branching off below the snapshot height. On master we'd download blocks from this peer, and as soon as we'd have a an
...
💬 boring877 commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#discussion_r1707579334)
why not just keep it ? why act like communist and remove things you desire ~
alot of data and infrastructure already on testnet3, why force people your own desires ~
(https://github.com/bitcoin/bitcoin/pull/29775#discussion_r1707579334)
why not just keep it ? why act like communist and remove things you desire ~
alot of data and infrastructure already on testnet3, why force people your own desires ~
💬 boring877 commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#discussion_r1707583093)
> @fjahr I guess because I feel it's hard to make concrete promises about something that far out. If we _know_ we will remove testnet3 in v30, we should just deprecate it in v28 already (including a `-deprecatedrpc` requirement), rather than saying it will be deprecated. If not, the best we can do is announce an intent that it will be removed in the future, without concrete timing.
what you mean testnet3 gone ? you seriously wants to delete it~ you can use testnet3 as reference for old script
...
(https://github.com/bitcoin/bitcoin/pull/29775#discussion_r1707583093)
> @fjahr I guess because I feel it's hard to make concrete promises about something that far out. If we _know_ we will remove testnet3 in v30, we should just deprecate it in v28 already (including a `-deprecatedrpc` requirement), rather than saying it will be deprecated. If not, the best we can do is announce an intent that it will be removed in the future, without concrete timing.
what you mean testnet3 gone ? you seriously wants to delete it~ you can use testnet3 as reference for old script
...
💬 murchandamus commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#discussion_r1707589818)
> what you mean testnet3 gone ? you seriously wants to delete it~ you can use testnet3 as reference for old scripts thats been used ...
No worries, you can continue to use Testnet 3 as long as you desire. It’s just not going to be supported by Bitcoin Core starting with some upcoming version.
(https://github.com/bitcoin/bitcoin/pull/29775#discussion_r1707589818)
> what you mean testnet3 gone ? you seriously wants to delete it~ you can use testnet3 as reference for old scripts thats been used ...
No worries, you can continue to use Testnet 3 as long as you desire. It’s just not going to be supported by Bitcoin Core starting with some upcoming version.