💬 maflcko commented on pull request "test: Add and use ElapseTime helper":
(https://github.com/bitcoin/bitcoin/pull/32430#issuecomment-3053003087)
> Sorry for the force-pushes, but this uncovered pre-existing issues in the fuzz tests that were not using mocktime during init. So I went ahead and fixed those as well in a separate commit. Should be good now, hopefully 😅
Went ahead and cherry-picked out the fuzz-fixes into https://github.com/bitcoin/bitcoin/pull/32927. Should be easy to (re-)review that one.
(https://github.com/bitcoin/bitcoin/pull/32430#issuecomment-3053003087)
> Sorry for the force-pushes, but this uncovered pre-existing issues in the fuzz tests that were not using mocktime during init. So I went ahead and fixed those as well in a separate commit. Should be good now, hopefully 😅
Went ahead and cherry-picked out the fuzz-fixes into https://github.com/bitcoin/bitcoin/pull/32927. Should be easy to (re-)review that one.
💬 stratospher commented on pull request "validation: invalid block handling followups":
(https://github.com/bitcoin/bitcoin/pull/32843#issuecomment-3053468148)
> I guess that means we could, instead of calc_flags_and_header, just use a bool calc_flags (for which we can't do a similar check). Do you think that would be clearer?
yes sounds good! (whenever you retouch next)
Ah missed the fact that iteration of entire block index is done in `SetBlockFailureFlags()` as well. I originally thought that iteration of entire block index is done only for best header calculation and `calc_flags_and_header` wasn't useful. Hence the confusion.
(https://github.com/bitcoin/bitcoin/pull/32843#issuecomment-3053468148)
> I guess that means we could, instead of calc_flags_and_header, just use a bool calc_flags (for which we can't do a similar check). Do you think that would be clearer?
yes sounds good! (whenever you retouch next)
Ah missed the fact that iteration of entire block index is done in `SetBlockFailureFlags()` as well. I originally thought that iteration of entire block index is done only for best header calculation and `calc_flags_and_header` wasn't useful. Hence the confusion.
🤔 stickies-v reviewed a pull request: "rpc, test: Fix JSON parsing errors in unloadwallet and getdescriptoractivity RPCs"
(https://github.com/bitcoin/bitcoin/pull/32845#pullrequestreview-3002523441)
I think the proposed fix for `getdescriptoractivity` is not robust, and the `GetWalletNameFromJSONRPCRequest()` overload confusing, as detailed in comments.
(https://github.com/bitcoin/bitcoin/pull/32845#pullrequestreview-3002523441)
I think the proposed fix for `getdescriptoractivity` is not robust, and the `GetWalletNameFromJSONRPCRequest()` overload confusing, as detailed in comments.
💬 stickies-v commented on pull request "rpc, test: Fix JSON parsing errors in unloadwallet and getdescriptoractivity RPCs":
(https://github.com/bitcoin/bitcoin/pull/32845#discussion_r2195638276)
I think these overloads are very confusing, and as such at higher risk for introducing bugs. Overloading on `std::string& wallet_name` vs `const std::string* wallet_name` when one is an out-parameter returning the wallet endpoint name, and the other an in-parameter representing a query parameter is not great. One overload throwing, and the other not, is even worse.
I'm still considering what the better alternatives would be - it seems like doing it properly would probably add quite a bit, but
...
(https://github.com/bitcoin/bitcoin/pull/32845#discussion_r2195638276)
I think these overloads are very confusing, and as such at higher risk for introducing bugs. Overloading on `std::string& wallet_name` vs `const std::string* wallet_name` when one is an out-parameter returning the wallet endpoint name, and the other an in-parameter representing a query parameter is not great. One overload throwing, and the other not, is even worse.
I'm still considering what the better alternatives would be - it seems like doing it properly would probably add quite a bit, but
...
💬 stickies-v commented on pull request "rpc, test: Fix JSON parsing errors in unloadwallet and getdescriptoractivity RPCs":
(https://github.com/bitcoin/bitcoin/pull/32845#discussion_r2195680365)
> Do we actually need to ensure that at least one such (valid) parameter is provided? If so, we should probably check that `blockindexes_sorted` and `scripts_to_watch` are not both empty. Otherwise, I think just making sure we only execute the `request.params[n].get_array().getValues()` statements if we've first checked that `!request.params[n].isNull()` should do the trick?
I don't think my comment was addressed, and e.g. this test still failing. According to the PR description and code chan
...
(https://github.com/bitcoin/bitcoin/pull/32845#discussion_r2195680365)
> Do we actually need to ensure that at least one such (valid) parameter is provided? If so, we should probably check that `blockindexes_sorted` and `scripts_to_watch` are not both empty. Otherwise, I think just making sure we only execute the `request.params[n].get_array().getValues()` statements if we've first checked that `!request.params[n].isNull()` should do the trick?
I don't think my comment was addressed, and e.g. this test still failing. According to the PR description and code chan
...
👍 stickies-v approved a pull request: "log: Mitigate disk filling attacks by rate limiting LogPrintf, LogInfo, LogWarning, LogError"
(https://github.com/bitcoin/bitcoin/pull/32604#pullrequestreview-3002650511)
re-ACK 4c772cbd83, no changes except release notes update
(https://github.com/bitcoin/bitcoin/pull/32604#pullrequestreview-3002650511)
re-ACK 4c772cbd83, no changes except release notes update
💬 stickies-v commented on pull request "log: Mitigate disk filling attacks by rate limiting LogPrintf, LogInfo, LogWarning, LogError":
(https://github.com/bitcoin/bitcoin/pull/32604#discussion_r2195710943)
nit: Conditional logs (or rather, everything with `should_ratelimit=false`) don't get the prefix. Perhaps the better/easier UX is to just apply it to all logs?
```suggestion
higher than debug, that is `info`, `warning`, and `error`. All unconditional logs will be
```
(https://github.com/bitcoin/bitcoin/pull/32604#discussion_r2195710943)
nit: Conditional logs (or rather, everything with `should_ratelimit=false`) don't get the prefix. Perhaps the better/easier UX is to just apply it to all logs?
```suggestion
higher than debug, that is `info`, `warning`, and `error`. All unconditional logs will be
```
💬 glozow commented on pull request "log: Mitigate disk filling attacks by rate limiting LogPrintf, LogInfo, LogWarning, LogError":
(https://github.com/bitcoin/bitcoin/pull/32604#discussion_r2195734934)
fwiw I didn't mean for this to hold up the PR, but thanks for taking the suggestion!
(https://github.com/bitcoin/bitcoin/pull/32604#discussion_r2195734934)
fwiw I didn't mean for this to hold up the PR, but thanks for taking the suggestion!
💬 glozow commented on pull request "log: Mitigate disk filling attacks by rate limiting LogPrintf, LogInfo, LogWarning, LogError":
(https://github.com/bitcoin/bitcoin/pull/32604#issuecomment-3053633853)
reACK 4c772cb
(https://github.com/bitcoin/bitcoin/pull/32604#issuecomment-3053633853)
reACK 4c772cb
🚀 glozow merged a pull request: "log: Mitigate disk filling attacks by rate limiting LogPrintf, LogInfo, LogWarning, LogError"
(https://github.com/bitcoin/bitcoin/pull/32604)
(https://github.com/bitcoin/bitcoin/pull/32604)
💬 instagibbs commented on pull request "p2p: Relax BlockRequestAllowed to respond to advertised blocks":
(https://github.com/bitcoin/bitcoin/pull/32869#issuecomment-3053653904)
@davidgumberg for completeness, the other solution, as stated in the issue tracker, would be to send a `notfound` in response to requests for invalid blocks. I'm not sure where people landed on that as that discussion was a long time ago
(https://github.com/bitcoin/bitcoin/pull/32869#issuecomment-3053653904)
@davidgumberg for completeness, the other solution, as stated in the issue tracker, would be to send a `notfound` in response to requests for invalid blocks. I'm not sure where people landed on that as that discussion was a long time ago
💬 pablomartin4btc commented on pull request "rpc, test: Fix JSON parsing errors in unloadwallet and getdescriptoractivity RPCs":
(https://github.com/bitcoin/bitcoin/pull/32845#discussion_r2195750958)
I could use a better naming for this function, not being an overload. My idea was to fix the issue without touching much and later refactor both `GetWalletNameFromJSONRPCRequest` and `GetWalletForJSONRPCRequest` on a separate PR. Currently `GetWalletForJSONRPCRequest`, which is used broadly, calls internally `GetWalletNameFromJSONRPCRequest` and wanted to keep them untouched for now.
(https://github.com/bitcoin/bitcoin/pull/32845#discussion_r2195750958)
I could use a better naming for this function, not being an overload. My idea was to fix the issue without touching much and later refactor both `GetWalletNameFromJSONRPCRequest` and `GetWalletForJSONRPCRequest` on a separate PR. Currently `GetWalletForJSONRPCRequest`, which is used broadly, calls internally `GetWalletNameFromJSONRPCRequest` and wanted to keep them untouched for now.
💬 darosior commented on pull request "policy: make pathological transactions packed with legacy sigops non-standard":
(https://github.com/bitcoin/bitcoin/pull/32521#discussion_r2195765195)
I prefer it this way.
(https://github.com/bitcoin/bitcoin/pull/32521#discussion_r2195765195)
I prefer it this way.
💬 darosior commented on pull request "policy: make pathological transactions packed with legacy sigops non-standard":
(https://github.com/bitcoin/bitcoin/pull/32521#discussion_r2195765353)
Done.
(https://github.com/bitcoin/bitcoin/pull/32521#discussion_r2195765353)
Done.
💬 darosior commented on pull request "policy: make pathological transactions packed with legacy sigops non-standard":
(https://github.com/bitcoin/bitcoin/pull/32521#discussion_r2195765533)
Done.
(https://github.com/bitcoin/bitcoin/pull/32521#discussion_r2195765533)
Done.
💬 darosior commented on pull request "policy: make pathological transactions packed with legacy sigops non-standard":
(https://github.com/bitcoin/bitcoin/pull/32521#discussion_r2195766179)
Done. Thanks for the screenshot.
(https://github.com/bitcoin/bitcoin/pull/32521#discussion_r2195766179)
Done. Thanks for the screenshot.
🚀 glozow merged a pull request: "mempool: use `FeeFrac` for ancestor/descendant score comparators"
(https://github.com/bitcoin/bitcoin/pull/32799)
(https://github.com/bitcoin/bitcoin/pull/32799)
💬 ishaanam commented on pull request "wallet, rpc: add v3 transaction creation and wallet support":
(https://github.com/bitcoin/bitcoin/pull/32896#discussion_r2195916152)
I've changed this test to import `TX_MAX_STANDARD_VERSION` instead.
(https://github.com/bitcoin/bitcoin/pull/32896#discussion_r2195916152)
I've changed this test to import `TX_MAX_STANDARD_VERSION` instead.
💬 ishaanam commented on pull request "wallet, rpc: add v3 transaction creation and wallet support":
(https://github.com/bitcoin/bitcoin/pull/32896#discussion_r2195917838)
Done
(https://github.com/bitcoin/bitcoin/pull/32896#discussion_r2195917838)
Done
🤔 furszy reviewed a pull request: "index: fix wrong assert of current_tip == m_best_block_index"
(https://github.com/bitcoin/bitcoin/pull/32878#pullrequestreview-3003004554)
@HowHsu, check this test https://github.com/furszy/bitcoin-core/commit/f2b8a06060e2a313f35101454c7669d46e0edc38.
It triggers the reorg assertion failure without needing to deduplicate the index synchronization code. The test fails without your fix commit and passes with it. Feel free to cherry-pick it.
> The Sync in the test is same as in bitcoind, expect the thread synchronization code which is to trigger the reorg. The only cons is we have to keep it updated when the logic of Sync() change
...
(https://github.com/bitcoin/bitcoin/pull/32878#pullrequestreview-3003004554)
@HowHsu, check this test https://github.com/furszy/bitcoin-core/commit/f2b8a06060e2a313f35101454c7669d46e0edc38.
It triggers the reorg assertion failure without needing to deduplicate the index synchronization code. The test fails without your fix commit and passes with it. Feel free to cherry-pick it.
> The Sync in the test is same as in bitcoind, expect the thread synchronization code which is to trigger the reorg. The only cons is we have to keep it updated when the logic of Sync() change
...