👍 vasild approved a pull request: "test: create assert_not_equal util"
(https://github.com/bitcoin/bitcoin/pull/29500#pullrequestreview-2415263506)
Almost ACK 1d722660a6, modulo squash of the two commits.
This is a nice addition.
It is better to squash the two commits into one because IMO it does not make sense to first add the import in one commit and in another commit to use it. That way it becomes difficult to review whether an unnecessary import was added to some file. Also some python linter that tests each commit could be upset about the unused imports in the first commit.
I found it easier to read the diff itself instead of
...
(https://github.com/bitcoin/bitcoin/pull/29500#pullrequestreview-2415263506)
Almost ACK 1d722660a6, modulo squash of the two commits.
This is a nice addition.
It is better to squash the two commits into one because IMO it does not make sense to first add the import in one commit and in another commit to use it. That way it becomes difficult to review whether an unnecessary import was added to some file. Also some python linter that tests each commit could be upset about the unused imports in the first commit.
I found it easier to read the diff itself instead of
...
💬 hebasto commented on pull request "Update secp256k1 subtree to v0.6.0":
(https://github.com/bitcoin/bitcoin/pull/31216#issuecomment-2456856188)
> v0.6.0 was just released, main change is that it has the musig module which #29675 needs.
Should we disable the musig module in this PR and enable it only when it is needed?
(https://github.com/bitcoin/bitcoin/pull/31216#issuecomment-2456856188)
> v0.6.0 was just released, main change is that it has the musig module which #29675 needs.
Should we disable the musig module in this PR and enable it only when it is needed?
💬 vasild commented on pull request "ci: skip Github CI on branch pushes for forks":
(https://github.com/bitcoin/bitcoin/pull/30487#issuecomment-2456862790)
Concept ACK
> A use case that was mentioned to me offline is that some people, before opening a PR to the main repo, like to push their branch and have CI check it.
FWIW I do that but I have a dedicated dummy branch which is associated with a PR to merge it into my copy of `master`. So I never merge that PR and keep `push -f`ing into the dummy branch to test.
(https://github.com/bitcoin/bitcoin/pull/30487#issuecomment-2456862790)
Concept ACK
> A use case that was mentioned to me offline is that some people, before opening a PR to the main repo, like to push their branch and have CI check it.
FWIW I do that but I have a dedicated dummy branch which is associated with a PR to merge it into my copy of `master`. So I never merge that PR and keep `push -f`ing into the dummy branch to test.
✅ ryanofsky closed an issue: "bench: `linearizeoptimallyexample11` benchmark now running 4x slow than previously"
(https://github.com/bitcoin/bitcoin/issues/31178)
(https://github.com/bitcoin/bitcoin/issues/31178)
🚀 ryanofsky merged a pull request: "build: Make G_FUZZING constexpr, require -DBUILD_FOR_FUZZING=ON to fuzz"
(https://github.com/bitcoin/bitcoin/pull/31191)
(https://github.com/bitcoin/bitcoin/pull/31191)
💬 maflcko commented on issue "intermittent issue in wallet_upgradewallet.py: AssertionError: bdb magic does not match bdb btree magic":
(https://github.com/bitcoin/bitcoin/issues/31210#issuecomment-2456883152)
Not sure how to fix this. IIUC neither podman (https://github.com/containers/podman/issues/11415#issuecomment-912015581), nor docker (https://docs.docker.com/engine/security/rootless/#known-limitations) support rootless zfs.
(https://github.com/bitcoin/bitcoin/issues/31210#issuecomment-2456883152)
Not sure how to fix this. IIUC neither podman (https://github.com/containers/podman/issues/11415#issuecomment-912015581), nor docker (https://docs.docker.com/engine/security/rootless/#known-limitations) support rootless zfs.
💬 ryanofsky commented on pull request "build: Make G_FUZZING constexpr, require -DBUILD_FOR_FUZZING=ON to fuzz":
(https://github.com/bitcoin/bitcoin/pull/31191#issuecomment-2456883737)
Went ahead and merged this since it has enough ACKs, and it sounds like the concerns I have about drawbacks of this PR don't seem to be shared by the other reviewers. I think it would be nice if fuzzing could be turned on without turning every else off, and this approach will probably make me a little less likely to start writing fuzz tests, and prefer writing unit tests instead for convenience. But status after this PR isn't worse than the status before #31093, and this approach can always be r
...
(https://github.com/bitcoin/bitcoin/pull/31191#issuecomment-2456883737)
Went ahead and merged this since it has enough ACKs, and it sounds like the concerns I have about drawbacks of this PR don't seem to be shared by the other reviewers. I think it would be nice if fuzzing could be turned on without turning every else off, and this approach will probably make me a little less likely to start writing fuzz tests, and prefer writing unit tests instead for convenience. But status after this PR isn't worse than the status before #31093, and this approach can always be r
...
💬 laanwj commented on pull request "net: Use actual memory size in receive buffer accounting":
(https://github.com/bitcoin/bitcoin/pull/31164#discussion_r1829166070)
yes, explaining it more would make sense!
but i think it's out of scope for this PR
(https://github.com/bitcoin/bitcoin/pull/31164#discussion_r1829166070)
yes, explaining it more would make sense!
but i think it's out of scope for this PR
💬 laanwj commented on pull request "net: Use actual memory size in receive buffer accounting":
(https://github.com/bitcoin/bitcoin/pull/31164#discussion_r1829170503)
right-it can be used for nested structures, but the call site has to do their own iteration and add it up, as this only covers the outermost layer
adding the `std::is_trivial_v` check is an interesting idea but would prevent it from being used there.
(https://github.com/bitcoin/bitcoin/pull/31164#discussion_r1829170503)
right-it can be used for nested structures, but the call site has to do their own iteration and add it up, as this only covers the outermost layer
adding the `std::is_trivial_v` check is an interesting idea but would prevent it from being used there.
💬 laanwj commented on pull request "net: Use actual memory size in receive buffer accounting":
(https://github.com/bitcoin/bitcoin/pull/31164#discussion_r1829176216)
i don't think there's anything to do here; the code is agnostic to the size and implementation of the sso area; the comment gives an example for one C++ library, to illustrate the point
adding more specifics adds more information that could go stale 😄
(https://github.com/bitcoin/bitcoin/pull/31164#discussion_r1829176216)
i don't think there's anything to do here; the code is agnostic to the size and implementation of the sso area; the comment gives an example for one C++ library, to illustrate the point
adding more specifics adds more information that could go stale 😄
💬 fanquake commented on pull request "build: increase minimum supported Windows to 10.0":
(https://github.com/bitcoin/bitcoin/pull/31172#discussion_r1829177093)
Sure, dropped.
(https://github.com/bitcoin/bitcoin/pull/31172#discussion_r1829177093)
Sure, dropped.
💬 vasild commented on issue "Distribute darknet node addresses via DNS seeds using AAAA records":
(https://github.com/bitcoin/bitcoin/issues/31062#issuecomment-2456901896)
I agree with the reasoning above. I am still Concept ACK if we can have the clients get all addresses from the response, without some addresses being omitted. I see no downsides if separate DNS seeds are used for the new encoding, leaving the existent ones as they are currently.
Just to clarify - Tor only nodes do not use DNS seeds and the intention here is to keep it that way. The motivation is to help multi-homed nodes that use clearnet and Tor. They are currently only getting clearnet addr
...
(https://github.com/bitcoin/bitcoin/issues/31062#issuecomment-2456901896)
I agree with the reasoning above. I am still Concept ACK if we can have the clients get all addresses from the response, without some addresses being omitted. I see no downsides if separate DNS seeds are used for the new encoding, leaving the existent ones as they are currently.
Just to clarify - Tor only nodes do not use DNS seeds and the intention here is to keep it that way. The motivation is to help multi-homed nodes that use clearnet and Tor. They are currently only getting clearnet addr
...
💬 fanquake commented on pull request "build: increase minimum supported Windows to 10.0":
(https://github.com/bitcoin/bitcoin/pull/31172#issuecomment-2456905576)
@davidgumberg @hodlinator Thanks for taking a look. I've adjusted the subsystem change, and made some other small updates. I think we can do this for now, and follow up further with #30210.
(https://github.com/bitcoin/bitcoin/pull/31172#issuecomment-2456905576)
@davidgumberg @hodlinator Thanks for taking a look. I've adjusted the subsystem change, and made some other small updates. I think we can do this for now, and follow up further with #30210.
🤔 hebasto reviewed a pull request: "build: increase minimum supported Windows to 10.0"
(https://github.com/bitcoin/bitcoin/pull/31172#pullrequestreview-2415383222)
Appproach ACK 0440c406eedbc16fa1ce6c77a802b7ea60a79057.
(https://github.com/bitcoin/bitcoin/pull/31172#pullrequestreview-2415383222)
Appproach ACK 0440c406eedbc16fa1ce6c77a802b7ea60a79057.
💬 maflcko commented on pull request "ci: Split out native fuzz jobs for macOS and windows":
(https://github.com/bitcoin/bitcoin/pull/31073#issuecomment-2456949207)
This may be re-considered after a rebase. However, I wonder if the bloat can be reduced, assuming GHA has a matrix feature, so that the non-fuzz and fuzz-build can share most of the GHA config and steps?
(https://github.com/bitcoin/bitcoin/pull/31073#issuecomment-2456949207)
This may be re-considered after a rebase. However, I wonder if the bloat can be reduced, assuming GHA has a matrix feature, so that the non-fuzz and fuzz-build can share most of the GHA config and steps?
💬 maflcko commented on pull request "build: Make G_FUZZING constexpr, require -DBUILD_FOR_FUZZING=ON to fuzz":
(https://github.com/bitcoin/bitcoin/pull/31191#issuecomment-2456953234)
> this approach will probably make me a little less likely to start writing fuzz tests
I understand your concerns, but did you actually encounter them in reality? Generally, for writing fuzz tests, you'll want to go with a fuzz engine (and ideally sanitizers). Otherwise, generating fuzz inputs and exploring the fuzz target reachable code will be harder. Once you link a fuzz engine, you'll have to go with a separate fuzz build anyway.
My understanding is that the only real-world developer u
...
(https://github.com/bitcoin/bitcoin/pull/31191#issuecomment-2456953234)
> this approach will probably make me a little less likely to start writing fuzz tests
I understand your concerns, but did you actually encounter them in reality? Generally, for writing fuzz tests, you'll want to go with a fuzz engine (and ideally sanitizers). Otherwise, generating fuzz inputs and exploring the fuzz target reachable code will be harder. Once you link a fuzz engine, you'll have to go with a separate fuzz build anyway.
My understanding is that the only real-world developer u
...
💬 hebasto commented on pull request "build: increase minimum supported Windows to 10.0":
(https://github.com/bitcoin/bitcoin/pull/31172#issuecomment-2456981291)
My Guix build:
```
aarch64
061fe1fb0c9d3ce9f564c19d1ddc60127a8fb3cae0cb24b4726c27dd41498c04 guix-build-0440c406eedb/output/dist-archive/bitcoin-0440c406eedb.tar.gz
2a0198646e6cbf8c61baf683bf36a25a826d19b8941e7b3a9cfeb04914d39aed guix-build-0440c406eedb/output/x86_64-w64-mingw32/SHA256SUMS.part
bdc9fb82b0f1a5dd361392f41aa09fe158448009f92c9914c04096d9ca47458c guix-build-0440c406eedb/output/x86_64-w64-mingw32/bitcoin-0440c406eedb-win64-debug.zip
896dcec8adae706035a693bf56a8ec8b3a88a5fb44e8
...
(https://github.com/bitcoin/bitcoin/pull/31172#issuecomment-2456981291)
My Guix build:
```
aarch64
061fe1fb0c9d3ce9f564c19d1ddc60127a8fb3cae0cb24b4726c27dd41498c04 guix-build-0440c406eedb/output/dist-archive/bitcoin-0440c406eedb.tar.gz
2a0198646e6cbf8c61baf683bf36a25a826d19b8941e7b3a9cfeb04914d39aed guix-build-0440c406eedb/output/x86_64-w64-mingw32/SHA256SUMS.part
bdc9fb82b0f1a5dd361392f41aa09fe158448009f92c9914c04096d9ca47458c guix-build-0440c406eedb/output/x86_64-w64-mingw32/bitcoin-0440c406eedb-win64-debug.zip
896dcec8adae706035a693bf56a8ec8b3a88a5fb44e8
...
💬 vasild commented on issue "Listen on random port by default (not 8333)":
(https://github.com/bitcoin/bitcoin/issues/31036#issuecomment-2456985760)
> We keep the DNS seeds, but treat them always as addrfetch peers
> Another downside would be that finding an initial batch of peers would take longer
What about having P2P-seeds, an alternative to DNS-seeds, which are serving the P2P protocol and are used as addrfetch peers and they return only high-quality addresses from the crawler? The IP/Tor/I2P addresses of those P2P-seeds could be hardcoded or (for clearnet only) we can have hardcoded the hostname, e.g. `p2pseed.bitcoin.org` which r
...
(https://github.com/bitcoin/bitcoin/issues/31036#issuecomment-2456985760)
> We keep the DNS seeds, but treat them always as addrfetch peers
> Another downside would be that finding an initial batch of peers would take longer
What about having P2P-seeds, an alternative to DNS-seeds, which are serving the P2P protocol and are used as addrfetch peers and they return only high-quality addresses from the crawler? The IP/Tor/I2P addresses of those P2P-seeds could be hardcoded or (for clearnet only) we can have hardcoded the hostname, e.g. `p2pseed.bitcoin.org` which r
...
👍 rkrux approved a pull request: "Remove mempoolfullrbf"
(https://github.com/bitcoin/bitcoin/pull/30592#pullrequestreview-2415368101)
reACK c189eec848e3c31f438151d4d3422718a29df3a3
(https://github.com/bitcoin/bitcoin/pull/30592#pullrequestreview-2415368101)
reACK c189eec848e3c31f438151d4d3422718a29df3a3
💬 rkrux commented on pull request "Remove mempoolfullrbf":
(https://github.com/bitcoin/bitcoin/pull/30592#discussion_r1829194254)
I ran the node with `mempoolfullrbf=0` and it correctly ignored the option.
```
2024-11-05T09:53:52Z Ignoring unknown configuration value regtest.mempoolfullrbf
```
(https://github.com/bitcoin/bitcoin/pull/30592#discussion_r1829194254)
I ran the node with `mempoolfullrbf=0` and it correctly ignored the option.
```
2024-11-05T09:53:52Z Ignoring unknown configuration value regtest.mempoolfullrbf
```
💬 rkrux commented on pull request "Remove mempoolfullrbf":
(https://github.com/bitcoin/bitcoin/pull/30592#discussion_r1829209285)
After the PR is merged: Thinking out loud, should the `fullrbf` option in this RPC output still be shown at all? Would it hold any meaningful significance or would it be just unnecessary information?
(https://github.com/bitcoin/bitcoin/pull/30592#discussion_r1829209285)
After the PR is merged: Thinking out loud, should the `fullrbf` option in this RPC output still be shown at all? Would it hold any meaningful significance or would it be just unnecessary information?