💬 plebhash commented on issue "Stratum v2 via IPC Mining Interface tracking issue":
(https://github.com/bitcoin/bitcoin/issues/31098#issuecomment-2499825788)
on the pre-IPC Sv2 Template Provider that @Sjors provides [on his `sv2` branch](https://github.com/Sjors/bitcoin), we have two CLI parameters for `bitcoind`:
- `-sv2interval`
- `-sv2feedelta`
these two parameters dictated how often TP would send templates to its clients (Pool or JDC), which could happen either on a regular interval (`sv2interval`), or ad-hoc when needed (`sv2feedelta`).
it seems that the new IPC approach makes communication between `bitcoin-stratum` and `bitcoin-node`
...
(https://github.com/bitcoin/bitcoin/issues/31098#issuecomment-2499825788)
on the pre-IPC Sv2 Template Provider that @Sjors provides [on his `sv2` branch](https://github.com/Sjors/bitcoin), we have two CLI parameters for `bitcoind`:
- `-sv2interval`
- `-sv2feedelta`
these two parameters dictated how often TP would send templates to its clients (Pool or JDC), which could happen either on a regular interval (`sv2interval`), or ad-hoc when needed (`sv2feedelta`).
it seems that the new IPC approach makes communication between `bitcoin-stratum` and `bitcoin-node`
...
💬 Sjors commented on issue "Stratum v2 via IPC Mining Interface tracking issue":
(https://github.com/bitcoin/bitcoin/issues/31098#issuecomment-2499968810)
@plebhash I pushed an update to the `bitcoin-mine` (Template Provider) application yesterday in https://github.com/Sjors/bitcoin/pull/48. It has the same `-sv2interval` and `-sv2feedelta` arguments. This uses `waitNext()` from #31283 under the hood. There's no polling involved!
(https://github.com/bitcoin/bitcoin/issues/31098#issuecomment-2499968810)
@plebhash I pushed an update to the `bitcoin-mine` (Template Provider) application yesterday in https://github.com/Sjors/bitcoin/pull/48. It has the same `-sv2interval` and `-sv2feedelta` arguments. This uses `waitNext()` from #31283 under the hood. There's no polling involved!
💬 vasild commented on pull request "ci: detect outbound internet traffic generated while running tests":
(https://github.com/bitcoin/bitcoin/pull/31349#discussion_r1858069999)
On some of the VMs this produces:
```
[09:47:01.270] + tcpdump -n -i eth0 -w /tmp/tcpdump_eth0
[09:47:01.334] tcpdump: eth0: You don't have permission to perform this capture on that device
[09:47:01.335] (socket: Operation not permitted)
```
and then the CI passes because the return code is ignored. I think better not fail the CI when `tcpdump` does not work in that environment. It is ok as long as `tcpdump` works on at least one VM to catch problems.
(https://github.com/bitcoin/bitcoin/pull/31349#discussion_r1858069999)
On some of the VMs this produces:
```
[09:47:01.270] + tcpdump -n -i eth0 -w /tmp/tcpdump_eth0
[09:47:01.334] tcpdump: eth0: You don't have permission to perform this capture on that device
[09:47:01.335] (socket: Operation not permitted)
```
and then the CI passes because the return code is ignored. I think better not fail the CI when `tcpdump` does not work in that environment. It is ok as long as `tcpdump` works on at least one VM to catch problems.
💬 maflcko commented on issue "Avoid internet traffic from tests":
(https://github.com/bitcoin/bitcoin/issues/31339#issuecomment-2500040855)
> Edit 2: `--internal` works
Good point, but I don't think this works conceptually to turn any and all network access in the tests into a failure, because a failure to access the network in the tests may not always lead to a test failure.
(https://github.com/bitcoin/bitcoin/issues/31339#issuecomment-2500040855)
> Edit 2: `--internal` works
Good point, but I don't think this works conceptually to turn any and all network access in the tests into a failure, because a failure to access the network in the tests may not always lead to a test failure.
💬 vasild commented on issue "Avoid internet traffic from tests":
(https://github.com/bitcoin/bitcoin/issues/31339#issuecomment-2500045928)
@0xB10C my wish is to catch and report these, not just block them silently (only) from the CI environments.
(https://github.com/bitcoin/bitcoin/issues/31339#issuecomment-2500045928)
@0xB10C my wish is to catch and report these, not just block them silently (only) from the CI environments.
💬 maflcko commented on pull request "ci: detect outbound internet traffic generated while running tests":
(https://github.com/bitcoin/bitcoin/pull/31349#discussion_r1858085005)
The problem is that no one will notice if this isn't run on any machine, because it will silently pass even if there is an error.
(https://github.com/bitcoin/bitcoin/pull/31349#discussion_r1858085005)
The problem is that no one will notice if this isn't run on any machine, because it will silently pass even if there is an error.
💬 vasild commented on pull request "ci: detect outbound internet traffic generated while running tests":
(https://github.com/bitcoin/bitcoin/pull/31349#discussion_r1858094964)
True, if it stops working on all VMs, then nobody will notice. Any ideas how to approach this?
(https://github.com/bitcoin/bitcoin/pull/31349#discussion_r1858094964)
True, if it stops working on all VMs, then nobody will notice. Any ideas how to approach this?
💬 maflcko commented on pull request "ci: Skip broken Wine64 tests by default":
(https://github.com/bitcoin/bitcoin/pull/31284#issuecomment-2500071417)
... https://cirrus-ci.com/task/5957633356595200
(https://github.com/bitcoin/bitcoin/pull/31284#issuecomment-2500071417)
... https://cirrus-ci.com/task/5957633356595200
💬 maflcko commented on pull request "ci: detect outbound internet traffic generated while running tests":
(https://github.com/bitcoin/bitcoin/pull/31349#discussion_r1858114741)
I'd say it is fine to ignore it by default (if you want). However, there should be one machine in the CI matrix to run the check (and fail on any error).
The cirrus workers are running in a user account, so they may not have the permissions (unless they are switched to @0xB10C's workers, which are running as root?). Alternatively, you could try with `--cap-add=...`/`--privileged`, but I haven't tried this. I guess the only task that has the required permissions right now is the ASan GHA task?
...
(https://github.com/bitcoin/bitcoin/pull/31349#discussion_r1858114741)
I'd say it is fine to ignore it by default (if you want). However, there should be one machine in the CI matrix to run the check (and fail on any error).
The cirrus workers are running in a user account, so they may not have the permissions (unless they are switched to @0xB10C's workers, which are running as root?). Alternatively, you could try with `--cap-add=...`/`--privileged`, but I haven't tried this. I guess the only task that has the required permissions right now is the ASan GHA task?
...
💬 dergoegge commented on pull request "ci: Split out native fuzz jobs for macOS and windows (take 2)":
(https://github.com/bitcoin/bitcoin/pull/31221#issuecomment-2500094356)
rfm?
(https://github.com/bitcoin/bitcoin/pull/31221#issuecomment-2500094356)
rfm?
💬 Sjors commented on issue "Stratum v2 via IPC Mining Interface tracking issue":
(https://github.com/bitcoin/bitcoin/issues/31098#issuecomment-2500137804)
In both versions `-sv2interval` specifies the _minimum_ time before sending a fee update, and it currently can't set lower than 1 second. This minimum is not related to polling between two processes.
It's there because determining the new fees requires the node to construct a whole new block template under the hood. This is currently inefficient so the node waits one second between each template generation. But once it finds a better template the node _pushses_ it to the `bitcoin-mine` proces
...
(https://github.com/bitcoin/bitcoin/issues/31098#issuecomment-2500137804)
In both versions `-sv2interval` specifies the _minimum_ time before sending a fee update, and it currently can't set lower than 1 second. This minimum is not related to polling between two processes.
It's there because determining the new fees requires the node to construct a whole new block template under the hood. This is currently inefficient so the node waits one second between each template generation. But once it finds a better template the node _pushses_ it to the `bitcoin-mine` proces
...
💬 TheCharlatan commented on pull request "kernel: Introduce initial C header API":
(https://github.com/bitcoin/bitcoin/pull/30595#discussion_r1858149291)
What do you think of doing something like this instead: https://github.com/TheCharlatan/bitcoin/commit/6323d7b072de5b13ab25aaa29e02332c44808b62
(https://github.com/bitcoin/bitcoin/pull/30595#discussion_r1858149291)
What do you think of doing something like this instead: https://github.com/TheCharlatan/bitcoin/commit/6323d7b072de5b13ab25aaa29e02332c44808b62
💬 maflcko commented on pull request "refactor: Clamp worker threads in ChainstateManager constructor":
(https://github.com/bitcoin/bitcoin/pull/31313#issuecomment-2500141836)
ACK 8f85d36d68ab33ba237407a2ed16667eb149d61f 🛳
<details><summary>Show signature</summary>
Signature:
```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: ACK 8f85d36d68ab33ba237407a2ed
...
(https://github.com/bitcoin/bitcoin/pull/31313#issuecomment-2500141836)
ACK 8f85d36d68ab33ba237407a2ed16667eb149d61f 🛳
<details><summary>Show signature</summary>
Signature:
```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: ACK 8f85d36d68ab33ba237407a2ed
...
💬 maflcko commented on pull request "interpreter: Use the same type for SignatureHash in the definition":
(https://github.com/bitcoin/bitcoin/pull/31365#issuecomment-2500148749)
review ACK c288c790cd9abe91e53164aba5d975ef1e26ee3f 🐺
<details><summary>Show signature</summary>
Signature:
```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: review ACK c288c790cd9a
...
(https://github.com/bitcoin/bitcoin/pull/31365#issuecomment-2500148749)
review ACK c288c790cd9abe91e53164aba5d975ef1e26ee3f 🐺
<details><summary>Show signature</summary>
Signature:
```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: review ACK c288c790cd9a
...
👍 TheCharlatan approved a pull request: "cmake: Check `-Wno-*` compiler options for `leveldb` target"
(https://github.com/bitcoin/bitcoin/pull/31366#pullrequestreview-2460955639)
ACK 9e4a4b4832219d9d11da441779ab8a3b1304bd8b
(https://github.com/bitcoin/bitcoin/pull/31366#pullrequestreview-2460955639)
ACK 9e4a4b4832219d9d11da441779ab8a3b1304bd8b
💬 maflcko commented on pull request "refactor: Fix remaining clang-tidy performance-unnecessary-copy-initialization errors":
(https://github.com/bitcoin/bitcoin/pull/31364#issuecomment-2500166446)
review ACK 3305972f7bfd78181566e4297891c2dd7cae0f2 🏀
<details><summary>Show signature</summary>
Signature:
```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: review ACK 3305972f7bfd7
...
(https://github.com/bitcoin/bitcoin/pull/31364#issuecomment-2500166446)
review ACK 3305972f7bfd78181566e4297891c2dd7cae0f2 🏀
<details><summary>Show signature</summary>
Signature:
```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: review ACK 3305972f7bfd7
...
💬 dergoegge commented on pull request "ci: limit max stack size to 512 KiB":
(https://github.com/bitcoin/bitcoin/pull/31367#issuecomment-2500175006)
Looks like there are some things to fix if we want to do this:
```
[11:46:11.067] Run str_printf with args ['/ci_container_base/ci/scratch/build-x86_64-pc-linux-gnu/src/test/fuzz/fuzz', '-runs=1', PosixPath('/ci_container_base/ci/scratch/qa-assets/fuzz_corpora/str_printf')]INFO: Running with entropic power schedule (0xFF, 100).
[11:46:11.067] INFO: Seed: 2972386372
[11:46:11.067] INFO: Loaded 1 modules (627947 inline 8-bit counters): 627947 [0x55cf2473c058, 0x55cf247d5543),
[11:46:11.0
...
(https://github.com/bitcoin/bitcoin/pull/31367#issuecomment-2500175006)
Looks like there are some things to fix if we want to do this:
```
[11:46:11.067] Run str_printf with args ['/ci_container_base/ci/scratch/build-x86_64-pc-linux-gnu/src/test/fuzz/fuzz', '-runs=1', PosixPath('/ci_container_base/ci/scratch/qa-assets/fuzz_corpora/str_printf')]INFO: Running with entropic power schedule (0xFF, 100).
[11:46:11.067] INFO: Seed: 2972386372
[11:46:11.067] INFO: Loaded 1 modules (627947 inline 8-bit counters): 627947 [0x55cf2473c058, 0x55cf247d5543),
[11:46:11.0
...
💬 maflcko commented on pull request "refactor: Fix remaining clang-tidy performance-inefficient-vector errors":
(https://github.com/bitcoin/bitcoin/pull/31305#issuecomment-2500182183)
review ACK 11f3bc229ccd4b20191855fb1df882cfa6145264 🎦
<details><summary>Show signature</summary>
Signature:
```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: review ACK 11f3bc229ccd
...
(https://github.com/bitcoin/bitcoin/pull/31305#issuecomment-2500182183)
review ACK 11f3bc229ccd4b20191855fb1df882cfa6145264 🎦
<details><summary>Show signature</summary>
Signature:
```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: review ACK 11f3bc229ccd
...
💬 i-am-yuvi commented on issue "Prioritize processing of peers based on their CPU usage":
(https://github.com/bitcoin/bitcoin/issues/31033#issuecomment-2500190904)
> Good questions that I do not have an answer to.
>
> I guess this should start with planting some metrics - CPU time used by each peer in the last 1, 5 and 15 minutes and assessing what a "usual" situation looks like.
>
> Specific to CPU DoS via invalid transactions: for peers that send us such transactions, maybe multiply the CPU time by a factor e.g. 10x or 100x. Or the other way around - nullify CPU time spend on definitely-good-and-positive things like new blocks or new transactions t
...
(https://github.com/bitcoin/bitcoin/issues/31033#issuecomment-2500190904)
> Good questions that I do not have an answer to.
>
> I guess this should start with planting some metrics - CPU time used by each peer in the last 1, 5 and 15 minutes and assessing what a "usual" situation looks like.
>
> Specific to CPU DoS via invalid transactions: for peers that send us such transactions, maybe multiply the CPU time by a factor e.g. 10x or 100x. Or the other way around - nullify CPU time spend on definitely-good-and-positive things like new blocks or new transactions t
...
💬 maflcko commented on pull request "ci: limit max stack size to 512 KiB":
(https://github.com/bitcoin/bitcoin/pull/31367#issuecomment-2500191918)
It looks like `DEBUG=1` has an effect on this?
(https://github.com/bitcoin/bitcoin/pull/31367#issuecomment-2500191918)
It looks like `DEBUG=1` has an effect on this?