💬 sipa commented on pull request "tracing: network connection tracepoints":
(https://github.com/bitcoin/bitcoin/pull/25832#issuecomment-2646354848)
> The BIP155 approach is a bit more involved with making GetBIP155Network() public, introducing a ConnectedThroughBIP155Network() helper, and passing 0 (or something else?) for NET_INTERNAL as there is no BIP155 equivalent.
Given that BIP155 network IDs are uint8_t's, I think it suffices to pick a value outside of that range for unreachable. For example, 0x100, or 0xffffffff for a `uint32_t, or -1 for a signed integer type.
(https://github.com/bitcoin/bitcoin/pull/25832#issuecomment-2646354848)
> The BIP155 approach is a bit more involved with making GetBIP155Network() public, introducing a ConnectedThroughBIP155Network() helper, and passing 0 (or something else?) for NET_INTERNAL as there is no BIP155 equivalent.
Given that BIP155 network IDs are uint8_t's, I think it suffices to pick a value outside of that range for unreachable. For example, 0x100, or 0xffffffff for a `uint32_t, or -1 for a signed integer type.
🤔 sipa reviewed a pull request: "Limit retries in GetRNDRRS to avoid infinite loop"
(https://github.com/bitcoin/bitcoin/pull/31826#pullrequestreview-2604310733)
utACK 03beb9c0bf2cb4a4022a1f9f94a6093fb4021154
(https://github.com/bitcoin/bitcoin/pull/31826#pullrequestreview-2604310733)
utACK 03beb9c0bf2cb4a4022a1f9f94a6093fb4021154
💬 fjahr commented on pull request "contrib: fix `test_deterministic_coverage.sh` script for out-of-tree builds":
(https://github.com/bitcoin/bitcoin/pull/31588#issuecomment-2646395385)
> Note that GCOV_EXECUTABLE is hardcoded in the script currently, so setting it as environment variable won't have any effect.
Ah, I had indeed missed that. I tried this for llvm but it didn't change the outcome, seems to be the same issue. I didn't investigate further there and instead tried again with gcc-14, given this is at least a bit closer to your tooling. I get another error there with this. It appears the compile time macros are confusing gcov and it sees `secp256k1_scalar_split_lam
...
(https://github.com/bitcoin/bitcoin/pull/31588#issuecomment-2646395385)
> Note that GCOV_EXECUTABLE is hardcoded in the script currently, so setting it as environment variable won't have any effect.
Ah, I had indeed missed that. I tried this for llvm but it didn't change the outcome, seems to be the same issue. I didn't investigate further there and instead tried again with gcc-14, given this is at least a bit closer to your tooling. I get another error there with this. It appears the compile time macros are confusing gcov and it sees `secp256k1_scalar_split_lam
...
💬 Christewart commented on pull request "tests: Add witness commitment if we have a witness transaction in `FullBlockTest.update_block()`":
(https://github.com/bitcoin/bitcoin/pull/31823#issuecomment-2646450622)
> 1. Is there any test case that can be covered in the current implementation that needs this change to be implemented?
There is not currently. This short coming in the test framework was discovered while working on test cases for disallowing 64 byte transactions in the bitcoin blockchain. This python test case would not fail correctly if this change wasn't added to the test framework: https://github.com/ajtowns/bitcoin/pull/13/files#diff-d390e9e12bfa34a462fdff9f1894d7dc3edb45c26cf55df486d9
...
(https://github.com/bitcoin/bitcoin/pull/31823#issuecomment-2646450622)
> 1. Is there any test case that can be covered in the current implementation that needs this change to be implemented?
There is not currently. This short coming in the test framework was discovered while working on test cases for disallowing 64 byte transactions in the bitcoin blockchain. This python test case would not fail correctly if this change wasn't added to the test framework: https://github.com/ajtowns/bitcoin/pull/13/files#diff-d390e9e12bfa34a462fdff9f1894d7dc3edb45c26cf55df486d9
...
🤔 sins921 reviewed a pull request: "refactor: Print verbose serialize compiler error messages"
(https://github.com/bitcoin/bitcoin/pull/29056#pullrequestreview-2604454205)
Gracias
(https://github.com/bitcoin/bitcoin/pull/29056#pullrequestreview-2604454205)
Gracias
📝 glozow opened a pull request: "p2p: improve TxOrphanage denial of service bounds and increase -maxorphantxs"
(https://github.com/bitcoin/bitcoin/pull/31829)
This PR is built on top of #31810 and is part of the orphan resolution project, see #27463.
We want to limit the CPU work and memory used by `TxOrphanage` to avoid denial of service attacks. On master, this is achieved by limiting the number of transactions in this data structure to 100, and the weight of each transaction to 400KWu (the largest standard tx) [0]. We always allow new orphans, but if the addition causes us to exceed 100, we evict one randomly. This is dead simple, but makes the
...
(https://github.com/bitcoin/bitcoin/pull/31829)
This PR is built on top of #31810 and is part of the orphan resolution project, see #27463.
We want to limit the CPU work and memory used by `TxOrphanage` to avoid denial of service attacks. On master, this is achieved by limiting the number of transactions in this data structure to 100, and the weight of each transaction to 400KWu (the largest standard tx) [0]. We always allow new orphans, but if the addition causes us to exceed 100, we evict one randomly. This is dead simple, but makes the
...
💬 hebasto commented on something "":
(https://github.com/bitcoin/bitcoin/commit/332655cb52c8f8ef64b29b09e38ef5d61235ed21#r152331640)
> Why not pass a version string to project command and use something like `PROJECT_VERSION_MAJOR` in places where `CLIENT_VERSION_MAJOR` is used at the moment?
This approach was indeed considered first.
Will the `project()` command handle the "29.0.0rc1" version string properly?
(https://github.com/bitcoin/bitcoin/commit/332655cb52c8f8ef64b29b09e38ef5d61235ed21#r152331640)
> Why not pass a version string to project command and use something like `PROJECT_VERSION_MAJOR` in places where `CLIENT_VERSION_MAJOR` is used at the moment?
This approach was indeed considered first.
Will the `project()` command handle the "29.0.0rc1" version string properly?
⚠️ brunoerg opened an issue: "Branch and Bound producing change"
(https://github.com/bitcoin/bitcoin/issues/31830)
My fuzz server crashed due to Branch and Bound producing change. I could reproduce the issue with the following test:
```cpp
BOOST_AUTO_TEST_CASE(bnb_change)
{
FastRandomContext fast_random_context{};
CoinSelectionParams coin_params{
/*rng_fast*/fast_random_context,
/*change_output_size=*/31,
/*change_spend_size=*/68,
/*min_change_target=*/50'000,
/*effective_feerate=*/CFeeRate(5000),
/*long_term_feerate=*/CFeeRate(10'000),
/*disca
...
(https://github.com/bitcoin/bitcoin/issues/31830)
My fuzz server crashed due to Branch and Bound producing change. I could reproduce the issue with the following test:
```cpp
BOOST_AUTO_TEST_CASE(bnb_change)
{
FastRandomContext fast_random_context{};
CoinSelectionParams coin_params{
/*rng_fast*/fast_random_context,
/*change_output_size=*/31,
/*change_spend_size=*/68,
/*min_change_target=*/50'000,
/*effective_feerate=*/CFeeRate(5000),
/*long_term_feerate=*/CFeeRate(10'000),
/*disca
...
💬 ryanofsky commented on pull request "multiprocess: Add libmultiprocess git subtree":
(https://github.com/bitcoin/bitcoin/pull/31741#issuecomment-2646919080)
Rebased b375aeaeefb70023c3c2cd74e3841e382473b292 -> e7743aa5df6387964c23f0629debf8c3cbb8ed4c ([`pr/subtree.12`](https://github.com/ryanofsky/bitcoin/commits/pr/subtree.12) -> [`pr/subtree.13`](https://github.com/ryanofsky/bitcoin/commits/pr/subtree.13), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/subtree.12-rebase..pr/subtree.13)) adding https://github.com/chaincodelabs/libmultiprocess/pull/159 and marking capnp cmake variables as advanced as requested.
> Could the `CAPNP_EXECUT
...
(https://github.com/bitcoin/bitcoin/pull/31741#issuecomment-2646919080)
Rebased b375aeaeefb70023c3c2cd74e3841e382473b292 -> e7743aa5df6387964c23f0629debf8c3cbb8ed4c ([`pr/subtree.12`](https://github.com/ryanofsky/bitcoin/commits/pr/subtree.12) -> [`pr/subtree.13`](https://github.com/ryanofsky/bitcoin/commits/pr/subtree.13), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/subtree.12-rebase..pr/subtree.13)) adding https://github.com/chaincodelabs/libmultiprocess/pull/159 and marking capnp cmake variables as advanced as requested.
> Could the `CAPNP_EXECUT
...
✅ ryanofsky closed a pull request: "multiprocess: Lock CapnpProtocol::m_loop with mutex"
(https://github.com/bitcoin/bitcoin/pull/31815)
(https://github.com/bitcoin/bitcoin/pull/31815)
💬 ryanofsky commented on pull request "multiprocess: Lock CapnpProtocol::m_loop with mutex":
(https://github.com/bitcoin/bitcoin/pull/31815#issuecomment-2646931290)
I reproduced the bug locally (see https://github.com/chaincodelabs/libmultiprocess/issues/154#issuecomment-2646926155) and implemented a different fix in https://github.com/chaincodelabs/libmultiprocess/pull/159, which should make these changes unnecessary, because instead of trying to delay eventloop destruction in Bitcoin code until all locks are released, it just avoids reacquiring a lock unnecessary and pretents eventloop::loop() from returning until all locks are released so it won't be des
...
(https://github.com/bitcoin/bitcoin/pull/31815#issuecomment-2646931290)
I reproduced the bug locally (see https://github.com/chaincodelabs/libmultiprocess/issues/154#issuecomment-2646926155) and implemented a different fix in https://github.com/chaincodelabs/libmultiprocess/pull/159, which should make these changes unnecessary, because instead of trying to delay eventloop destruction in Bitcoin code until all locks are released, it just avoids reacquiring a lock unnecessary and pretents eventloop::loop() from returning until all locks are released so it won't be des
...
💬 rhysbeynon commented on pull request "Updated MacOS icon to more closely fit Apple's design standards":
(https://github.com/bitcoin-core/gui/pull/852#issuecomment-2646981748)


Some screenshots to show size difference in context of other apps in a populated dock.
(https://github.com/bitcoin-core/gui/pull/852#issuecomment-2646981748)


Some screenshots to show size difference in context of other apps in a populated dock.
📝 ShivaanjayNarula opened a pull request: "imp"
(https://github.com/bitcoin/bitcoin/pull/31831)
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed
immediately.
GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->
<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:
* Any test improvements or new tests that improv
...
(https://github.com/bitcoin/bitcoin/pull/31831)
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed
immediately.
GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->
<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:
* Any test improvements or new tests that improv
...
✅ hebasto closed a pull request: "."
(https://github.com/bitcoin/bitcoin/pull/31831)
(https://github.com/bitcoin/bitcoin/pull/31831)
📝 hebasto locked a pull request: "."
(https://github.com/bitcoin/bitcoin/pull/31831)
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed
immediately.
GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->
<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:
* Any test improvements or new tests that improv
...
(https://github.com/bitcoin/bitcoin/pull/31831)
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed
immediately.
GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->
<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:
* Any test improvements or new tests that improv
...
💬 hebasto commented on pull request "Updated MacOS icon to more closely fit Apple's design standards":
(https://github.com/bitcoin-core/gui/pull/852#issuecomment-2647219126)
> The .icns file was compiled using Apple's own "iconutil" cli program.
What are steps to reproduce the new `src/qt/res/icons/bitcoin.icns` file?
(https://github.com/bitcoin-core/gui/pull/852#issuecomment-2647219126)
> The .icns file was compiled using Apple's own "iconutil" cli program.
What are steps to reproduce the new `src/qt/res/icons/bitcoin.icns` file?
⚠️ embetrix opened an issue: "Wallets not automatically loaded"
(https://github.com/bitcoin/bitcoin/issues/31832)
### Is there an existing issue for this?
- [x] I have searched the existing issues
### Current behaviour
after starting `bitcoind` the wallets are not automatically loaded
### Expected behaviour
thee wallets should be automatically loaded
### Steps to reproduce
My bitcoin.conf
```
pid=/run/bitcoin/bitcoind.pid
nodebuglogfile=1
datadir=/var/bitcoin
loglevel=info
proxy=127.0.0.1:9050
testnet4=1
[testnet4]
walletdir=/var/wallet
server=1
rpcuser=satobox
rpcport=8332
rpcconnect=127.0.0.1
rp
...
(https://github.com/bitcoin/bitcoin/issues/31832)
### Is there an existing issue for this?
- [x] I have searched the existing issues
### Current behaviour
after starting `bitcoind` the wallets are not automatically loaded
### Expected behaviour
thee wallets should be automatically loaded
### Steps to reproduce
My bitcoin.conf
```
pid=/run/bitcoin/bitcoind.pid
nodebuglogfile=1
datadir=/var/bitcoin
loglevel=info
proxy=127.0.0.1:9050
testnet4=1
[testnet4]
walletdir=/var/wallet
server=1
rpcuser=satobox
rpcport=8332
rpcconnect=127.0.0.1
rp
...
💬 Sjors commented on pull request "multiprocess: Lock CapnpProtocol::m_loop with mutex":
(https://github.com/bitcoin/bitcoin/pull/31815#issuecomment-2647256950)
Thanks. I dropped this from #30975 and rebased on your latest #31741 which contains https://github.com/chaincodelabs/libmultiprocess/pull/159.
(https://github.com/bitcoin/bitcoin/pull/31815#issuecomment-2647256950)
Thanks. I dropped this from #30975 and rebased on your latest #31741 which contains https://github.com/chaincodelabs/libmultiprocess/pull/159.
💬 maflcko commented on issue "Wallets not automatically loaded":
(https://github.com/bitcoin/bitcoin/issues/31832#issuecomment-2647313705)
If you want to have a wallet loaded on startup, you'll have to set `load_on_startup` to `True`.
To learn more about the `loadwallet` RPC, you can try `help loadwallet`.
(https://github.com/bitcoin/bitcoin/issues/31832#issuecomment-2647313705)
If you want to have a wallet loaded on startup, you'll have to set `load_on_startup` to `True`.
To learn more about the `loadwallet` RPC, you can try `help loadwallet`.
💬 maflcko commented on issue "Wallets not automatically loaded":
(https://github.com/bitcoin/bitcoin/issues/31832#issuecomment-2647314964)
Usually the issue tracker is used to track technical issues related to the Bitcoin Core code base.
General bitcoin questions and/or support requests are best directed to the [Bitcoin StackExchange](https://bitcoin.stackexchange.com) or the `#bitcoin` IRC channel on Libera Chat, or one of the Bitcoin subreddits, or any other place that you feel is well suited.
(https://github.com/bitcoin/bitcoin/issues/31832#issuecomment-2647314964)
Usually the issue tracker is used to track technical issues related to the Bitcoin Core code base.
General bitcoin questions and/or support requests are best directed to the [Bitcoin StackExchange](https://bitcoin.stackexchange.com) or the `#bitcoin` IRC channel on Libera Chat, or one of the Bitcoin subreddits, or any other place that you feel is well suited.