bitcoind shouldn't be shutdown automatically despite wallet synchronisation error

GregTonoski commented at 11:34 am on August 18, 2024: none

Is there an existing issue for this?

I have searched the existing issues

Current behaviour

Bitcoind startup is terminated.

Expected behaviour

bitcoind should complete startup and keep running successfully.

Steps to reproduce

Step: $ ./bitcoind

Relevant log output

Result (logs): Keys: 9 plaintext, 0 encrypted, 0 w/ metadata, 9 total. Unknown wallet records: 0 Wallet completed loading in 326ms Error: Prune: last wallet synchronisation goes beyond pruned data. You need to -reindex (download the whole blockchain again in case of pruned node) Error: Prune: last wallet synchronisation goes beyond pruned data. You need to -reindex (download the whole blockchain again in case of pruned node) Shutdown: In progress… scheduler thread exit Shutdown: done

How did you obtain Bitcoin Core

Compiled from source

What version of Bitcoin Core are you using?

master

Operating system and version

Linux

Machine specifications

No response

maflcko added the label Wallet on Aug 19, 2024

willcl-ark commented at 9:15 am on August 19, 2024: member

Is the rationale proposed that it’s more important for the node to be running than successfully to load a startup wallet? IMO loading a chosen wallet successfully would usually be more important.

If we changed to not fail startup the main effect would be that bitcoind would start up and sync further forwards, increasing the total work and time needed to resync back to a consistent state for that wallet. Therefore it seems to make most sense that we fail “early and fast” if we need a resync (for any reason) that way minimising the work and bandwidth used on the node and on the network.

I guess this could become more complicated in a multi-wallet setup where you may not want a single wallet failing to load to shutdown the whole node though.

Other options are to remove the failing wallet from the config or restart with -nowallet if starting up at all costs is more important to you.

GregTonoski commented at 9:46 am on August 19, 2024: none

Is the rationale proposed that it’s more important for the node to be running than successfully to load a startup wallet?

Yes. I would prefer bitcoind to run independently from a wallet by default. I don’t see a reason for a wallet to drive behaviur of bitcoind. Also, blocked startup of bitcoind could be seen as a (minor?) security issue.

Therefore it seems to make most sense that we fail “early and fast” if we need a resync (for any reason) that way minimising the work and bandwidth used on the node and on the network.

The reasoning doesn’t justify bitcoind startup to be dependent on a wallet. Even if, then a wallet state could have been synced from chainstate/UTXO set with txindex without additional work and bandwith consumed. Ideally, wallet should keep syncing with new data and warning (about old data being not fully synced).

maflcko commented at 10:03 am on August 19, 2024: member

Even if, then a wallet state could have been synced from chainstate/UTXO set with txindex without additional work and bandwith consumed.

Prune mode is incompatible with txindex, and will similarly abort the start. This means that if you had txindex enabled, prune mode would be disabled, and you wouldn’t see the error in the issue description in the first place.

GregTonoski commented at 10:30 am on August 19, 2024: none

Even if, then a wallet state could have been synced from chainstate/UTXO set with txindex without additional work and bandwith consumed.

Prune mode is incompatible with txindex, and will similarly abort the start. This means that if you had txindex enabled, prune mode would be disabled, and you wouldn’t see the error in the issue description in the first place.

I agree (and to clarify the corner case: “wallet state could have been synced from chainstate/UTXO set with txindex [using RPCs to a so-called unpruned node]”).

The main point still holds: Bitcoind startup should not be terminated despite wallet synchronisation error.

maflcko commented at 11:01 am on August 19, 2024: member

The main point still holds: Bitcoind startup should not be terminated despite wallet synchronisation error.

I disagree that an error should be silently ignored during startup. If the user asked for something during startup, it seems clearer to tell them as soon as possible that the request could not be fulfilled. This allows them to evaluate their alternatives, or spot possible mistakes in their setup. If the user request is silently ignored, it may just lead to a different kind of error down the line, which could be confusing and could make debugging harder.

GregTonoski commented at 11:17 am on August 19, 2024: none

The main point still holds: Bitcoind startup should not be terminated despite wallet synchronisation error.

I disagree that an error should be silently ignored during startup.

I am also not advocating for silently ignoring wallet error message during bitcoind startup. At the same time, I think that blocking bitcoind startup is not the same as alerting a user. Thankfully, operating system is not shut down due to Bitcoin Core Wallet error message.

furszy commented at 7:21 pm on August 20, 2024: member

The error message could suggest an alternative path to follow, such as: “If you want to proceed without using this wallet, use ‘-disablewallet=<wallet_name>’ during startup”.

GregTonoski commented at 7:34 pm on August 20, 2024: none

The error message could suggest an alternative path to follow, such as: “If you want to proceed without using this wallet, use ‘-disablewallet=<wallet_name>’ during startup”.

Why not automatically unloading a wallet if it prevents bitcoind from completing start-up?

furszy commented at 8:09 pm on August 20, 2024: member

Why not automatically unloading a wallet if it prevents bitcoind from completing start-up?

Wallets contain users’ money. We should not silently unload any of them without user interaction. Their importance is greater than completing a node startup. Imagine how would you behave if you start your wallet’s node and your coins are not there.

GregTonoski commented at 6:23 am on August 21, 2024: none

Wallets contain users’ money. We should not silently unload any of them without user interaction. Their importance is greater than completing a node startup. Imagine how would you behave if you start your wallet’s node and your coins are not there.

As a user, I want to start bitcoind irrespectively of coins being in a wallet. In this case, I don’t even enable RPC which makes it impossible for me to check wallet’s balance.

maflcko commented at 6:35 am on August 21, 2024: member

I want to start bitcoind

As mentioned previously, it is possible to do so in any previous release of Bitcoin Core, and no one is holding you back from doing so.

I agree that the error message can be improved to add more context or suggestions, but reworking the startup (and post-startup) behavior in a breaking change for all users with questionable trade-offs is unlikely to happen.

furszy commented at 1:37 pm on August 21, 2024: member

As a user, I want to start bitcoind irrespectively of coins being in a wallet.

There are four ways to opt-out of running a wallet:

Do not run any wallet: -nowallet=1.
Do not run a specific wallet -disablewallet=<wallet_name>.
Remove the wallet json object manually from the settings.json file.
Disable wallet support at the binaries level during build (maybe we could provide this binaries in the future).

Any of them will work fine in your specific case of not caring about your existing wallet.

ryanofsky commented at 2:53 pm on August 21, 2024: contributor

Agree with furszy and marco that current behavior makes sense and there are a lot of existing options for dealing with this situation. I could imagine adding new options, however, like -reindex=auto to reindex automatically when needed, or -allowfail=wallets, -allowfail=indexes to allow starting up when wallets or indexes fail to load.

maflcko commented at 9:04 am on August 22, 2024: member

Updating the help texts in the GUI and the daemon around -prune to mention that wallets (and indexes) should ideally be kept loaded or active to avoid sync catch-up errors from happening at all and avoid this error in the first place could make sense as well.

bitcoind shouldn’t be shutdown automatically despite wallet synchronisation error #30671