💬 davidgumberg commented on pull request "deps: Bump lief to 0.16.5":
(https://github.com/bitcoin/bitcoin/pull/32431#discussion_r2080687125)
Yes, but it was to appease the CI linter, I understand now that this script is not meant for general use, so I changed this to just cast to `lief.Binary` without checking
(https://github.com/bitcoin/bitcoin/pull/32431#discussion_r2080687125)
Yes, but it was to appease the CI linter, I understand now that this script is not meant for general use, so I changed this to just cast to `lief.Binary` without checking
💬 0xBEEFCAF3 commented on pull request "CAT in Tapscript (BIP-347)":
(https://github.com/bitcoin/bitcoin/pull/29247#issuecomment-2864936156)
>Let me see if there is anything that can be done to ensure it is never the case that OP_CAT = False && DISCOURAGE_OP_CAT = False since that should never happen outside of tests.
By default, the `SCRIPT_VERIFY_DISCOURAGE_OP_CAT` bit [is set](https://github.com/bitcoin/bitcoin/pull/29247/files#diff-1fc0f6b5081e8ed5dfa8bf230744ad08cc6f4c1147e98552f1f424b0492fe9bdR121), and we do not expose this as a configurable mempool policy. The only practical way for node operators to unset this bit (`SCRIP
...
(https://github.com/bitcoin/bitcoin/pull/29247#issuecomment-2864936156)
>Let me see if there is anything that can be done to ensure it is never the case that OP_CAT = False && DISCOURAGE_OP_CAT = False since that should never happen outside of tests.
By default, the `SCRIPT_VERIFY_DISCOURAGE_OP_CAT` bit [is set](https://github.com/bitcoin/bitcoin/pull/29247/files#diff-1fc0f6b5081e8ed5dfa8bf230744ad08cc6f4c1147e98552f1f424b0492fe9bdR121), and we do not expose this as a configurable mempool policy. The only practical way for node operators to unset this bit (`SCRIP
...
📝 jb55 opened a pull request: "tracing: fix invalid argument in mempool_monitor"
(https://github.com/bitcoin/bitcoin/pull/32454)
The mempool_monitor tracing tool is incorrectly reading the reason as the first argument, which is incorrect. Fix this!
Noticed this during the bitcoin++ mempool hackathon 😅
cc @0xB10C
(https://github.com/bitcoin/bitcoin/pull/32454)
The mempool_monitor tracing tool is incorrectly reading the reason as the first argument, which is incorrect. Fix this!
Noticed this during the bitcoin++ mempool hackathon 😅
cc @0xB10C
💬 Eunovo commented on pull request "Wallet: Fix Non-Ranged Descriptors with Range [0,0] Trigger Unexpected Wallet Errors in AddWalletDescriptor":
(https://github.com/bitcoin/bitcoin/pull/32344#issuecomment-2865239247)
> Including a range in a non-ranged descriptor import should cause the process to fail before reaching the wallet descriptor update function.
AFAICT this will cause `importdescriptor` to throw an error with the message "Range should not be specified for an un-ranged descriptor"
(https://github.com/bitcoin/bitcoin/pull/32344#issuecomment-2865239247)
> Including a range in a non-ranged descriptor import should cause the process to fail before reaching the wallet descriptor update function.
AFAICT this will cause `importdescriptor` to throw an error with the message "Range should not be specified for an un-ranged descriptor"
⚠️ hMsats opened an issue: "Self-compiled bitcoind 29.0 much slower than self-compiled 28.0 on my system"
(https://github.com/bitcoin/bitcoin/issues/32455)
I always compile the bitcoin software myself (`Ubuntu 24.04.2 LTS`). For `bitcoin-29.0` I compiled it (of course) for the first time with `cmake` (with and without `berkeley-db`).
For both (with and without `berkeley-db`), `bitcoind-29.0` is much slower than `bitcoin-28.0` which gives me problems on my server.
To investigate I wrote a shell script that determines the time difference in seconds between "Saw new header" and "UpdateTip":
```
2025-05-09T05:24:11Z Saw new header hash=000000000000
...
(https://github.com/bitcoin/bitcoin/issues/32455)
I always compile the bitcoin software myself (`Ubuntu 24.04.2 LTS`). For `bitcoin-29.0` I compiled it (of course) for the first time with `cmake` (with and without `berkeley-db`).
For both (with and without `berkeley-db`), `bitcoind-29.0` is much slower than `bitcoin-28.0` which gives me problems on my server.
To investigate I wrote a shell script that determines the time difference in seconds between "Saw new header" and "UpdateTip":
```
2025-05-09T05:24:11Z Saw new header hash=000000000000
...
💬 fanquake commented on issue "Self-compiled bitcoind 29.0 much slower than self-compiled 28.0 on my system":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2865331250)
> So my first question before I investigate any further is: how come my bitcoind is so big compared to the pre-compiled one?
This will be the debug symbols. If you run 'strip' on the binaries. i.e 'strip bitcoind' this debug information will be removed, and the size of your binaries should shrink 80-90%.
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2865331250)
> So my first question before I investigate any further is: how come my bitcoind is so big compared to the pre-compiled one?
This will be the debug symbols. If you run 'strip' on the binaries. i.e 'strip bitcoind' this debug information will be removed, and the size of your binaries should shrink 80-90%.
💬 0xB10C commented on pull request "tracing: fix invalid argument in mempool_monitor":
(https://github.com/bitcoin/bitcoin/pull/32454#issuecomment-2865366915)
Code Review ACK 31c5ebc4007884b655f2f90ca09e36e0b9ada4da
Seems like I introduced that bug in https://github.com/bitcoin/bitcoin/pull/31848 (ec47ba349d0b3cb2d274593ca7b828ae70584e10).
(https://github.com/bitcoin/bitcoin/pull/32454#issuecomment-2865366915)
Code Review ACK 31c5ebc4007884b655f2f90ca09e36e0b9ada4da
Seems like I introduced that bug in https://github.com/bitcoin/bitcoin/pull/31848 (ec47ba349d0b3cb2d274593ca7b828ae70584e10).
💬 polespinasa commented on pull request "tests: Expand HTTP coverage to assert libevent behavior":
(https://github.com/bitcoin/bitcoin/pull/32408#discussion_r2081079062)
I'm not sure about this but shouldn't this be `socket.timeout`? As we're using `sock.recv` and not `getresponse()`?
(https://github.com/bitcoin/bitcoin/pull/32408#discussion_r2081079062)
I'm not sure about this but shouldn't this be `socket.timeout`? As we're using `sock.recv` and not `getresponse()`?
🤔 polespinasa reviewed a pull request: "tests: Expand HTTP coverage to assert libevent behavior"
(https://github.com/bitcoin/bitcoin/pull/32408#pullrequestreview-2827278739)
tACK 840dd5b6eb0b2c1f35a91c36acac5d97933172dc
Maybe the three commits could be squashed?
(https://github.com/bitcoin/bitcoin/pull/32408#pullrequestreview-2827278739)
tACK 840dd5b6eb0b2c1f35a91c36acac5d97933172dc
Maybe the three commits could be squashed?
💬 polespinasa commented on pull request "tests: Expand HTTP coverage to assert libevent behavior":
(https://github.com/bitcoin/bitcoin/pull/32408#discussion_r2081097699)
If the timeout is set to 2 wouldn't make more sense to test between 2 and 4 seconds? Can it be less than 2 seconds?
(https://github.com/bitcoin/bitcoin/pull/32408#discussion_r2081097699)
If the timeout is set to 2 wouldn't make more sense to test between 2 and 4 seconds? Can it be less than 2 seconds?
💬 hMsats commented on issue "Self-compiled bitcoind 29.0 much slower than self-compiled 28.0 on my system":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2865489117)
@fanquake Thanks a lot! I expected something like this (debug info) but thought it was some compiler option. The `strip` worked and now my bitcoind is only 12 MB 👍. As I never used `strip` on `bitcoin-28.0` I don't expect this to make a difference but will try it first on my server anyway or could it?
This is very confusing. I'm a long time bitcoin node runner and linux user but would never have thought of this possibility. **Shouldn't this be mentioned in the `doc/build-unix.md`?**
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2865489117)
@fanquake Thanks a lot! I expected something like this (debug info) but thought it was some compiler option. The `strip` worked and now my bitcoind is only 12 MB 👍. As I never used `strip` on `bitcoin-28.0` I don't expect this to make a difference but will try it first on my server anyway or could it?
This is very confusing. I'm a long time bitcoin node runner and linux user but would never have thought of this possibility. **Shouldn't this be mentioned in the `doc/build-unix.md`?**
⚠️ hodlinator opened an issue: "qa: Failure in wallet_basic.py spendzeroconfchange test"
(https://github.com/bitcoin/bitcoin/issues/32456)
CI failure upon merge of my PR (ad5cd129f3cc72f2d2b140e182781bf3bb5dbacc): https://github.com/bitcoin/bitcoin/actions/runs/14916001314/job/41901630172
Relevant high-level log:
```
22/267 - wallet_basic.py failed, Duration: 23 s
stdout:
2025-05-08T21:04:47.763000Z TestFramework (INFO): PRNG seed is: 1820560705145373934
2025-05-08T21:04:47.764000Z TestFramework (INFO): Initializing test directory /Users/runner/work/bitcoin/bitcoin/ci/scratch/test_runner/test_runner_₿_🏃_20250508_210317/wallet_ba
...
(https://github.com/bitcoin/bitcoin/issues/32456)
CI failure upon merge of my PR (ad5cd129f3cc72f2d2b140e182781bf3bb5dbacc): https://github.com/bitcoin/bitcoin/actions/runs/14916001314/job/41901630172
Relevant high-level log:
```
22/267 - wallet_basic.py failed, Duration: 23 s
stdout:
2025-05-08T21:04:47.763000Z TestFramework (INFO): PRNG seed is: 1820560705145373934
2025-05-08T21:04:47.764000Z TestFramework (INFO): Initializing test directory /Users/runner/work/bitcoin/bitcoin/ci/scratch/test_runner/test_runner_₿_🏃_20250508_210317/wallet_ba
...
💬 vasild commented on pull request "multiprocess: Add bitcoin wrapper executable":
(https://github.com/bitcoin/bitcoin/pull/31375#discussion_r2081139299)
> `bitcoin daemon -daemon`
Good point. Indeed I find that super not-intuitive, I did not think about that before. I would strongly prefer to rename it to `node`, e.g. `bitcoin node -daemon`.
> `bitcoind -daemon` already means the same thing
Eh, but somehow I don't find it so perplexing. Or even if it is as confusing, now we have a chance to pick better names.
(https://github.com/bitcoin/bitcoin/pull/31375#discussion_r2081139299)
> `bitcoin daemon -daemon`
Good point. Indeed I find that super not-intuitive, I did not think about that before. I would strongly prefer to rename it to `node`, e.g. `bitcoin node -daemon`.
> `bitcoind -daemon` already means the same thing
Eh, but somehow I don't find it so perplexing. Or even if it is as confusing, now we have a chance to pick better names.
💬 hebasto commented on pull request "depends: Avoid using helper variables in toolchain file":
(https://github.com/bitcoin/bitcoin/pull/31360#issuecomment-2865541704)
My Guix build:
```
aarch64
cab0e4d3d2602d2eaa8893ae5294bd736b514fea6deb72df03c4d693971282dd guix-build-7343a1846ceb/output/aarch64-linux-gnu/SHA256SUMS.part
21163373fc74e834f3d81309888fc4cd99719462be8fef447e535fb56aa5ce1e guix-build-7343a1846ceb/output/aarch64-linux-gnu/bitcoin-7343a1846ceb-aarch64-linux-gnu-debug.tar.gz
b09ca7a33bf16d3e97bce8800bf57a06402a9cf4860d327be3d6571a56be598c guix-build-7343a1846ceb/output/aarch64-linux-gnu/bitcoin-7343a1846ceb-aarch64-linux-gnu.tar.gz
f1b2aa3e
...
(https://github.com/bitcoin/bitcoin/pull/31360#issuecomment-2865541704)
My Guix build:
```
aarch64
cab0e4d3d2602d2eaa8893ae5294bd736b514fea6deb72df03c4d693971282dd guix-build-7343a1846ceb/output/aarch64-linux-gnu/SHA256SUMS.part
21163373fc74e834f3d81309888fc4cd99719462be8fef447e535fb56aa5ce1e guix-build-7343a1846ceb/output/aarch64-linux-gnu/bitcoin-7343a1846ceb-aarch64-linux-gnu-debug.tar.gz
b09ca7a33bf16d3e97bce8800bf57a06402a9cf4860d327be3d6571a56be598c guix-build-7343a1846ceb/output/aarch64-linux-gnu/bitcoin-7343a1846ceb-aarch64-linux-gnu.tar.gz
f1b2aa3e
...
💬 maflcko commented on issue "Self-compiled bitcoind 29.0 much slower than self-compiled 28.0 on my system":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2865595699)
What are your settings?
Can you share the debug log?
Can you run with the debug categories `bench, blockstorage, lock, prune, validation`, and possibly `rpc`, if there is a background caller?
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2865595699)
What are your settings?
Can you share the debug log?
Can you run with the debug categories `bench, blockstorage, lock, prune, validation`, and possibly `rpc`, if there is a background caller?
🚀 fanquake merged a pull request: "tracing: fix invalid argument in mempool_monitor"
(https://github.com/bitcoin/bitcoin/pull/32454)
(https://github.com/bitcoin/bitcoin/pull/32454)
💬 hMsats commented on issue "Self-compiled bitcoind 29.0 much slower than self-compiled 28.0 on my system":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2865633695)
@maflcko I will but it will take some time as I'm on vacation right now but will investigate when I have time.
Created `bitcoind` via:
`cmake -B build -DWITH_ZMQ=ON -DBUILD_GUI=ON`
Settings (same as for 28.0):
```
txindex=1
rpcthreads=4
rpcworkqueue=64
dbcache=2500
maxconnections=100
permitbaremultisig=0
datacarrier=0
```
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2865633695)
@maflcko I will but it will take some time as I'm on vacation right now but will investigate when I have time.
Created `bitcoind` via:
`cmake -B build -DWITH_ZMQ=ON -DBUILD_GUI=ON`
Settings (same as for 28.0):
```
txindex=1
rpcthreads=4
rpcworkqueue=64
dbcache=2500
maxconnections=100
permitbaremultisig=0
datacarrier=0
```
💬 fanquake commented on pull request "tracing: fix invalid argument in mempool_monitor":
(https://github.com/bitcoin/bitcoin/pull/32454#issuecomment-2865654520)
Backported to `29.x` in #32292.
(https://github.com/bitcoin/bitcoin/pull/32454#issuecomment-2865654520)
Backported to `29.x` in #32292.
💬 l0rinc commented on issue "qa: Failure in wallet_basic.py spendzeroconfchange test":
(https://github.com/bitcoin/bitcoin/issues/32456#issuecomment-2865716098)
I can't reproduce it either on my Mac - but it does seem to be passing with latest push at least.
<img width="549" alt="Image" src="https://github.com/user-attachments/assets/30b441f9-a8d0-44ff-b23c-2529a7de424a" />
(https://github.com/bitcoin/bitcoin/issues/32456#issuecomment-2865716098)
I can't reproduce it either on my Mac - but it does seem to be passing with latest push at least.
<img width="549" alt="Image" src="https://github.com/user-attachments/assets/30b441f9-a8d0-44ff-b23c-2529a7de424a" />
💬 maflcko commented on pull request "build: let CMake determine the year":
(https://github.com/bitcoin/bitcoin/pull/32445#issuecomment-2865717510)
Not sure if this is worth it. Currently 4 lines of code need to be changed, looking at b537a2c02a9921235d1ecf8c3c7dc1836ec68131. After this, 3 lines will need to be changed. I don't really see the benefit here.
Whereas this comes with downsides:
* People compiling an ancient EOL version/commit will get the impression that they are running a recent release from the current year. This could lead them to thinking they have the latest security patches.
* Conversely, people setting a fixed, bu
...
(https://github.com/bitcoin/bitcoin/pull/32445#issuecomment-2865717510)
Not sure if this is worth it. Currently 4 lines of code need to be changed, looking at b537a2c02a9921235d1ecf8c3c7dc1836ec68131. After this, 3 lines will need to be changed. I don't really see the benefit here.
Whereas this comes with downsides:
* People compiling an ancient EOL version/commit will get the impression that they are running a recent release from the current year. This could lead them to thinking they have the latest security patches.
* Conversely, people setting a fixed, bu
...