👍 kristapsk approved a pull request: "test: dedup file hashing using `sha256sum_file` helper"
(https://github.com/bitcoin/bitcoin/pull/27572#pullrequestreview-1558692172)
ACK 2c0c6f44770403899bd8514ad7343356853bf38c
(https://github.com/bitcoin/bitcoin/pull/27572#pullrequestreview-1558692172)
ACK 2c0c6f44770403899bd8514ad7343356853bf38c
💬 Daniel600 commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1661960440)
A clear and open method to research the adoption of full RBF would look something like this and could easily be done -
Create 20 trxs (larger numbers better) every block and after 30 seconds try replace them.
Run this test for at least a few hours preferably more than 24 hours or even a few days.
See results of how many were replaced.
Ignore trx results if trx are included in blocks before replace trxs are published.
Based on a test like this or something similar it would be reliable t
...
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1661960440)
A clear and open method to research the adoption of full RBF would look something like this and could easily be done -
Create 20 trxs (larger numbers better) every block and after 30 seconds try replace them.
Run this test for at least a few hours preferably more than 24 hours or even a few days.
See results of how many were replaced.
Ignore trx results if trx are included in blocks before replace trxs are published.
Based on a test like this or something similar it would be reliable t
...
💬 MarcoFalke commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#issuecomment-1661971280)
> I'd prefer a separate tool as we otherwise turn fingerprinting into a big maintenance issue. A separate tool guarantees that there is no internal state overlap which makes fingerprinting very hard (if not impossible).
Not sure why this requires a separate tool? I think a separate internal module (or internal library that is linked, or whatever) should be able to achieve the same, with the added benefit that users can use it in Bitcoin Core without having to fiddle with another binary.
(https://github.com/bitcoin/bitcoin/pull/27509#issuecomment-1661971280)
> I'd prefer a separate tool as we otherwise turn fingerprinting into a big maintenance issue. A separate tool guarantees that there is no internal state overlap which makes fingerprinting very hard (if not impossible).
Not sure why this requires a separate tool? I think a separate internal module (or internal library that is linked, or whatever) should be able to achieve the same, with the added benefit that users can use it in Bitcoin Core without having to fiddle with another binary.
💬 hebasto commented on pull request "ci: Move ASan USDT to persistent_worker":
(https://github.com/bitcoin/bitcoin/pull/28161#issuecomment-1661972486)
Concept ACK on moving CI tasks outside from Cirrus CI as a response to their new [limits](https://cirrus-ci.org/blog/2023/07/17/limiting-free-usage-of-cirrus-ci/).
Historically, the Bitcoin Core project started to use self-hosted CI in [April 2021](https://github.com/bitcoin/bitcoin/pull/21619):
> For testing purposes, a single task will be transformed to run on the DrahtBot infrastructure. If all goes well, the other tasks can be moved, too.
At the same time, there were some usage of the
...
(https://github.com/bitcoin/bitcoin/pull/28161#issuecomment-1661972486)
Concept ACK on moving CI tasks outside from Cirrus CI as a response to their new [limits](https://cirrus-ci.org/blog/2023/07/17/limiting-free-usage-of-cirrus-ci/).
Historically, the Bitcoin Core project started to use self-hosted CI in [April 2021](https://github.com/bitcoin/bitcoin/pull/21619):
> For testing purposes, a single task will be transformed to run on the DrahtBot infrastructure. If all goes well, the other tasks can be moved, too.
At the same time, there were some usage of the
...
💬 vasild commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1281726530)
_moving discussion from https://github.com/bitcoin/bitcoin/pull/27509#issuecomment-1659008138_
> 1. `-sensitiverelay=1` and `-onlynet=ipv4` should probably throw an init error. In this configuration, sensitive stuff seems to be ignored and new wallet TXs are relayed via ipv4 peers like normal.
This check was supposed to prevent that but it was too strict. Apparently you have `listenonion=1` which means that later, after startup, we will connect to the Tor control and may set the Tor proxy
...
(https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1281726530)
_moving discussion from https://github.com/bitcoin/bitcoin/pull/27509#issuecomment-1659008138_
> 1. `-sensitiverelay=1` and `-onlynet=ipv4` should probably throw an init error. In this configuration, sensitive stuff seems to be ignored and new wallet TXs are relayed via ipv4 peers like normal.
This check was supposed to prevent that but it was too strict. Apparently you have `listenonion=1` which means that later, after startup, we will connect to the Tor control and may set the Tor proxy
...
💬 dergoegge commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#issuecomment-1661976345)
> I think a separate internal module (or internal library that is linked, or whatever) should be able to achieve the same, with the added benefit that users can use it in Bitcoin Core without having to fiddle with another binary.
Sure but that is the "significant effort" i was referring to. You would need to completely decouple this new logic (and its state) from the other full node networking and message processing logic.
(https://github.com/bitcoin/bitcoin/pull/27509#issuecomment-1661976345)
> I think a separate internal module (or internal library that is linked, or whatever) should be able to achieve the same, with the added benefit that users can use it in Bitcoin Core without having to fiddle with another binary.
Sure but that is the "significant effort" i was referring to. You would need to completely decouple this new logic (and its state) from the other full node networking and message processing logic.
🚀 fanquake merged a pull request: "test: dedup file hashing using `sha256sum_file` helper"
(https://github.com/bitcoin/bitcoin/pull/27572)
(https://github.com/bitcoin/bitcoin/pull/27572)
📝 glozow opened a pull request: "functional test: tx orphan handling"
(https://github.com/bitcoin/bitcoin/pull/28199)
I was doing some mutation testing (through reckless refactoring) locally and found some specific behaviors in orphan handling that weren't picked up by tests. Adding some of these test cases now can maybe help with reviewing refactors like #28031.
- Parent requests aren't sent immediately. A delay is added and the requests are filtered by AlreadyHaveTx before they are sent, which means you can't use fake orphans to probe precise arrival timing of a tx.
- Parent requests include all that are
...
(https://github.com/bitcoin/bitcoin/pull/28199)
I was doing some mutation testing (through reckless refactoring) locally and found some specific behaviors in orphan handling that weren't picked up by tests. Adding some of these test cases now can maybe help with reviewing refactors like #28031.
- Parent requests aren't sent immediately. A delay is added and the requests are filtered by AlreadyHaveTx before they are sent, which means you can't use fake orphans to probe precise arrival timing of a tx.
- Parent requests include all that are
...
💬 MarcoFalke commented on pull request "ci: Move ASan USDT to persistent_worker":
(https://github.com/bitcoin/bitcoin/pull/28161#issuecomment-1662036818)
> Tbh, I'd feel much more confident and comfortable knowing that some sponsors publicly pledged to cover all related costs.
Ok, I'll try to encourage the sponsor to publicly identify themselves, but I wonder what you worry about? If you are worried about the sponsor walking away, I can assure you that there are currently three (3) willing sponsors in line. Also, while it isn't free, running Linux is extremely cheap compared to Windows/macOS.
If you have any alternative ideas, it would be g
...
(https://github.com/bitcoin/bitcoin/pull/28161#issuecomment-1662036818)
> Tbh, I'd feel much more confident and comfortable knowing that some sponsors publicly pledged to cover all related costs.
Ok, I'll try to encourage the sponsor to publicly identify themselves, but I wonder what you worry about? If you are worried about the sponsor walking away, I can assure you that there are currently three (3) willing sponsors in line. Also, while it isn't free, running Linux is extremely cheap compared to Windows/macOS.
If you have any alternative ideas, it would be g
...
💬 hebasto commented on pull request "ci: Move ASan USDT to persistent_worker":
(https://github.com/bitcoin/bitcoin/pull/28161#issuecomment-1662057512)
> > Tbh, I'd feel much more confident and comfortable knowing that some sponsors publicly pledged to cover all related costs.
>
> Ok, I'll try to encourage the sponsor to publicly identify themselves
Sorry for being misunderstood. I don't want to force current sponsors to any additional actions.
> ... but I wonder what you worry about?
Sustainability.
> Also, while it isn't free, running Linux is extremely cheap compared to Windows/macOS.
I don't think so. In June, total Linux
...
(https://github.com/bitcoin/bitcoin/pull/28161#issuecomment-1662057512)
> > Tbh, I'd feel much more confident and comfortable knowing that some sponsors publicly pledged to cover all related costs.
>
> Ok, I'll try to encourage the sponsor to publicly identify themselves
Sorry for being misunderstood. I don't want to force current sponsors to any additional actions.
> ... but I wonder what you worry about?
Sustainability.
> Also, while it isn't free, running Linux is extremely cheap compared to Windows/macOS.
I don't think so. In June, total Linux
...
👍 hebasto approved a pull request: "ci: Move ASan USDT to persistent_worker"
(https://github.com/bitcoin/bitcoin/pull/28161#pullrequestreview-1558764134)
ACK fa474397b5d4235efdfc5a5ddce2d637234548a7, I have reviewed the code and it looks OK.
(https://github.com/bitcoin/bitcoin/pull/28161#pullrequestreview-1558764134)
ACK fa474397b5d4235efdfc5a5ddce2d637234548a7, I have reviewed the code and it looks OK.
💬 hebasto commented on pull request "ci: Move ASan USDT to persistent_worker":
(https://github.com/bitcoin/bitcoin/pull/28161#discussion_r1281752846)
Might it be more straightforward to define `BPFCC_PACKAGE` in `ci\test_imagefile`?
Running `FILE_ENV="./ci/test/00_setup_env_native_asan.sh" ./ci/test_run_all.sh` locally skips `interface_usdt_*.py` tests.
(https://github.com/bitcoin/bitcoin/pull/28161#discussion_r1281752846)
Might it be more straightforward to define `BPFCC_PACKAGE` in `ci\test_imagefile`?
Running `FILE_ENV="./ci/test/00_setup_env_native_asan.sh" ./ci/test_run_all.sh` locally skips `interface_usdt_*.py` tests.
💬 MarcoFalke commented on pull request "ci: Move ASan USDT to persistent_worker":
(https://github.com/bitcoin/bitcoin/pull/28161#issuecomment-1662066525)
> > Also, while it isn't free, running Linux is extremely cheap compared to Windows/macOS.
>
> I don't think so. In June, total Linux tasks cost was the biggest one followed by Windows.
You are quoting Linux costs that Cirrus CI "sells". The goal of this pull request is to use Linux "sold" by someone else. (There are many professional companies that offer Linux boxes. If you are unsure, you can use your favourite search engine to get typical competitive pricing on Linux boxes.)
(https://github.com/bitcoin/bitcoin/pull/28161#issuecomment-1662066525)
> > Also, while it isn't free, running Linux is extremely cheap compared to Windows/macOS.
>
> I don't think so. In June, total Linux tasks cost was the biggest one followed by Windows.
You are quoting Linux costs that Cirrus CI "sells". The goal of this pull request is to use Linux "sold" by someone else. (There are many professional companies that offer Linux boxes. If you are unsure, you can use your favourite search engine to get typical competitive pricing on Linux boxes.)
💬 MarcoFalke commented on pull request "ci: Move ASan USDT to persistent_worker":
(https://github.com/bitcoin/bitcoin/pull/28161#discussion_r1281795401)
> Running `FILE_ENV="./ci/test/00_setup_env_native_asan.sh" ./ci/test_run_all.sh` locally skips `interface_usdt_*.py` tests.
The goal of this pull request is not to change any behavior locally. If you are interested in changing the behavior, a separate issue or pull request would be good.
(https://github.com/bitcoin/bitcoin/pull/28161#discussion_r1281795401)
> Running `FILE_ENV="./ci/test/00_setup_env_native_asan.sh" ./ci/test_run_all.sh` locally skips `interface_usdt_*.py` tests.
The goal of this pull request is not to change any behavior locally. If you are interested in changing the behavior, a separate issue or pull request would be good.
💬 dergoegge commented on pull request "test: tx orphan handling":
(https://github.com/bitcoin/bitcoin/pull/28199#issuecomment-1662073675)
Concept ACK
Good to have these tests prior to refactoring
(https://github.com/bitcoin/bitcoin/pull/28199#issuecomment-1662073675)
Concept ACK
Good to have these tests prior to refactoring
💬 hebasto commented on pull request "ci: Move ASan USDT to persistent_worker":
(https://github.com/bitcoin/bitcoin/pull/28161#issuecomment-1662076765)
> > > Also, while it isn't free, running Linux is extremely cheap compared to Windows/macOS.
> >
> >
> > I don't think so. In June, total Linux tasks cost was the biggest one followed by Windows.
>
> You are quoting Linux costs that Cirrus CI "sells".
Yes. We have to cope with new Cirrus's offers.
> The goal of this pull request is to use Linux "sold" by someone else.
Using someone's else resource equals to not using Cirrus provided resources.
> (There are many professional c
...
(https://github.com/bitcoin/bitcoin/pull/28161#issuecomment-1662076765)
> > > Also, while it isn't free, running Linux is extremely cheap compared to Windows/macOS.
> >
> >
> > I don't think so. In June, total Linux tasks cost was the biggest one followed by Windows.
>
> You are quoting Linux costs that Cirrus CI "sells".
Yes. We have to cope with new Cirrus's offers.
> The goal of this pull request is to use Linux "sold" by someone else.
Using someone's else resource equals to not using Cirrus provided resources.
> (There are many professional c
...
✅ fanquake closed an issue: "Add support for all networks in `deserialize_v2` in test_framework"
(https://github.com/bitcoin/bitcoin/issues/27140)
(https://github.com/bitcoin/bitcoin/issues/27140)
🚀 fanquake merged a pull request: "test: cover addrv2 anchors by adding TorV3 to CAddress in messages.py"
(https://github.com/bitcoin/bitcoin/pull/27452)
(https://github.com/bitcoin/bitcoin/pull/27452)
💬 dergoegge commented on pull request "fuzz: Generate with random libFuzzer settings":
(https://github.com/bitcoin/bitcoin/pull/28178#issuecomment-1662089886)
> I'd say the main goal here is to prevent a case where a bug isn't found at all (or only after a "outlier" long time) due to the default settings.
This sounds reasonable but also quite rare. Could you give me an example of a theoretical target where this could happen?
Are there any other projects that do this (e.g. oss-fuzz)?
> I don't think we've seen such a bug in reality, so I am happy to close this pull.
On a general note, I think it is fine to add to/improve on our fuzzing tool
...
(https://github.com/bitcoin/bitcoin/pull/28178#issuecomment-1662089886)
> I'd say the main goal here is to prevent a case where a bug isn't found at all (or only after a "outlier" long time) due to the default settings.
This sounds reasonable but also quite rare. Could you give me an example of a theoretical target where this could happen?
Are there any other projects that do this (e.g. oss-fuzz)?
> I don't think we've seen such a bug in reality, so I am happy to close this pull.
On a general note, I think it is fine to add to/improve on our fuzzing tool
...
💬 MarcoFalke commented on pull request "fuzz: Generate with random libFuzzer settings":
(https://github.com/bitcoin/bitcoin/pull/28178#issuecomment-1662115396)
> Are there any other projects that do this (e.g. oss-fuzz)?
IIRC oss-fuzz did that with AFL build time settings, but removed it again because it would turn up bugs intermittently/non-deterministically. I don't think they do it for libFuzzer runtime settings, but I found this, which claims that exponential search is turned into linear search.
```
oss-fuzz]$ git grep -W -I use_value_profile
projects/java-example/ExampleValueProfileFuzzer.java=public class ExampleValueProfileFuzzer {
pr
...
(https://github.com/bitcoin/bitcoin/pull/28178#issuecomment-1662115396)
> Are there any other projects that do this (e.g. oss-fuzz)?
IIRC oss-fuzz did that with AFL build time settings, but removed it again because it would turn up bugs intermittently/non-deterministically. I don't think they do it for libFuzzer runtime settings, but I found this, which claims that exponential search is turned into linear search.
```
oss-fuzz]$ git grep -W -I use_value_profile
projects/java-example/ExampleValueProfileFuzzer.java=public class ExampleValueProfileFuzzer {
pr
...
💬 vasild commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1281768350)
_moving discussion from https://github.com/bitcoin/bitcoin/pull/27509#issuecomment-1659008138_
> 2. Rapidly sending multiple transactions "...incremented the number of connections to open from 20 to 25..." this number grows rapidly and decreases slowly (especially on signet) I wonder if it should max out at some point or reduce the tx:relay-peer ratio from 5:1 to just 1:1
`MAX_SENSITIVE_RELAY_CONNECTIONS` (64) is supposed to cap it. Did it exceed 64?
(https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1281768350)
_moving discussion from https://github.com/bitcoin/bitcoin/pull/27509#issuecomment-1659008138_
> 2. Rapidly sending multiple transactions "...incremented the number of connections to open from 20 to 25..." this number grows rapidly and decreases slowly (especially on signet) I wonder if it should max out at some point or reduce the tx:relay-peer ratio from 5:1 to just 1:1
`MAX_SENSITIVE_RELAY_CONNECTIONS` (64) is supposed to cap it. Did it exceed 64?