Skip to content

Conversation

achow101
Copy link
Member

Wallet directories were introduced because BDB has issues with shared database environments. Since SQLite does not have database environments it is not necessary to have these directories. So instead, we go back to the original multiwallet plan of having just wallet files named with the desired wallet name. Note that this configuration is technically supported with BDB wallets although new wallets would not be created like this. For SQLite, this is both supported and the way that wallets are created.

Depends on #18788 for tests.

Removes the use of dumpprivkey so that descriptor wallets can pass on
this. Also does a few descriptor wallet specific changes due to
different IsMine semantics.
Import things into a separate watchonly wallet to work with descriptor
wallets.
Existing import* RPCs are disabled for descriptor wallets, so only do
these tests for legacy wallets.
Generate a privkey in the test framework instead of using dumpprivkey so
that descriptor wallets work in this test.
If using descriptor wallets, use importdescriptors instead of
importmulti.
…lance.py

Imports and watchonly behavior are legacy wallet only, so make them only
run when the test is in legacy wallet mode.
Create and import the multisig into a separate watchonly wallet so that
feature_nulldummy.py works with descriptor wallets.

blocktools.create_raw_transaction is also updated to use multiple nodes
and wallets and to use PSBT so that this test passes.
Descriptor wallets output slightly different information in the wallet
tool, so check that output when in descriptor wallet mode.
dumpprivkey and watchonly behavior don't work with descriptor wallets.

Test for multisigs is modified to not rely on watchonly behavior for
those multisigs. This has a side effect of removing listunspent, but
that's not the target of this test, so that's fine.
…wallet.py

sethdseed and importmulti are not available for descriptor wallets, so
when doing descriptor wallet tests, use importdescriptors instead.

Also changes some output to match what descriptor wallets will return.
…ypes.py

addmultisigaddress is not available in descriptor wallets, so only run
these when testing legacy wallets
The traditional multisig workflow doesn't work with descriptor wallets
so make these tests legacy wallet only.
…ptors

Although legacy wallet is still the default, for future use, add a
--legacy-wallet option to the test framework. Additional tests for
descriptor wallets have been enabled with the --descriptors option.
Tests that must be legacy wallet only are being started with
--legacy-wallet. Even though this option does not currently do anything,
this will be helpful in the future when descriptor wallets become the
default.
Some tests are legacy wallet only (and make legacy wallets) so they
shouldn't be run when doing descriptor wallet tests.
Like with BDB, we allow users to specify the wallet file directly,
rather than just a wallet dir name.
When --dsecriptors, we expect the wallets to be descriptor wallets, and
the reverse when not (or --legacy-wallet). So updated
wallet_multiwallet.py to do that.
It isn't necessary to have wallet directories for sqlite wallets, so we
should just make single files in the wallets dir.
@ryanofsky
Copy link
Contributor

I think wallets should keep being directories. Few reasons:

  • Aesthetics, usability, and the road to ambiguity. People are used to file names having extensions, and directory names not having extensions. If you create wallet named "My Wallet" in the GUI, or run bitcoin-cli createwallet "My Wallet", there's nothing unusual about seeing a directory called "My Wallet" in <walletdir>. If "My Wallet" is created as a file not a directory, then you have an unusual looking file with no extension. So then there is a reason to call bitcoin-cli createwallet with a name that looks more like a filename: mywallet.dat, mywallet.db mywallet.wallet. And then the GUI starts showing lists of wallets like mywallet1.wallet and mywallet2.wallet and RPC endpoints looks like /wallet/mywallet1.wallet and /wallet/mywallet2.wallet. And then to improve ergonomics, somebody writes a PR to strip extensions, so GUI is more user-friendly or so RPC endpoint names are less verbose. And then simple mapping of wallet name == RPC endpoint name == GUI display name is broken, so now there are multiple mappings, ambiguity, more confusion, and everything is more complicated and stupid.

  • Backup safety. The claim that "Since SQLite does not have database environments it is not necessary to have these directories" is ambiguous and not accurate as far as I know. The sqlite implementation does not require periodic flushing to consolidate log files, but that doesn't mean that sqlite doesn't create log files. If you create a <walletname> wallet, sqlite will create a <walletname>.wallet-journal file, so if you have a backup script that is periodically backing up the <walletdir>/<walletname> path, it can miss the journal file. If the backup script wants to include the journal file, it needs to know about wallet database layout. It is better if wallet is just a directory, so the backup script can back up the directory without having to care about database layout. If script wants to care about the layout, it can still do that and exclude things, but the simple non-invasive approach will include data instead of excluding it.

  • Future extensibility. It's nice if wallets are directories instead of files, so there is a place to add new files associated with the wallet. I have PRs that let wallets run as separate processes. These wallet processes will want to run RPC servers. These RPC servers will need a place to put cookie files. A logical place would be inside the wallet directory. Similarly with future per-wallet debug logs, per-wallet settings files, per-wallet socket endpoints. If you have wallet directory, there is a natural place to put all these things. Users and external tools will be able to locate all data associated with a wallet without having to make assumptions about layout.

@DrahtBot
Copy link
Contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

@hebasto
Copy link
Member

hebasto commented Oct 29, 2020

I agree with @ryanofsky's reasons, especially with "Future extensibility" and "Backup safety".

As for wallet names that looks like <filename><dot><extension>, they could cause user confusion and fund loss because some OSes hide extensions from users.

@sipa
Copy link
Member

sipa commented Oct 29, 2020

@ryanofsky I considered being able to move to non-directory wallets an advantage of sqlite, but you give good arguments for sticking with directories.

@DrahtBot
Copy link
Contributor

🐙 This pull request conflicts with the target branch and needs rebase.

Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a "draft".

@achow101
Copy link
Member Author

@ryanofsky makes a convincing argument. Closing.

@achow101 achow101 closed this Oct 29, 2020
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Feb 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants