💬 jo-elimu commented on pull request "test: speedup bip324_cipher.py unit test":
(https://github.com/bitcoin/bitcoin/pull/29390#issuecomment-1928764743)
Is this pull request associated with one of the issues at https://github.com/bitcoin/bitcoin/issues?
(https://github.com/bitcoin/bitcoin/pull/29390#issuecomment-1928764743)
Is this pull request associated with one of the issues at https://github.com/bitcoin/bitcoin/issues?
💬 jo-elimu commented on pull request "test: fix RPC coverage check":
(https://github.com/bitcoin/bitcoin/pull/29387#discussion_r1479210925)
@BrandonOdiwuor What does the `-disablewallet` mean?
(https://github.com/bitcoin/bitcoin/pull/29387#discussion_r1479210925)
@BrandonOdiwuor What does the `-disablewallet` mean?
💬 maflcko commented on pull request "fuzz: remove unused `args` and `context` from `FuzzedWallet`":
(https://github.com/bitcoin/bitcoin/pull/29388#issuecomment-1928938045)
lgtm ACK b14298c5bca395e5ed6a27fe1758c0d1f4b824ac
(https://github.com/bitcoin/bitcoin/pull/29388#issuecomment-1928938045)
lgtm ACK b14298c5bca395e5ed6a27fe1758c0d1f4b824ac
💬 delta1 commented on pull request "test: speedup bip324_cipher.py unit test":
(https://github.com/bitcoin/bitcoin/pull/29390#issuecomment-1928950663)
Concept ACK a8c3454
To run the individual test I had to run it from the `test/functional` directory this way: `python3 -m unittest ./crypto/bip324_cipher.py`
Saves about 10 seconds in test_runner on my machine
Before:
```
Running Unit Tests for Test Framework Modules
.....................
----------------------------------------------------------------------
Ran 21 tests in 15.701s
```
After:
```
Running Unit Tests for Test Framework Modules
.....................
--------
...
(https://github.com/bitcoin/bitcoin/pull/29390#issuecomment-1928950663)
Concept ACK a8c3454
To run the individual test I had to run it from the `test/functional` directory this way: `python3 -m unittest ./crypto/bip324_cipher.py`
Saves about 10 seconds in test_runner on my machine
Before:
```
Running Unit Tests for Test Framework Modules
.....................
----------------------------------------------------------------------
Ran 21 tests in 15.701s
```
After:
```
Running Unit Tests for Test Framework Modules
.....................
--------
...
💬 maflcko commented on pull request "test: fix RPC coverage check":
(https://github.com/bitcoin/bitcoin/pull/29387#discussion_r1479350456)
You can remove this? Also, it would be good to mention the commit that this reverts. (It may be one of mine)
(https://github.com/bitcoin/bitcoin/pull/29387#discussion_r1479350456)
You can remove this? Also, it would be good to mention the commit that this reverts. (It may be one of mine)
💬 maflcko commented on pull request "util: check for errors after close and read in AutoFile":
(https://github.com/bitcoin/bitcoin/pull/29307#issuecomment-1928966222)
> How/when would the file be closed?
An `AutoFile` can be closed by calling the `fclose()` method in the code.
(https://github.com/bitcoin/bitcoin/pull/29307#issuecomment-1928966222)
> How/when would the file be closed?
An `AutoFile` can be closed by calling the `fclose()` method in the code.
💬 maflcko commented on pull request "assumeutxo: Get rid of faked nTx and nChainTx values":
(https://github.com/bitcoin/bitcoin/pull/29370#discussion_r1479427801)
I think the comment was wrong, or do you have a code path where nChainTx is read when it was wrong (previously) or is unset (now)?
Generally, `GuessVerificationProgress` is only called to estimate the IBD progress at the tip, in which case nChainTx is set to the correct value. It is also used to guess rescan progress, which is not possible for blocks outside the active chain or blocks that have data missing, so nChainTx should be correct there as well.
unrelated to this pull: Maybe an `Ass
...
(https://github.com/bitcoin/bitcoin/pull/29370#discussion_r1479427801)
I think the comment was wrong, or do you have a code path where nChainTx is read when it was wrong (previously) or is unset (now)?
Generally, `GuessVerificationProgress` is only called to estimate the IBD progress at the tip, in which case nChainTx is set to the correct value. It is also used to guess rescan progress, which is not possible for blocks outside the active chain or blocks that have data missing, so nChainTx should be correct there as well.
unrelated to this pull: Maybe an `Ass
...
💬 maflcko commented on pull request "assumeutxo: Get rid of faked nTx and nChainTx values":
(https://github.com/bitcoin/bitcoin/pull/29370#discussion_r1479428612)
unrelated to this pull: May be better to throw here, instead of returning wrong data, but this can be done in a follow-up.
(https://github.com/bitcoin/bitcoin/pull/29370#discussion_r1479428612)
unrelated to this pull: May be better to throw here, instead of returning wrong data, but this can be done in a follow-up.
💬 maflcko commented on pull request "assumeutxo: Get rid of faked nTx and nChainTx values":
(https://github.com/bitcoin/bitcoin/pull/29370#issuecomment-1929064411)
Needs rebase
(https://github.com/bitcoin/bitcoin/pull/29370#issuecomment-1929064411)
Needs rebase
💬 maflcko commented on pull request "test: maxuploadtarget: check for mempool msg disconnect if limit is reached, improve existing test coverage":
(https://github.com/bitcoin/bitcoin/pull/28996#issuecomment-1929096646)
lgtm ACK b58f009d9585aab775998644de07e27e2a4a8045
(https://github.com/bitcoin/bitcoin/pull/28996#issuecomment-1929096646)
lgtm ACK b58f009d9585aab775998644de07e27e2a4a8045
💬 Rodert commented on issue "When I make a highly concurrent request to bitcoin core, a new block appears and all my requests get blocked":
(https://github.com/bitcoin/bitcoin/issues/29384#issuecomment-1929097083)
> Is it blocked forever or until the block is finished processing? Can you provide more details about what your highly concurrent request is?
this . I used golang to initiate rpc getblock and so on for the http request node, 30 concurrent continuous calls. As you can see from the load monitoring of the server, every time a new block is synchronized, the program is stuck.
(https://github.com/bitcoin/bitcoin/issues/29384#issuecomment-1929097083)
> Is it blocked forever or until the block is finished processing? Can you provide more details about what your highly concurrent request is?
this . I used golang to initiate rpc getblock and so on for the http request node, 30 concurrent continuous calls. As you can see from the load monitoring of the server, every time a new block is synchronized, the program is stuck.
💬 maflcko commented on pull request "test: fix RPC coverage check":
(https://github.com/bitcoin/bitcoin/pull/29387#issuecomment-1929108842)
Also, it doesn't seem to work, because the CI should fail, because the `abortrescan` rpc is uncovered
(https://github.com/bitcoin/bitcoin/pull/29387#issuecomment-1929108842)
Also, it doesn't seem to work, because the CI should fail, because the `abortrescan` rpc is uncovered
💬 Rodert commented on issue "When I make a highly concurrent request to bitcoin core, a new block appears and all my requests get blocked":
(https://github.com/bitcoin/bitcoin/issues/29384#issuecomment-1929110998)
> > Package manager
>
> Which package manager?
>
> Can you provide any debug.log output?
i use bitcoin version `bitcoin-25.0` by `Linux *.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:30:08 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux` .
Here are some error messages encountered, But I don't know if it matters.
```bash
2024-02-05T06:13:24Z BlockUntilSyncedToCurrentChain: txindex is catching up on block notifications
2024-02-05T06:27:32Z Saw new header hash=0000000000000000000380aa9f106ee
...
(https://github.com/bitcoin/bitcoin/issues/29384#issuecomment-1929110998)
> > Package manager
>
> Which package manager?
>
> Can you provide any debug.log output?
i use bitcoin version `bitcoin-25.0` by `Linux *.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:30:08 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux` .
Here are some error messages encountered, But I don't know if it matters.
```bash
2024-02-05T06:13:24Z BlockUntilSyncedToCurrentChain: txindex is catching up on block notifications
2024-02-05T06:27:32Z Saw new header hash=0000000000000000000380aa9f106ee
...
💬 Rodert commented on issue "When I make a highly concurrent request to bitcoin core, a new block appears and all my requests get blocked":
(https://github.com/bitcoin/bitcoin/issues/29384#issuecomment-1929113601)
I've reduced the concurrency now, the problem is happening less often, but it's not completely solved
(https://github.com/bitcoin/bitcoin/issues/29384#issuecomment-1929113601)
I've reduced the concurrency now, the problem is happening less often, but it's not completely solved
💬 maflcko commented on pull request "validation: improve performance of CheckBlockIndex":
(https://github.com/bitcoin/bitcoin/pull/28339#discussion_r1479473030)
May be better to do this deterministically to avoid non-determinism in tests?
(https://github.com/bitcoin/bitcoin/pull/28339#discussion_r1479473030)
May be better to do this deterministically to avoid non-determinism in tests?
💬 maflcko commented on issue "When I make a highly concurrent request to bitcoin core, a new block appears and all my requests get blocked":
(https://github.com/bitcoin/bitcoin/issues/29384#issuecomment-1929125756)
`-rpcworkqueue=` should be at least as large as the number of concurrent requests you are doing.
(https://github.com/bitcoin/bitcoin/issues/29384#issuecomment-1929125756)
`-rpcworkqueue=` should be at least as large as the number of concurrent requests you are doing.
💬 maflcko commented on issue "When I make a highly concurrent request to bitcoin core, a new block appears and all my requests get blocked":
(https://github.com/bitcoin/bitcoin/issues/29384#issuecomment-1929130106)
`-rpcthreads=` should be at least as large as the number of concurrent requests you are doing, otherwise there won't be any threads to service the query and the work-queue will eventually overflow.
(https://github.com/bitcoin/bitcoin/issues/29384#issuecomment-1929130106)
`-rpcthreads=` should be at least as large as the number of concurrent requests you are doing, otherwise there won't be any threads to service the query and the work-queue will eventually overflow.
💬 vasild commented on pull request "util: check for errors after close and read in AutoFile":
(https://github.com/bitcoin/bitcoin/pull/29307#issuecomment-1929136430)
Ok, the users of the class then have to explicitly close. That is 1.4. from the OP, I elaborated it with more words.
(https://github.com/bitcoin/bitcoin/pull/29307#issuecomment-1929136430)
Ok, the users of the class then have to explicitly close. That is 1.4. from the OP, I elaborated it with more words.
💬 scgbckbone commented on pull request "test: Add `leaf_version` parameter to `taproot_tree_helper()`":
(https://github.com/bitcoin/bitcoin/pull/29371#discussion_r1479508835)
this line should be removed and only `leaf_version` function argument should be used in the function. Both `version` and `leaf_version` will point to the same object [anyways](https://github.com/python/cpython/blob/4830f581af57dd305c02c1fd72299ecb5b090eca/Objects/longobject.c#L18-L23). Same with all possible future leaf versions [even 0xc0..0xfe](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-7)
(https://github.com/bitcoin/bitcoin/pull/29371#discussion_r1479508835)
this line should be removed and only `leaf_version` function argument should be used in the function. Both `version` and `leaf_version` will point to the same object [anyways](https://github.com/python/cpython/blob/4830f581af57dd305c02c1fd72299ecb5b090eca/Objects/longobject.c#L18-L23). Same with all possible future leaf versions [even 0xc0..0xfe](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-7)
👍 scgbckbone approved a pull request: "test: Add `leaf_version` parameter to `taproot_tree_helper()`"
(https://github.com/bitcoin/bitcoin/pull/29371#pullrequestreview-1864732480)
utACK
(https://github.com/bitcoin/bitcoin/pull/29371#pullrequestreview-1864732480)
utACK