💬 rkrux commented on pull request "test: write functional test results to csv":
(https://github.com/bitcoin/bitcoin/pull/30291#discussion_r1642326303)
As soon as the `functional_test_results.csv` file was generated in my system, I thought of adding it in `gitignore`. Since this feature is conditional based on the param, we can't add this hardcoded name in gitgnore but how about adding `*.csv` in gitgnore?
(https://github.com/bitcoin/bitcoin/pull/30291#discussion_r1642326303)
As soon as the `functional_test_results.csv` file was generated in my system, I thought of adding it in `gitignore`. Since this feature is conditional based on the param, we can't add this hardcoded name in gitgnore but how about adding `*.csv` in gitgnore?
💬 rkrux commented on pull request "test: write functional test results to csv":
(https://github.com/bitcoin/bitcoin/pull/30291#discussion_r1642313591)
Nit: Having had only few tests failed also display `ALL,Failed`, which in the first glance gives the impression that all of them failed. In cases like this, displaying `ALL, Few failed` would be more explicit.
(https://github.com/bitcoin/bitcoin/pull/30291#discussion_r1642313591)
Nit: Having had only few tests failed also display `ALL,Failed`, which in the first glance gives the impression that all of them failed. In cases like this, displaying `ALL, Few failed` would be more explicit.
💬 S3RK commented on pull request "wallet: BIP 326 sequence based anti-fee-snipe for taproot inputs":
(https://github.com/bitcoin/bitcoin/pull/24128#issuecomment-2172540718)
I think there is a silent merge conflict with #29325
Otherwise, to the best of my understanding, the code is implemented according to [BIP-326](https://github.com/bitcoin/bips/blob/master/bip-0326.mediawiki) and LGTM
(https://github.com/bitcoin/bitcoin/pull/24128#issuecomment-2172540718)
I think there is a silent merge conflict with #29325
Otherwise, to the best of my understanding, the code is implemented according to [BIP-326](https://github.com/bitcoin/bips/blob/master/bip-0326.mediawiki) and LGTM
💬 Sjors commented on pull request "Introduce Mining interface":
(https://github.com/bitcoin/bitcoin/pull/30200#issuecomment-2172702822)
> any other good ways you'd like to see these changes exercised `getblocktemplate()` is a pretty crucial RPC
You could test #27433 on top of the changes here. Or try solo CPU mining on a custom signet, e.g. using [pooler/cpuminer](https://github.com/pooler/cpuminer) and then:
```sh
./minerd -u bitcoin -p bitcoin -o http://127.0.0.1:38332 --coinbase-addr $ADDRESS --no-stratum --algo=sha256d
```
The latter requires `signetchallenge=51` and a patch setting `#define GBT_RULES "[\"segwit\"
...
(https://github.com/bitcoin/bitcoin/pull/30200#issuecomment-2172702822)
> any other good ways you'd like to see these changes exercised `getblocktemplate()` is a pretty crucial RPC
You could test #27433 on top of the changes here. Or try solo CPU mining on a custom signet, e.g. using [pooler/cpuminer](https://github.com/pooler/cpuminer) and then:
```sh
./minerd -u bitcoin -p bitcoin -o http://127.0.0.1:38332 --coinbase-addr $ADDRESS --no-stratum --algo=sha256d
```
The latter requires `signetchallenge=51` and a patch setting `#define GBT_RULES "[\"segwit\"
...
💬 Sjors commented on pull request "Introduce Mining interface":
(https://github.com/bitcoin/bitcoin/pull/30200#discussion_r1642458226)
`GetBlockHash()`, which was called directly before this commit, has an `assert` that `tip` must exist. So `return uint256{0};` should never happen. An optional does seem more robust though, will look into it.
(https://github.com/bitcoin/bitcoin/pull/30200#discussion_r1642458226)
`GetBlockHash()`, which was called directly before this commit, has an `assert` that `tip` must exist. So `return uint256{0};` should never happen. An optional does seem more robust though, will look into it.
💬 Sjors commented on pull request "Introduce Mining interface":
(https://github.com/bitcoin/bitcoin/pull/30200#discussion_r1642459287)
I added a default `true` to mimic `TestBlockValidity` in `validation.h`.
(https://github.com/bitcoin/bitcoin/pull/30200#discussion_r1642459287)
I added a default `true` to mimic `TestBlockValidity` in `validation.h`.
👍 rkrux approved a pull request: "test: Validate oversized transactions or without inputs"
(https://github.com/bitcoin/bitcoin/pull/29862#pullrequestreview-2122365305)
tACK [0aa7db4](https://github.com/bitcoin/bitcoin/pull/29862/commits/0aa7db42564408edb41b0d42103d39ba4c2787dc)
`make` and `make check` successful, so are all the functional tests.
Thanks for adding these unit tests and using `SCRIPT_VERIFY_NONE` instead of hardcoded 0.
(https://github.com/bitcoin/bitcoin/pull/29862#pullrequestreview-2122365305)
tACK [0aa7db4](https://github.com/bitcoin/bitcoin/pull/29862/commits/0aa7db42564408edb41b0d42103d39ba4c2787dc)
`make` and `make check` successful, so are all the functional tests.
Thanks for adding these unit tests and using `SCRIPT_VERIFY_NONE` instead of hardcoded 0.
💬 cdecker commented on issue "DNS seed "seed.bitcoinstats.com" doesn't support filtering while the comments says it does":
(https://github.com/bitcoin/bitcoin/issues/29911#issuecomment-2172871011)
I spoke with @emzy and I decided to revive this seed, and migrate to a more standard deployment as well. The overhead of the custom solution did not add enough quality, and caused the seeder to rot and break. Using sipa's seeder will solve that, and reduce the burden of maintenance.
No timeline yet, but I'll dedicate a couple of weekends
(https://github.com/bitcoin/bitcoin/issues/29911#issuecomment-2172871011)
I spoke with @emzy and I decided to revive this seed, and migrate to a more standard deployment as well. The overhead of the custom solution did not add enough quality, and caused the seeder to rot and break. Using sipa's seeder will solve that, and reduce the burden of maintenance.
No timeline yet, but I'll dedicate a couple of weekends
👍 hebasto approved a pull request: "ci: parse TEST_RUNNER_EXTRA into an array"
(https://github.com/bitcoin/bitcoin/pull/30244#pullrequestreview-2122406132)
ACK 8131bf7483c0ea10d3573c9f2e977d19d8569b7f, tested on Ubuntu 23.10 and Windows 11.
In the command prompt on Windows, the following commands work as expected:
```
>set EXTRA=--exclude "rpc_bind.py --ipv6, feature_proxy.py"
>py -3 test\functional\test_runner.py %EXTRA%
```
which is sufficient for our CI if needed.
(https://github.com/bitcoin/bitcoin/pull/30244#pullrequestreview-2122406132)
ACK 8131bf7483c0ea10d3573c9f2e977d19d8569b7f, tested on Ubuntu 23.10 and Windows 11.
In the command prompt on Windows, the following commands work as expected:
```
>set EXTRA=--exclude "rpc_bind.py --ipv6, feature_proxy.py"
>py -3 test\functional\test_runner.py %EXTRA%
```
which is sufficient for our CI if needed.
⚠️ Fonta1n3 opened an issue: "Setting `bip32derivs` to `false` with `walletprocesspsbt` includes `bip32_derivs` for outputs."
(https://github.com/bitcoin/bitcoin/issues/30294)
### Please describe the feature you'd like to see added.
I'd like an option to remove the `bip32derivs` from outputs as well as inputs when calling `walletprocesspsbt`.
### Is your feature related to a problem, if so please describe it.
I am using Bitcoin Core to create psbt's which are meant to be passed around to multiple users for collaborative transactions. I want to leak as little data as possible. When I set `bip32derivs` to `false` with `walletprocesspsbt` it does not remove the `bip32
...
(https://github.com/bitcoin/bitcoin/issues/30294)
### Please describe the feature you'd like to see added.
I'd like an option to remove the `bip32derivs` from outputs as well as inputs when calling `walletprocesspsbt`.
### Is your feature related to a problem, if so please describe it.
I am using Bitcoin Core to create psbt's which are meant to be passed around to multiple users for collaborative transactions. I want to leak as little data as possible. When I set `bip32derivs` to `false` with `walletprocesspsbt` it does not remove the `bip32
...
💬 marcofleon commented on pull request "fuzz: FuzzedSock::Recv() don't lose bytes from MSG_PEEK read":
(https://github.com/bitcoin/bitcoin/pull/30273#discussion_r1642560055)
You can add it to the end of the command. So `FUZZ=i2p ./src/test/fuzz/fuzz -dict=DICTFILE`. The dictionary (`i2p.dict`) is in the qa-assets repo: https://github.com/bitcoin-core/qa-assets/tree/main/fuzz_dicts. I'm running it now on the most recent commit.
(https://github.com/bitcoin/bitcoin/pull/30273#discussion_r1642560055)
You can add it to the end of the command. So `FUZZ=i2p ./src/test/fuzz/fuzz -dict=DICTFILE`. The dictionary (`i2p.dict`) is in the qa-assets repo: https://github.com/bitcoin-core/qa-assets/tree/main/fuzz_dicts. I'm running it now on the most recent commit.
👍 dergoegge approved a pull request: "test: Add Compact Block Encoding test `ReceiveWithExtraTransactions` covering non-empty `extra_txn`"
(https://github.com/bitcoin/bitcoin/pull/30237#pullrequestreview-2122540242)
tACK 09b90c69bc17ce43dce3881a208d9066a729c67d
(https://github.com/bitcoin/bitcoin/pull/30237#pullrequestreview-2122540242)
tACK 09b90c69bc17ce43dce3881a208d9066a729c67d
💬 maflcko commented on pull request "test: write functional test results to csv":
(https://github.com/bitcoin/bitcoin/pull/30291#issuecomment-2173079380)
re-ACK ad06e68399da71c615db0dbf5304d0cd46bc1f40
(https://github.com/bitcoin/bitcoin/pull/30291#issuecomment-2173079380)
re-ACK ad06e68399da71c615db0dbf5304d0cd46bc1f40
👍 hebasto approved a pull request: "ci: move ASan job to GitHub Actions from Cirrus CI"
(https://github.com/bitcoin/bitcoin/pull/30193#pullrequestreview-2122625080)
ACK 9eea51d9058ad638861aa4b94c1c6e71caeb8765.
(https://github.com/bitcoin/bitcoin/pull/30193#pullrequestreview-2122625080)
ACK 9eea51d9058ad638861aa4b94c1c6e71caeb8765.
💬 Sjors commented on pull request "Introduce Mining interface":
(https://github.com/bitcoin/bitcoin/pull/30200#issuecomment-2173170961)
Oops, `'TestBlockValidity failed: bad-txns-inputs-missingorspent'`...
(https://github.com/bitcoin/bitcoin/pull/30200#issuecomment-2173170961)
Oops, `'TestBlockValidity failed: bad-txns-inputs-missingorspent'`...
💬 glozow commented on pull request "test: Add Compact Block Encoding test `ReceiveWithExtraTransactions` covering non-empty `extra_txn`":
(https://github.com/bitcoin/bitcoin/pull/30237#discussion_r1642697581)
really not a fan of these magic numbers, would prefer `rand_ctx.rand64()`
(https://github.com/bitcoin/bitcoin/pull/30237#discussion_r1642697581)
really not a fan of these magic numbers, would prefer `rand_ctx.rand64()`
💬 glozow commented on pull request "test: Add Compact Block Encoding test `ReceiveWithExtraTransactions` covering non-empty `extra_txn`":
(https://github.com/bitcoin/bitcoin/pull/30237#discussion_r1642694693)
What about always requiring a `FastRandomContext` and getting a `rand64()` for the nonce that way? peerman would pass in its own `m_rng. Making the rng a param feels preferable to adding a test-only version of the ctor.
(https://github.com/bitcoin/bitcoin/pull/30237#discussion_r1642694693)
What about always requiring a `FastRandomContext` and getting a `rand64()` for the nonce that way? peerman would pass in its own `m_rng. Making the rng a param feels preferable to adding a test-only version of the ctor.
💬 rkrux commented on pull request "test: expand LimitOrphan and EraseForPeer coverage":
(https://github.com/bitcoin/bitcoin/pull/30082#discussion_r1642703544)
Can you please share how exactly is this being done `check timeout logic` here?
I see from the `AddTx` code that if the tx size is more than the standard weight, then it will not be added in the orphanage. Is the timeout logic here that the size of this tx is less than the standard weight and therefore it's inserted?
(https://github.com/bitcoin/bitcoin/pull/30082#discussion_r1642703544)
Can you please share how exactly is this being done `check timeout logic` here?
I see from the `AddTx` code that if the tx size is more than the standard weight, then it will not be added in the orphanage. Is the timeout logic here that the size of this tx is less than the standard weight and therefore it's inserted?
👍 rkrux approved a pull request: "test: expand LimitOrphan and EraseForPeer coverage"
(https://github.com/bitcoin/bitcoin/pull/30082#pullrequestreview-2122597073)
tACK [eaf4de0](https://github.com/bitcoin/bitcoin/pull/30082/commits/eaf4de028de8fa13227b6089785889f1c6c15b4d)
Make successful, so are all the unit tests and functional test. Asked couple questions for my understanding.
(https://github.com/bitcoin/bitcoin/pull/30082#pullrequestreview-2122597073)
tACK [eaf4de0](https://github.com/bitcoin/bitcoin/pull/30082/commits/eaf4de028de8fa13227b6089785889f1c6c15b4d)
Make successful, so are all the unit tests and functional test. Asked couple questions for my understanding.
💬 rkrux commented on pull request "test: expand LimitOrphan and EraseForPeer coverage":
(https://github.com/bitcoin/bitcoin/pull/30082#discussion_r1642629997)
Nit: Tying it to `expected_num_orphans` like `expected_num_orphans -3` in the `LimitOrphans` call would make it more explicit (but not necessarily in the `BOOST_CHECK`), otherwise it made me wonder whether the current count is more than 40 or not.
(https://github.com/bitcoin/bitcoin/pull/30082#discussion_r1642629997)
Nit: Tying it to `expected_num_orphans` like `expected_num_orphans -3` in the `LimitOrphans` call would make it more explicit (but not necessarily in the `BOOST_CHECK`), otherwise it made me wonder whether the current count is more than 40 or not.