📝 maflcko opened a pull request: "ci: Run GUI unit tests in cross-Windows task"
(https://github.com/bitcoin/bitcoin/pull/33919)
Most users of the cross-compiled releases for Windows will most likely pick the GUI, so running the cross-compiled GUI unit tests on a real Windows seems desirable.
(https://github.com/bitcoin/bitcoin/pull/33919)
Most users of the cross-compiled releases for Windows will most likely pick the GUI, so running the cross-compiled GUI unit tests on a real Windows seems desirable.
💬 l0rinc commented on issue "RFC: Do we want to support fuzzing on MacOS?":
(https://github.com/bitcoin/bitcoin/issues/33731#issuecomment-3560177532)
Fuzzing works, I just have to disable the sanitizers, since they disable exception support - and the fuzzer halts at the very first throw.
(https://github.com/bitcoin/bitcoin/issues/33731#issuecomment-3560177532)
Fuzzing works, I just have to disable the sanitizers, since they disable exception support - and the fuzzer halts at the very first throw.
👍 hebasto approved a pull request: "clang-format: Set PackConstructorInitializers: CurrentLine"
(https://github.com/bitcoin/bitcoin/pull/33912#pullrequestreview-3490063992)
ACK fad0c76d0a109ab7b063f0d405588cf1e6c15e4d.
(https://github.com/bitcoin/bitcoin/pull/33912#pullrequestreview-3490063992)
ACK fad0c76d0a109ab7b063f0d405588cf1e6c15e4d.
🚀 hebasto merged a pull request: "clang-format: Set PackConstructorInitializers: CurrentLine"
(https://github.com/bitcoin/bitcoin/pull/33912)
(https://github.com/bitcoin/bitcoin/pull/33912)
💬 davidgumberg commented on pull request "docs: clarify RPC credentials security boundary":
(https://github.com/bitcoin/bitcoin/pull/33196#discussion_r2547793630)
I think the existing docs make it pretty clear that other processes/users with access to the machine can comprise the node, but I think what is not obvious in the existing docs is that the other direction is true as well, someone with RPC access can probably compromise the machine the `bitcoind` node is running on.
(https://github.com/bitcoin/bitcoin/pull/33196#discussion_r2547793630)
I think the existing docs make it pretty clear that other processes/users with access to the machine can comprise the node, but I think what is not obvious in the existing docs is that the other direction is true as well, someone with RPC access can probably compromise the machine the `bitcoind` node is running on.
💬 davidgumberg commented on pull request "log: avoid collecting `GetSerializeSize` data when compact block logging is disabled":
(https://github.com/bitcoin/bitcoin/pull/33738#issuecomment-3560241264)
crACK 10e0e96e703a40b298b8
Lightly tested running on mainnet, logs for receiving look good:
```
2025-11-20T21:56:39.778340Z [cmpctblock] Successfully reconstructed block 000000000000000000004152f92a1ec0a2f2e4356264001b11361f35247f641d with 1 txn prefilled, 3940 txn from mempool (incl at least 6 from extra pool) and 141 txn (64021 bytes) requested
```
Haven't received a `GETBLOCKTXN` request yet.
(https://github.com/bitcoin/bitcoin/pull/33738#issuecomment-3560241264)
crACK 10e0e96e703a40b298b8
Lightly tested running on mainnet, logs for receiving look good:
```
2025-11-20T21:56:39.778340Z [cmpctblock] Successfully reconstructed block 000000000000000000004152f92a1ec0a2f2e4356264001b11361f35247f641d with 1 txn prefilled, 3940 txn from mempool (incl at least 6 from extra pool) and 141 txn (64021 bytes) requested
```
Haven't received a `GETBLOCKTXN` request yet.
🤔 mzumsande reviewed a pull request: "test: assumeutxo: add missing tests in wallet_assumeutxo.py"
(https://github.com/bitcoin/bitcoin/pull/30455#pullrequestreview-3490160325)
Code Review ACK 55c6a69f777ac08a14e61b98efea00e5c8f98a5f
(https://github.com/bitcoin/bitcoin/pull/30455#pullrequestreview-3490160325)
Code Review ACK 55c6a69f777ac08a14e61b98efea00e5c8f98a5f
💬 maflcko commented on pull request "ci: Run GUI unit tests in cross-Windows task":
(https://github.com/bitcoin/bitcoin/pull/33919#issuecomment-3560370955)
Hmm, the CI did not fail, but I also do not see the expected output `********* Start testing of AppTests *********...` etc, so I am not sure if everything worked here.
(https://github.com/bitcoin/bitcoin/pull/33919#issuecomment-3560370955)
Hmm, the CI did not fail, but I also do not see the expected output `********* Start testing of AppTests *********...` etc, so I am not sure if everything worked here.
🤔 w0xlt reviewed a pull request: "argsman, cli: GNU-style command-line option parsing (allows options after non-option arguments)"
(https://github.com/bitcoin/bitcoin/pull/33540#pullrequestreview-3490254189)
This command works on master but not in this PR:
`./build/bin/bitcoin-cli --datadir=/tmp/btc1 --signet getblockhash 1000`
Could it be related to GetCommandArgs()?
(https://github.com/bitcoin/bitcoin/pull/33540#pullrequestreview-3490254189)
This command works on master but not in this PR:
`./build/bin/bitcoin-cli --datadir=/tmp/btc1 --signet getblockhash 1000`
Could it be related to GetCommandArgs()?
💬 mzumsande commented on issue "test: spurious failure in p2p_leak_tx.py --v1transport":
(https://github.com/bitcoin/bitcoin/issues/33090#issuecomment-3560395768)
I think this can be closed after merge of #3312. Even though (as discussed there) the test can still fail with a very low probability, the fix should have lowered this probability more.
(https://github.com/bitcoin/bitcoin/issues/33090#issuecomment-3560395768)
I think this can be closed after merge of #3312. Even though (as discussed there) the test can still fail with a very low probability, the fix should have lowered this probability more.
💬 maflcko commented on issue "RFC: Do we want to support fuzzing on MacOS?":
(https://github.com/bitcoin/bitcoin/issues/33731#issuecomment-3560406701)
If `--preset=libfuzzer-nosan` is the only thing that works reliably, then only that should be mentioned. And possibly mention the option to reproduce existing fuzz inputs with a sanitizer, without libfuzzer.
(https://github.com/bitcoin/bitcoin/issues/33731#issuecomment-3560406701)
If `--preset=libfuzzer-nosan` is the only thing that works reliably, then only that should be mentioned. And possibly mention the option to reproduce existing fuzz inputs with a sanitizer, without libfuzzer.
💬 hebasto commented on pull request "depends, doc: Learn `x86_64-w64-mingw32ucrt` host and document it":
(https://github.com/bitcoin/bitcoin/pull/33857#discussion_r2547912404)
Thanks! Dropped.
(https://github.com/bitcoin/bitcoin/pull/33857#discussion_r2547912404)
Thanks! Dropped.
💬 Crypt-iQ commented on pull request "net: Provide block templates to peers on request":
(https://github.com/bitcoin/bitcoin/pull/33191#discussion_r2547912908)
It could also be done with standard txns: if there are 25 txn's each 320KWU, it's also not possible to split.
I guess I'm wondering how this protocol should handle not being able to split an 8MWU template into two chunks? It could split it into three or give up if these witness-heavy cases are pathological.
(https://github.com/bitcoin/bitcoin/pull/33191#discussion_r2547912908)
It could also be done with standard txns: if there are 25 txn's each 320KWU, it's also not possible to split.
I guess I'm wondering how this protocol should handle not being able to split an 8MWU template into two chunks? It could split it into three or give up if these witness-heavy cases are pathological.
✅ maflcko closed an issue: "test: spurious failure in p2p_leak_tx.py --v1transport"
(https://github.com/bitcoin/bitcoin/issues/33090)
(https://github.com/bitcoin/bitcoin/issues/33090)
💬 maflcko commented on issue "test: spurious failure in p2p_leak_tx.py --v1transport":
(https://github.com/bitcoin/bitcoin/issues/33090#issuecomment-3560422313)
closing for now. a new issue can be opened, the next time this happens again.
(https://github.com/bitcoin/bitcoin/issues/33090#issuecomment-3560422313)
closing for now. a new issue can be opened, the next time this happens again.
💬 maflcko commented on pull request "ci: Enable experimental kernel stuff in most CI tasks via `dev-mode`":
(https://github.com/bitcoin/bitcoin/pull/33824#discussion_r2547946443)
This lead to a failure: https://github.com/maflcko/bitcoin-core-nightly/actions/runs/19550555322/job/55988016546#step:12:25:
```
stdout:
2025-11-20T22:23:58.576632Z TestFramework (INFO): PRNG seed is: 4045980459550867813
2025-11-20T22:23:58.577475Z TestFramework (INFO): Initializing test directory /Users/runner/work/_temp/test_runner_₿_🏃_20251120_220520/tool_bitcoin_chainstate_201
2025-11-20T22:23:59.071213Z TestFramework (INFO): Testing bitcoin-chainstate ['/Users/runner/work/bitcoin-core-ni
...
(https://github.com/bitcoin/bitcoin/pull/33824#discussion_r2547946443)
This lead to a failure: https://github.com/maflcko/bitcoin-core-nightly/actions/runs/19550555322/job/55988016546#step:12:25:
```
stdout:
2025-11-20T22:23:58.576632Z TestFramework (INFO): PRNG seed is: 4045980459550867813
2025-11-20T22:23:58.577475Z TestFramework (INFO): Initializing test directory /Users/runner/work/_temp/test_runner_₿_🏃_20251120_220520/tool_bitcoin_chainstate_201
2025-11-20T22:23:59.071213Z TestFramework (INFO): Testing bitcoin-chainstate ['/Users/runner/work/bitcoin-core-ni
...
💬 hebasto commented on pull request "depends, doc: Learn `x86_64-w64-mingw32ucrt` host and document it":
(https://github.com/bitcoin/bitcoin/pull/33857#issuecomment-3560480250)
> If we are migrating, should we just do this at this same time as we actually migrate, then we don't have to worry about both. Are we dropping support for the old runtime at the same time we switch to using the new ones in releases?
Yes, we are going to migrate the Windows release binaries to UCRT.
However, the depends build subsystem has capabilities to build for a wider range of targets than those used in releases. This is well documented in README.md, which refers, for example, to `i68
...
(https://github.com/bitcoin/bitcoin/pull/33857#issuecomment-3560480250)
> If we are migrating, should we just do this at this same time as we actually migrate, then we don't have to worry about both. Are we dropping support for the old runtime at the same time we switch to using the new ones in releases?
Yes, we are going to migrate the Windows release binaries to UCRT.
However, the depends build subsystem has capabilities to build for a wider range of targets than those used in releases. This is well documented in README.md, which refers, for example, to `i68
...
💬 hebasto commented on pull request "depends, doc: Learn `x86_64-w64-mingw32ucrt` host and document it":
(https://github.com/bitcoin/bitcoin/pull/33857#discussion_r2547970130)
Given that full UCRT-capable toolchains are not yet available across all major distributions, developers on Ubuntu, for example, may still want to build for `x86_64-w64-mingw32`.
(https://github.com/bitcoin/bitcoin/pull/33857#discussion_r2547970130)
Given that full UCRT-capable toolchains are not yet available across all major distributions, developers on Ubuntu, for example, may still want to build for `x86_64-w64-mingw32`.
💬 l0rinc commented on pull request "precalculate SipHash constant salt XORs":
(https://github.com/bitcoin/bitcoin/pull/30442#discussion_r2548060905)
Done
(https://github.com/bitcoin/bitcoin/pull/30442#discussion_r2548060905)
Done
💬 l0rinc commented on pull request "precalculate SipHash constant salt XORs":
(https://github.com/bitcoin/bitcoin/pull/30442#discussion_r2548060973)
Added some comments, please check them out
(https://github.com/bitcoin/bitcoin/pull/30442#discussion_r2548060973)
Added some comments, please check them out