💬 kannapoix commented on issue "`rpc_getblockstats.py` fails with `--gen-test-data`":
(https://github.com/bitcoin/bitcoin/issues/31838#issuecomment-3222438327)
For anyone reproducing this issue at the current master HEAD: Please add the flag `-deprecatedrpc=settxfee`.
(https://github.com/bitcoin/bitcoin/issues/31838#issuecomment-3222438327)
For anyone reproducing this issue at the current master HEAD: Please add the flag `-deprecatedrpc=settxfee`.
✅ achow101 closed an issue: "rewrite in rust"
(https://github.com/bitcoin/bitcoin/issues/33255)
(https://github.com/bitcoin/bitcoin/issues/33255)
💬 w0xlt commented on pull request "net: Prevent node from binding to the same `CService`":
(https://github.com/bitcoin/bitcoin/pull/33231#issuecomment-3222458339)
@l0rinc thank you for your detailed reviews.
> I personally would not try to correct the behavior (especially silently), given that it's rare, I would simply give the user a warning or error and let them fix the arguments.
I adjusted the approach to meet this requirement. Now when duplicates are detected, the node terminates with a clear, specific error message: "_Duplicate binding configuration for address < addr >. Please check your -bind, -whitebind, and onion binding settings._"
I d
...
(https://github.com/bitcoin/bitcoin/pull/33231#issuecomment-3222458339)
@l0rinc thank you for your detailed reviews.
> I personally would not try to correct the behavior (especially silently), given that it's rare, I would simply give the user a warning or error and let them fix the arguments.
I adjusted the approach to meet this requirement. Now when duplicates are detected, the node terminates with a clear, specific error message: "_Duplicate binding configuration for address < addr >. Please check your -bind, -whitebind, and onion binding settings._"
I d
...
💬 kannapoix commented on issue "`rpc_getblockstats.py` fails with `--gen-test-data`":
(https://github.com/bitcoin/bitcoin/issues/31838#issuecomment-3222459293)
For anyone reproducing this issue at the current master HEAD: Please add the flag -deprecatedrpc=settxfee.
```diff
diff --git a/test/functional/rpc_getblockstats.py b/test/functional/rpc_getblockstats.py
index 002763201a5..a904e56d7f0 100755
--- a/test/functional/rpc_getblockstats.py
+++ b/test/functional/rpc_getblockstats.py
@@ -24,6 +24,7 @@ class GetblockstatsTest(BitcoinTestFramework):
max_stat_pos = 2
def add_options(self, parser):
+ self.add_wallet_options(parser)
...
(https://github.com/bitcoin/bitcoin/issues/31838#issuecomment-3222459293)
For anyone reproducing this issue at the current master HEAD: Please add the flag -deprecatedrpc=settxfee.
```diff
diff --git a/test/functional/rpc_getblockstats.py b/test/functional/rpc_getblockstats.py
index 002763201a5..a904e56d7f0 100755
--- a/test/functional/rpc_getblockstats.py
+++ b/test/functional/rpc_getblockstats.py
@@ -24,6 +24,7 @@ class GetblockstatsTest(BitcoinTestFramework):
max_stat_pos = 2
def add_options(self, parser):
+ self.add_wallet_options(parser)
...
💬 ajtowns commented on pull request "Revert compact block cache inefficiencies":
(https://github.com/bitcoin/bitcoin/pull/33253#discussion_r2299685034)
This is just testing how quickly we can iterate through all the txs in the mempool when looking at a compact block -- which is the worst case scenario that can still be fast (if we finish solving the block with transactions from the extra pool, and don't need to go back to the network). Hitting duplicates automatically puts us in the slow resolve-via-network path, so benching that shouldn't be terribly interesting.
(https://github.com/bitcoin/bitcoin/pull/33253#discussion_r2299685034)
This is just testing how quickly we can iterate through all the txs in the mempool when looking at a compact block -- which is the worst case scenario that can still be fast (if we finish solving the block with transactions from the extra pool, and don't need to go back to the network). Hitting duplicates automatically puts us in the slow resolve-via-network path, so benching that shouldn't be terribly interesting.
💬 ajtowns commented on pull request "Revert compact block cache inefficiencies":
(https://github.com/bitcoin/bitcoin/pull/33253#discussion_r2299690928)
Once we've found a shortid match, looking up the actual tx is fine, so I don't think this warrants changing.
(https://github.com/bitcoin/bitcoin/pull/33253#discussion_r2299690928)
Once we've found a shortid match, looking up the actual tx is fine, so I don't think this warrants changing.
💬 ajtowns commented on pull request "Revert compact block cache inefficiencies":
(https://github.com/bitcoin/bitcoin/pull/33253#issuecomment-3222540332)
> Can we bench that? Maybe as a separate benchmark instead of having this one benchmark include both.
Added benchmarks with 50k txs in mempool and 0, 100 (default), and 5000 entries in extra pool. For reference [datum](https://github.com/OCEAN-xyz/datum_gateway) recommends setting the value to 1M.
(https://github.com/bitcoin/bitcoin/pull/33253#issuecomment-3222540332)
> Can we bench that? Maybe as a separate benchmark instead of having this one benchmark include both.
Added benchmarks with 50k txs in mempool and 0, 100 (default), and 5000 entries in extra pool. For reference [datum](https://github.com/OCEAN-xyz/datum_gateway) recommends setting the value to 1M.
💬 l0rinc commented on pull request "Revert compact block cache inefficiencies":
(https://github.com/bitcoin/bitcoin/pull/33253#discussion_r2299706227)
To make sure that's what we're testing, we should still assert the outcome of `InitData` was `READ_STATUS_OK` - otherwise it would be possible that we accidentally generated duplicates here.
(https://github.com/bitcoin/bitcoin/pull/33253#discussion_r2299706227)
To make sure that's what we're testing, we should still assert the outcome of `InitData` was `READ_STATUS_OK` - otherwise it would be possible that we accidentally generated duplicates here.
💬 w0xlt commented on issue "`feature_bind_extra.py` test fails in `test_runner` if new nodes are added":
(https://github.com/bitcoin/bitcoin/issues/33250#issuecomment-3222620994)
But MAX_NODES has a value of 12.
In the above patch, the number of nodes has been increased to 6.
(https://github.com/bitcoin/bitcoin/issues/33250#issuecomment-3222620994)
But MAX_NODES has a value of 12.
In the above patch, the number of nodes has been increased to 6.
💬 zaidmstrr commented on pull request "rpc: Handle -named argument parsing where '=' character is used":
(https://github.com/bitcoin/bitcoin/pull/32821#discussion_r2299891671)
The definition might be the same, but the purpose is entirely different. This is specifically for string RPC methods.
(https://github.com/bitcoin/bitcoin/pull/32821#discussion_r2299891671)
The definition might be the same, but the purpose is entirely different. This is specifically for string RPC methods.
💬 zaidmstrr commented on pull request "rpc: Handle -named argument parsing where '=' character is used":
(https://github.com/bitcoin/bitcoin/pull/32821#discussion_r2299891945)
There was a `@note` at around lines 328-330 explaining this behaviour.
(https://github.com/bitcoin/bitcoin/pull/32821#discussion_r2299891945)
There was a `@note` at around lines 328-330 explaining this behaviour.
💬 marcofleon commented on pull request "build: set ENABLE_IPC to OFF when fuzzing":
(https://github.com/bitcoin/bitcoin/pull/33235#issuecomment-3223004584)
> we should mostly fuzz to gain confidence in stability and correctness, for which I'd suggest:
I'm happy to work on this. Still thinking about the best approach. It seems like using fuzzamoto is ultimately most effective, but it might be worth trying to get a baseline single-process fuzz test into the repo? This would probably be a more practical starting point for me too, but I'm open to suggestions.
(https://github.com/bitcoin/bitcoin/pull/33235#issuecomment-3223004584)
> we should mostly fuzz to gain confidence in stability and correctness, for which I'd suggest:
I'm happy to work on this. Still thinking about the best approach. It seems like using fuzzamoto is ultimately most effective, but it might be worth trying to get a baseline single-process fuzz test into the repo? This would probably be a more practical starting point for me too, but I'm open to suggestions.
💬 Sjors commented on pull request "build: set ENABLE_IPC to OFF when fuzzing":
(https://github.com/bitcoin/bitcoin/pull/33235#issuecomment-3223044161)
> a baseline single-process fuzz test into the repo?
I think so yes, otherwise it might not make the branch-off.
(https://github.com/bitcoin/bitcoin/pull/33235#issuecomment-3223044161)
> a baseline single-process fuzz test into the repo?
I think so yes, otherwise it might not make the branch-off.
✅ maflcko closed an issue: "depends: `native_libmultiprocess` fails to build on OpenBSD"
(https://github.com/bitcoin/bitcoin/issues/33219)
(https://github.com/bitcoin/bitcoin/issues/33219)
💬 maflcko commented on issue "depends: `native_libmultiprocess` fails to build on OpenBSD":
(https://github.com/bitcoin/bitcoin/issues/33219#issuecomment-3223048498)
Closing for now as "fixed"
(https://github.com/bitcoin/bitcoin/issues/33219#issuecomment-3223048498)
Closing for now as "fixed"
💬 maflcko commented on issue "build: indefinite mpgen hang on Ubuntu 22.04":
(https://github.com/bitcoin/bitcoin/issues/33176#issuecomment-3223079751)
On current master this will now fail configure:
```
...
cmake -B build -DENABLE_IPC=ON
...
-- Checking for module 'capnp'
-- Found capnp, version 0.8.0
-- Checking for module 'capnp-rpc'
-- Found capnp-rpc, version 0.8.0
-- Checking for module 'capnp-json'
-- Found capnp-json, version 0.8.0
-- Checking for module 'kj'
-- Found kj, version 0.8.0
-- Checking for module 'kj-async'
-- Found kj-async, version 0.8.0
-- Checking for module 'kj-http'
-- Found kj-http, version 0.8.0
-- Chec
...
(https://github.com/bitcoin/bitcoin/issues/33176#issuecomment-3223079751)
On current master this will now fail configure:
```
...
cmake -B build -DENABLE_IPC=ON
...
-- Checking for module 'capnp'
-- Found capnp, version 0.8.0
-- Checking for module 'capnp-rpc'
-- Found capnp-rpc, version 0.8.0
-- Checking for module 'capnp-json'
-- Found capnp-json, version 0.8.0
-- Checking for module 'kj'
-- Found kj, version 0.8.0
-- Checking for module 'kj-async'
-- Found kj-async, version 0.8.0
-- Checking for module 'kj-http'
-- Found kj-http, version 0.8.0
-- Chec
...
💬 maflcko commented on issue "`feature_bind_extra.py` test fails in `test_runner` if new nodes are added":
(https://github.com/bitcoin/bitcoin/issues/33250#issuecomment-3223172462)
The test is re-using "unused" p2p ports after the 6 nodes. On master it is using 4 ports and you are using another 6, so `6+4+6=16`, which is greater than 12, no?
(https://github.com/bitcoin/bitcoin/issues/33250#issuecomment-3223172462)
The test is re-using "unused" p2p ports after the 6 nodes. On master it is using 4 ports and you are using another 6, so `6+4+6=16`, which is greater than 12, no?
💬 0xB10C commented on issue "tracing: issue running `contrib/tracing/log_utxos.bt`":
(https://github.com/bitcoin/bitcoin/issues/33227#issuecomment-3223275608)
Can not reproduce with bpftrace `v0.22.1`.
Can reproduce with bpftrace `v0.23.2` on both `aarch64` and `x86_64`.
Given the `reg type unsupported for arg#0` error, I assume it is related to how we read the txid (arg0). I looked into it a bit, but haven't been to get it to work.
```
ERROR: Error loading BPF program for BEGIN_1.
Kernel error log:
processed 104 insns (limit 1000000) max_states_per_insn 0 total_states 2 peak_states 2 mark_read 1
ERROR: Error loading BPF program for usdt__nix_sto
...
(https://github.com/bitcoin/bitcoin/issues/33227#issuecomment-3223275608)
Can not reproduce with bpftrace `v0.22.1`.
Can reproduce with bpftrace `v0.23.2` on both `aarch64` and `x86_64`.
Given the `reg type unsupported for arg#0` error, I assume it is related to how we read the txid (arg0). I looked into it a bit, but haven't been to get it to work.
```
ERROR: Error loading BPF program for BEGIN_1.
Kernel error log:
processed 104 insns (limit 1000000) max_states_per_insn 0 total_states 2 peak_states 2 mark_read 1
ERROR: Error loading BPF program for usdt__nix_sto
...
💬 Sjors commented on issue "build: indefinite mpgen hang on Ubuntu 22.04":
(https://github.com/bitcoin/bitcoin/issues/33176#issuecomment-3223277365)
I'm still investigating whether Ubuntu can be pursuaded to bump this. I received some replies on https://answers.launchpad.net/ubuntu/+source/capnproto/+question/822317 but haven't gotten around to studying those.
(https://github.com/bitcoin/bitcoin/issues/33176#issuecomment-3223277365)
I'm still investigating whether Ubuntu can be pursuaded to bump this. I received some replies on https://answers.launchpad.net/ubuntu/+source/capnproto/+question/822317 but haven't gotten around to studying those.
💬 0xB10C commented on issue "tracing: issue running `contrib/tracing/log_utxos.bt`":
(https://github.com/bitcoin/bitcoin/issues/33227#issuecomment-3223326346)
The bpftrace script `connectblock_benchmark.bt` works. It is similar but reads a block hash instead of a txid. However, not the difference between the arg0 of `block_connected` (`8@-2432(%rbp`) and e.g. arg0 of `utxocache::add` (`8@%r15`). Maybe that's the cause for the `reg type unsupported for arg#0` error.
```
$ readelf -n bitcoind
...
stapsdt 0x0000007a NT_STAPSDT (SystemTap probe descriptors)
Provider: validation
Name: block_connected
Location: 0x00000000004b394
...
(https://github.com/bitcoin/bitcoin/issues/33227#issuecomment-3223326346)
The bpftrace script `connectblock_benchmark.bt` works. It is similar but reads a block hash instead of a txid. However, not the difference between the arg0 of `block_connected` (`8@-2432(%rbp`) and e.g. arg0 of `utxocache::add` (`8@%r15`). Maybe that's the cause for the `reg type unsupported for arg#0` error.
```
$ readelf -n bitcoind
...
stapsdt 0x0000007a NT_STAPSDT (SystemTap probe descriptors)
Provider: validation
Name: block_connected
Location: 0x00000000004b394
...