👍 Ronnie6464 approved a pull request: "wallet: ensure the wallet is unlocked when needed for rescanning"
(https://github.com/bitcoin/bitcoin/pull/26347#pullrequestreview-1447808954)
test/functional/wallet_transactiontime_rescan.py
(https://github.com/bitcoin/bitcoin/pull/26347#pullrequestreview-1447808954)
test/functional/wallet_transactiontime_rescan.py
💬 Ronnie6464 commented on pull request "wallet: ensure the wallet is unlocked when needed for rescanning":
(https://github.com/bitcoin/bitcoin/pull/26347#discussion_r1208271444)
test/functional/wallet_transactiontime_rescan.py
(https://github.com/bitcoin/bitcoin/pull/26347#discussion_r1208271444)
test/functional/wallet_transactiontime_rescan.py
📝 achow101 locked a pull request: "wallet: ensure the wallet is unlocked when needed for rescanning"
(https://github.com/bitcoin/bitcoin/pull/26347)
Wallet passphrases are needed to top up the keypool of encrypted wallets
during a rescan. The following RPCs need the passphrase when rescanning:
- `importdescriptors`
- `rescanblockchain`
The following RPCs use the information about whether or not the
passphrase is being used to ensure that full rescans are able to
take place (meaning the following RPCs should not be able to run
if a rescan requiring the wallet to be unlocked is taking place):
- `walletlock`
- `encry
...
(https://github.com/bitcoin/bitcoin/pull/26347)
Wallet passphrases are needed to top up the keypool of encrypted wallets
during a rescan. The following RPCs need the passphrase when rescanning:
- `importdescriptors`
- `rescanblockchain`
The following RPCs use the information about whether or not the
passphrase is being used to ensure that full rescans are able to
take place (meaning the following RPCs should not be able to run
if a rescan requiring the wallet to be unlocked is taking place):
- `walletlock`
- `encry
...
📝 achow101 unlocked a pull request: "wallet: ensure the wallet is unlocked when needed for rescanning"
(https://github.com/bitcoin/bitcoin/pull/26347)
Wallet passphrases are needed to top up the keypool of encrypted wallets
during a rescan. The following RPCs need the passphrase when rescanning:
- `importdescriptors`
- `rescanblockchain`
The following RPCs use the information about whether or not the
passphrase is being used to ensure that full rescans are able to
take place (meaning the following RPCs should not be able to run
if a rescan requiring the wallet to be unlocked is taking place):
- `walletlock`
- `encry
...
(https://github.com/bitcoin/bitcoin/pull/26347)
Wallet passphrases are needed to top up the keypool of encrypted wallets
during a rescan. The following RPCs need the passphrase when rescanning:
- `importdescriptors`
- `rescanblockchain`
The following RPCs use the information about whether or not the
passphrase is being used to ensure that full rescans are able to
take place (meaning the following RPCs should not be able to run
if a rescan requiring the wallet to be unlocked is taking place):
- `walletlock`
- `encry
...
📝 achow101 locked a pull request: "wallet: ensure the wallet is unlocked when needed for rescanning"
(https://github.com/bitcoin/bitcoin/pull/26347)
Wallet passphrases are needed to top up the keypool of encrypted wallets
during a rescan. The following RPCs need the passphrase when rescanning:
- `importdescriptors`
- `rescanblockchain`
The following RPCs use the information about whether or not the
passphrase is being used to ensure that full rescans are able to
take place (meaning the following RPCs should not be able to run
if a rescan requiring the wallet to be unlocked is taking place):
- `walletlock`
- `encry
...
(https://github.com/bitcoin/bitcoin/pull/26347)
Wallet passphrases are needed to top up the keypool of encrypted wallets
during a rescan. The following RPCs need the passphrase when rescanning:
- `importdescriptors`
- `rescanblockchain`
The following RPCs use the information about whether or not the
passphrase is being used to ensure that full rescans are able to
take place (meaning the following RPCs should not be able to run
if a rescan requiring the wallet to be unlocked is taking place):
- `walletlock`
- `encry
...
💬 joostjager commented on issue "Allow accepting non-standard transactions on mainnet via local rpc":
(https://github.com/bitcoin/bitcoin/issues/27768#issuecomment-1565960002)
Could you provide a concrete example of such a high fee rate transaction that nevertheless isn't included in a block by miners? Also, could you elaborate on why that would be the case? I'd like to better understand their incentives and priorities.
(https://github.com/bitcoin/bitcoin/issues/27768#issuecomment-1565960002)
Could you provide a concrete example of such a high fee rate transaction that nevertheless isn't included in a block by miners? Also, could you elaborate on why that would be the case? I'd like to better understand their incentives and priorities.
📝 hebasto opened a pull request: "ci: Use docker image cache for "Win64 native [vs2022]" task"
(https://github.com/bitcoin/bitcoin/pull/27771)
This PR aims to speed up the "Win64 native [vs2022]" CI task by caching all prerequisite steps in the docker image cache.
(https://github.com/bitcoin/bitcoin/pull/27771)
This PR aims to speed up the "Win64 native [vs2022]" CI task by caching all prerequisite steps in the docker image cache.
📝 joostjager opened a pull request: "Make non-standard tx acceptance a peer option."
(https://github.com/bitcoin/bitcoin/pull/27772)
Make `-acceptnonstdtxn` apply to peers only and always allow local rpc calls to submit non-standard transactions to the mempool.
Fixes https://github.com/bitcoin/bitcoin/issues/27768
(https://github.com/bitcoin/bitcoin/pull/27772)
Make `-acceptnonstdtxn` apply to peers only and always allow local rpc calls to submit non-standard transactions to the mempool.
Fixes https://github.com/bitcoin/bitcoin/issues/27768
💬 dongcarl commented on pull request "contrib/init: Better systemd integration":
(https://github.com/bitcoin/bitcoin/pull/25975#issuecomment-1566203166)
Pushed 689a65d878:
- Addressed: https://github.com/bitcoin/bitcoin/pull/25975#discussion_r1182373299
(https://github.com/bitcoin/bitcoin/pull/25975#issuecomment-1566203166)
Pushed 689a65d878:
- Addressed: https://github.com/bitcoin/bitcoin/pull/25975#discussion_r1182373299
💬 dongcarl commented on pull request "contrib/init: Better systemd integration":
(https://github.com/bitcoin/bitcoin/pull/25975#discussion_r1208605841)
Incorporated, thanks!
(https://github.com/bitcoin/bitcoin/pull/25975#discussion_r1208605841)
Incorporated, thanks!
💬 dongcarl commented on pull request "contrib/init: Better systemd integration":
(https://github.com/bitcoin/bitcoin/pull/25975#issuecomment-1566204313)
I think whether or not to to add a `-nodebuglogfile` is somewhat tangential to the `systemd` integration and more related to whether or not `-daemonwait` is specified or even more specifically whether or not we're writing logs to `stdout`+`stderr`.
As in: Does a user of `bitcoind` that doesn't specify `-daemonwait` and expects logs on `stdout`+`stderr` also expect the debug log file to be written to or no?
In any case, I think we can leave that discussion for another time.
(https://github.com/bitcoin/bitcoin/pull/25975#issuecomment-1566204313)
I think whether or not to to add a `-nodebuglogfile` is somewhat tangential to the `systemd` integration and more related to whether or not `-daemonwait` is specified or even more specifically whether or not we're writing logs to `stdout`+`stderr`.
As in: Does a user of `bitcoind` that doesn't specify `-daemonwait` and expects logs on `stdout`+`stderr` also expect the debug log file to be written to or no?
In any case, I think we can leave that discussion for another time.
💬 sdaftuar commented on pull request "Make non-standard tx acceptance a peer option.":
(https://github.com/bitcoin/bitcoin/pull/27772#issuecomment-1566232510)
Rather than open more PRs that are duplicative of other recently rejected PRs, it would be more helpful to directly address the feedback that was previously given.
Are you unaware that some of the DoS attacks that are prevented by our standardness checks include situations where a block might be mined that would take a very long time to validate, a cost that would be felt by the whole network? See for instance https://bitcointalk.org/?topic=140078%7CCVE-2013-2292]]. It is absurd that this i
...
(https://github.com/bitcoin/bitcoin/pull/27772#issuecomment-1566232510)
Rather than open more PRs that are duplicative of other recently rejected PRs, it would be more helpful to directly address the feedback that was previously given.
Are you unaware that some of the DoS attacks that are prevented by our standardness checks include situations where a block might be mined that would take a very long time to validate, a cost that would be felt by the whole network? See for instance https://bitcointalk.org/?topic=140078%7CCVE-2013-2292]]. It is absurd that this i
...
👋 hebasto's pull request is ready for review: "ci: Use docker image cache for "Win64 native [vs2022]" task"
(https://github.com/bitcoin/bitcoin/pull/27771)
(https://github.com/bitcoin/bitcoin/pull/27771)
💬 hebasto commented on pull request "lint: stop ignoring LIEF imports":
(https://github.com/bitcoin/bitcoin/pull/27507#issuecomment-1566243044)
> > or an issue with the LIEF stubs. Am following up.
>
> This has now been resolved upstream in LIEF. See [lief-project/LIEF#909](https://github.com/lief-project/LIEF/issues/909) & [lief-project/LIEF@2e06bdb](https://github.com/lief-project/LIEF/commit/2e06bdb4af4586d1f5dcb9e9ccb027b55d457e24).
LIEF 0.13.1 has just been released with the fix.
(https://github.com/bitcoin/bitcoin/pull/27507#issuecomment-1566243044)
> > or an issue with the LIEF stubs. Am following up.
>
> This has now been resolved upstream in LIEF. See [lief-project/LIEF#909](https://github.com/lief-project/LIEF/issues/909) & [lief-project/LIEF@2e06bdb](https://github.com/lief-project/LIEF/commit/2e06bdb4af4586d1f5dcb9e9ccb027b55d457e24).
LIEF 0.13.1 has just been released with the fix.
💬 ryanofsky commented on pull request "util: generalize accounting of system-allocated memory in pool resource":
(https://github.com/bitcoin/bitcoin/pull/27748#issuecomment-1566300943)
> GitHub isn't allowing me to reopen this
In order to reopen the PR, the branch needs to point at the same commit it was pointing to at the time the PR was closed.
Right now the branch https://github.com/LarryRuane/bitcoin/commits/2023-05-resource-pool-system-alloc points to d25b54346fed931830cf3f538b96c5c346165487, but the PR points to 576a270bbcbb21725770b07ba32af8e0c8965f44. If you temporarily force push 576a270bbcbb21725770b07ba32af8e0c8965f44 to the branch, I think you should be able
...
(https://github.com/bitcoin/bitcoin/pull/27748#issuecomment-1566300943)
> GitHub isn't allowing me to reopen this
In order to reopen the PR, the branch needs to point at the same commit it was pointing to at the time the PR was closed.
Right now the branch https://github.com/LarryRuane/bitcoin/commits/2023-05-resource-pool-system-alloc points to d25b54346fed931830cf3f538b96c5c346165487, but the PR points to 576a270bbcbb21725770b07ba32af8e0c8965f44. If you temporarily force push 576a270bbcbb21725770b07ba32af8e0c8965f44 to the branch, I think you should be able
...
💬 theStack commented on issue "rpc_getblockfrompeer.py intermittent failure: assert_equal(pruneheight, 248); not(249 == 248)":
(https://github.com/bitcoin/bitcoin/issues/27749#issuecomment-1566354933)
After digging deeper and analyzing the [failed CI log](https://api.cirrus-ci.com/v1/task/4776911524593664/logs/ci.log), I got a clearer picture what's going on here.
Comparing the "Leaving block file" debug messages from a successful and the failed test run gave the
essential hint:
```
$ grep "Leaving block" successful_run.log
Leaving block file 0: CBlockFileInfo(blocks=249, size=65319, heights=0...248, time=2011-02-02...2023-05-28)
Leaving block file 1: CBlockFileInfo(blocks=251, size=6
...
(https://github.com/bitcoin/bitcoin/issues/27749#issuecomment-1566354933)
After digging deeper and analyzing the [failed CI log](https://api.cirrus-ci.com/v1/task/4776911524593664/logs/ci.log), I got a clearer picture what's going on here.
Comparing the "Leaving block file" debug messages from a successful and the failed test run gave the
essential hint:
```
$ grep "Leaving block" successful_run.log
Leaving block file 0: CBlockFileInfo(blocks=249, size=65319, heights=0...248, time=2011-02-02...2023-05-28)
Leaving block file 1: CBlockFileInfo(blocks=251, size=6
...
💬 Crypto2 commented on issue "listunspent, fundrawtransaction, getwalletinfo locks wallet for any other operation":
(https://github.com/bitcoin/bitcoin/issues/27002#issuecomment-1566421689)
> `listunspent`, `fundrawtransaction`, and the `send*` RPCs all require figuring out the UTXOs that belong to the wallet. Currently, that means iterating through every single output of every transaction in the wallet, including received, sent, and unrelated, all while holding the wallet lock to ensure that atomicity of the operation.
I've suggested before just having a second map of only unspents, should speed it up massively at the expense of some memory. Could be default off and have to ena
...
(https://github.com/bitcoin/bitcoin/issues/27002#issuecomment-1566421689)
> `listunspent`, `fundrawtransaction`, and the `send*` RPCs all require figuring out the UTXOs that belong to the wallet. Currently, that means iterating through every single output of every transaction in the wallet, including received, sent, and unrelated, all while holding the wallet lock to ensure that atomicity of the operation.
I've suggested before just having a second map of only unspents, should speed it up massively at the expense of some memory. Could be default off and have to ena
...
💬 LarryRuane commented on pull request "util: generalize accounting of system-allocated memory in pool resource":
(https://github.com/bitcoin/bitcoin/pull/27748#issuecomment-1566448078)
Thanks, Ryan!
(https://github.com/bitcoin/bitcoin/pull/27748#issuecomment-1566448078)
Thanks, Ryan!
📝 LarryRuane reopened a pull request: "util: generalize accounting of system-allocated memory in pool resource"
(https://github.com/bitcoin/bitcoin/pull/27748)
Follow-on to PR #25325, "Add pool based memory resource"
The `DynamicUsage()` function for the version of `unordered_map` that uses the `PoolAllocator` returns a close approximation of the amount of physical memory used by the map. (This is the map used for the dbcache.) It accounts for several of the allocator's internal data structures, such as the memory chunks and the freelist. It also includes the `unordered_map`'s bucket array (vector), which is a bit out of place because the rest of th
...
(https://github.com/bitcoin/bitcoin/pull/27748)
Follow-on to PR #25325, "Add pool based memory resource"
The `DynamicUsage()` function for the version of `unordered_map` that uses the `PoolAllocator` returns a close approximation of the amount of physical memory used by the map. (This is the map used for the dbcache.) It accounts for several of the allocator's internal data structures, such as the memory chunks and the freelist. It also includes the `unordered_map`'s bucket array (vector), which is a bit out of place because the rest of th
...
💬 mzumsande commented on issue "rpc_getblockfrompeer.py intermittent failure: assert_equal(pruneheight, 248); not(249 == 248)":
(https://github.com/bitcoin/bitcoin/issues/27749#issuecomment-1566554075)
Nice analysis!
> Not sure how to best solve this issue. Is there a way to enforce linear blocks reception at least when only having a single peer?
I think the cause is that a failed DoS check
`if (pindex->nHeight <= m_chainman.ActiveChain().Height() + 2) ` ([link](https://github.com/bitcoin/bitcoin/blob/7d33ae755de2bff806fe600bdaebedbd7fa67aba/src/net_processing.cpp#LL4342C9-L4342C72))
will revert to HeadersProcessing if the chain of node2 hasn't caught up enough (the new block is too fa
...
(https://github.com/bitcoin/bitcoin/issues/27749#issuecomment-1566554075)
Nice analysis!
> Not sure how to best solve this issue. Is there a way to enforce linear blocks reception at least when only having a single peer?
I think the cause is that a failed DoS check
`if (pindex->nHeight <= m_chainman.ActiveChain().Height() + 2) ` ([link](https://github.com/bitcoin/bitcoin/blob/7d33ae755de2bff806fe600bdaebedbd7fa67aba/src/net_processing.cpp#LL4342C9-L4342C72))
will revert to HeadersProcessing if the chain of node2 hasn't caught up enough (the new block is too fa
...