💬 willcl-ark commented on issue "Nit: Inconsistency in the docs regarding block-relay-only connections":
(https://github.com/bitcoin/bitcoin/issues/29046#issuecomment-1849754763)
The short-lived feeler connections are not counted against the full outbound count:
https://github.com/bitcoin/bitcoin/blob/09ab9d4fa731866802a6a9f9aa00d92536a8b420/src/net.cpp#L2349-L2355
...so reduce-traffic.md could be updated to mention that there are occasionally up to 11 outbound nodes, which it appears @MarnixCroes has just done :)
(https://github.com/bitcoin/bitcoin/issues/29046#issuecomment-1849754763)
The short-lived feeler connections are not counted against the full outbound count:
https://github.com/bitcoin/bitcoin/blob/09ab9d4fa731866802a6a9f9aa00d92536a8b420/src/net.cpp#L2349-L2355
...so reduce-traffic.md could be updated to mention that there are occasionally up to 11 outbound nodes, which it appears @MarnixCroes has just done :)
🚀 fanquake merged a pull request: "test: fix intermittent error in rpc_net.py (#29030)"
(https://github.com/bitcoin/bitcoin/pull/29041)
(https://github.com/bitcoin/bitcoin/pull/29041)
✅ fanquake closed an issue: "test: Intermittent issue in rpc_net.py"
(https://github.com/bitcoin/bitcoin/issues/29030)
(https://github.com/bitcoin/bitcoin/issues/29030)
🤔 josibake reviewed a pull request: "wallet: skip BnB when SFFO is enabled"
(https://github.com/bitcoin/bitcoin/pull/28994#pullrequestreview-1774837387)
ACK https://github.com/bitcoin/bitcoin/commit/1d3bc77cbe25a8492a4733841bb7d6ecd6d60d30
> Applied @murchandamus suggestion of adding inputs fee to each UTXO rather than deduct them from the target. The latter one was breaking the equivalence of the input sets.
Wasn't the test still passing before, when you were deducting them from the target? If so, I would suggest we take a closer look at this test in https://github.com/bitcoin/bitcoin/pull/28985 to ensure it's testing the thing it's suppo
...
(https://github.com/bitcoin/bitcoin/pull/28994#pullrequestreview-1774837387)
ACK https://github.com/bitcoin/bitcoin/commit/1d3bc77cbe25a8492a4733841bb7d6ecd6d60d30
> Applied @murchandamus suggestion of adding inputs fee to each UTXO rather than deduct them from the target. The latter one was breaking the equivalence of the input sets.
Wasn't the test still passing before, when you were deducting them from the target? If so, I would suggest we take a closer look at this test in https://github.com/bitcoin/bitcoin/pull/28985 to ensure it's testing the thing it's suppo
...
👍 TheCharlatan approved a pull request: "msvc: Define the same `QT_...` macros as in Autotools builds"
(https://github.com/bitcoin/bitcoin/pull/29044#pullrequestreview-1774842750)
ACK 1a5dae630df1eef9eac51557b2f1c5dba0924953
Thank you @hebasto, this fixes the build failure of #28960.
(https://github.com/bitcoin/bitcoin/pull/29044#pullrequestreview-1774842750)
ACK 1a5dae630df1eef9eac51557b2f1c5dba0924953
Thank you @hebasto, this fixes the build failure of #28960.
💬 willcl-ark commented on issue "The logo icon doesn't show properly under Wayland":
(https://github.com/bitcoin-core/gui/issues/781#issuecomment-1849838605)
I think Wayland is much stricter about loading the icon from the `.desktop` file (which must have an exactly matching name). I didn't test this any further, but running Wayland on my system with an appropriate `.desktop` file installed I do get the correct icon:

That said, I added my .desktop file manually a while ago, and I notice now that on my machine the code
...
(https://github.com/bitcoin-core/gui/issues/781#issuecomment-1849838605)
I think Wayland is much stricter about loading the icon from the `.desktop` file (which must have an exactly matching name). I didn't test this any further, but running Wayland on my system with an appropriate `.desktop` file installed I do get the correct icon:

That said, I added my .desktop file manually a while ago, and I notice now that on my machine the code
...
⚠️ kallerosenbaum opened an issue: "bumpfee doc about incrementalfee is incorrect"
(https://github.com/bitcoin/bitcoin/issues/29053)
### Is there an existing issue for this?
- [X] I have searched the existing issues
### Current behaviour
The documentation for the `bumpfee` command states
"At a minimum, the new fee rate must be high enough to pay an additional new relay fee (incrementalfee
returned by getnetworkinfo) to enter the node's mempool."
While not strictly incorrect (the "At a minimum" part), it is very misleadi
...
(https://github.com/bitcoin/bitcoin/issues/29053)
### Is there an existing issue for this?
- [X] I have searched the existing issues
### Current behaviour
The documentation for the `bumpfee` command states
"At a minimum, the new fee rate must be high enough to pay an additional new relay fee (incrementalfee
returned by getnetworkinfo) to enter the node's mempool."
While not strictly incorrect (the "At a minimum" part), it is very misleadi
...
🚀 fanquake merged a pull request: "msvc: Define the same `QT_...` macros as in Autotools builds"
(https://github.com/bitcoin/bitcoin/pull/29044)
(https://github.com/bitcoin/bitcoin/pull/29044)
✅ fanquake closed a pull request: "kernel: Remove dependency on CScheduler"
(https://github.com/bitcoin/bitcoin/pull/28960)
(https://github.com/bitcoin/bitcoin/pull/28960)
✅ fanquake closed a pull request: "kernel: Remove dependency on CScheduler"
(https://github.com/bitcoin/bitcoin/pull/28960)
(https://github.com/bitcoin/bitcoin/pull/28960)
💬 darosior commented on pull request "kernel: Remove dependency on CScheduler":
(https://github.com/bitcoin/bitcoin/pull/28960#issuecomment-1849887372)
This shouldn't have been closed i think @fanquake.
(https://github.com/bitcoin/bitcoin/pull/28960#issuecomment-1849887372)
This shouldn't have been closed i think @fanquake.
📝 fanquake reopened a pull request: "kernel: Remove dependency on CScheduler"
(https://github.com/bitcoin/bitcoin/pull/28960)
By defining a virtual interface class for the scheduler client, users of the kernel can now define their own event consuming infrastructure, without having to spawn threads or rely on the scheduler design.
Removing `CScheduler` also allows removing the thread and exception modules from the kernel library.
To make the `CMainSignals` class easier to use from a kernel library perspective, remove its global instantiation and adopt RAII practices.
---
This PR is part of the [libbitcoinke
...
(https://github.com/bitcoin/bitcoin/pull/28960)
By defining a virtual interface class for the scheduler client, users of the kernel can now define their own event consuming infrastructure, without having to spawn threads or rely on the scheduler design.
Removing `CScheduler` also allows removing the thread and exception modules from the kernel library.
To make the `CMainSignals` class easier to use from a kernel library perspective, remove its global instantiation and adopt RAII practices.
---
This PR is part of the [libbitcoinke
...
💬 Sjors commented on pull request "Silent payment index (for light wallets and consistency check)":
(https://github.com/bitcoin/bitcoin/pull/28241#issuecomment-1849912410)
Rebased and added a simple functional test, which includes a (hopefully) deterministic tweak.
(https://github.com/bitcoin/bitcoin/pull/28241#issuecomment-1849912410)
Rebased and added a simple functional test, which includes a (hopefully) deterministic tweak.
💬 dergoegge commented on pull request "fuzz: make FuzzedDataProvider usage deterministic":
(https://github.com/bitcoin/bitcoin/pull/29043#issuecomment-1849934451)
Nice find!
I am wondering if this is worth it at this point, since we only fuzz with llvm based compilers. If we had infrastructure that was fuzzing with gcc (e.g. compiling with afl++'s `afl-g++-fast`) then this would clearly make sense. I think if we are going to care about this, we should also add a gcc fuzz CI job and have a linter (maybe a custom clang-tidy plugin?) that checks for dependence on evaluation order (which would probably be a good idea in any case).
(https://github.com/bitcoin/bitcoin/pull/29043#issuecomment-1849934451)
Nice find!
I am wondering if this is worth it at this point, since we only fuzz with llvm based compilers. If we had infrastructure that was fuzzing with gcc (e.g. compiling with afl++'s `afl-g++-fast`) then this would clearly make sense. I think if we are going to care about this, we should also add a gcc fuzz CI job and have a linter (maybe a custom clang-tidy plugin?) that checks for dependence on evaluation order (which would probably be a good idea in any case).
💬 glozow commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1422369475)
I think just direct parents should be fine - presumably any further generations should have the same version anyway.
I'll continue using `m_ancestors` here since it's what we have access to, but will leave a comment about this.
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1422369475)
I think just direct parents should be fine - presumably any further generations should have the same version anyway.
I'll continue using `m_ancestors` here since it's what we have access to, but will leave a comment about this.
👍 brunoerg approved a pull request: "fuzz: p2p: Detect peer deadlocks"
(https://github.com/bitcoin/bitcoin/pull/29009#pullrequestreview-1775003092)
ACK 9f265d88253ed464413dea5614fa13dea0d8cfd5
(https://github.com/bitcoin/bitcoin/pull/29009#pullrequestreview-1775003092)
ACK 9f265d88253ed464413dea5614fa13dea0d8cfd5
🚀 fanquake merged a pull request: "fuzz: Improve fuzzing stability for txorphan harness"
(https://github.com/bitcoin/bitcoin/pull/29031)
(https://github.com/bitcoin/bitcoin/pull/29031)
💬 kallewoof commented on pull request "signet: fixing mining for OP_TRUE challenge":
(https://github.com/bitcoin/bitcoin/pull/29032#issuecomment-1849995402)
This looks reasonable to me, although I'm not super familiar with all the code being changed.
(https://github.com/bitcoin/bitcoin/pull/29032#issuecomment-1849995402)
This looks reasonable to me, although I'm not super familiar with all the code being changed.
💬 dergoegge commented on pull request "wip: Split fuzz binary":
(https://github.com/bitcoin/bitcoin/pull/29010#issuecomment-1849996651)
> Hmm, if I switch to this PR and try compiling, I get bunches of linker errors about multiple definitions, eg
Yea weird, it compiles for me with `afl-clang-lto` but not with regular clang.
> Dropping from 14GB to 3.6GB seems worthwhile for oss-fuzz (and similar), but not worthwhile otherwise to me
I listed more benefits in https://github.com/bitcoin/bitcoin/issues/28971. It is not gonna have a noticeable effect for contributors that aren't regularly fuzzing.
> to get a list of fuzz
...
(https://github.com/bitcoin/bitcoin/pull/29010#issuecomment-1849996651)
> Hmm, if I switch to this PR and try compiling, I get bunches of linker errors about multiple definitions, eg
Yea weird, it compiles for me with `afl-clang-lto` but not with regular clang.
> Dropping from 14GB to 3.6GB seems worthwhile for oss-fuzz (and similar), but not worthwhile otherwise to me
I listed more benefits in https://github.com/bitcoin/bitcoin/issues/28971. It is not gonna have a noticeable effect for contributors that aren't regularly fuzzing.
> to get a list of fuzz
...
👍 stickies-v approved a pull request: "mempool: Don't sort in entryAll"
(https://github.com/bitcoin/bitcoin/pull/29019#pullrequestreview-1775071503)
re-ACK f761f0306b092c06cecd239060b36cd0ba45fa2c, very nice
(https://github.com/bitcoin/bitcoin/pull/29019#pullrequestreview-1775071503)
re-ACK f761f0306b092c06cecd239060b36cd0ba45fa2c, very nice