Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wallet: fully migrate address book entries for watchonly/solvable wallets #26761

Merged

Conversation

theStack
Copy link
Contributor

Currently migratewallet migrates the address book (i.e. labels and purposes) for watchonly and solvable wallets only in RAM, but doesn't persist them on disk. Fix this by adding another loop for both of the special wallet types after which writes the corresponding NAME and PURPOSE entries to the database in a single batch. Also adds a corresponding test that checks if labels were migrated correctly for a watchonly wallet.

…lets

Currently `migratewallet` migrates the address book (i.e. labels and
purposes) for watchonly and solvable wallets only in RAM, but doesn't
persist them on disk. Fix this by adding another loop for both of the
special wallet types after which writes the corresponding NAME and
PURPOSE entries to the database in a single batch.
@DrahtBot
Copy link
Contributor

DrahtBot commented Dec 28, 2022

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

Reviews

See the guideline for information on the review process.

Type Reviewers
ACK achow101, furszy, aureleoules

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

@maflcko
Copy link
Member

maflcko commented Dec 28, 2022

Is this for backport?

Copy link

@Sarkerversion2030 Sarkerversion2030 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@theStack
Copy link
Contributor Author

theStack commented Jan 3, 2023

Is this for backport?

I'd say yes. Though the issue only affects an experimental RPC and is not as severe as e.g. a node crash or losing funds, losing labels after migration is still annoying enough for users.

@achow101
Copy link
Member

achow101 commented Jan 3, 2023

ACK 730e14a

Copy link
Member

@furszy furszy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

code ACK 730e14a, left a non-blocking nit.

// Persist added address book entries (labels, purpose) for watchonly and solvable wallets
auto persist_address_book = [](const CWallet& wallet) {
LOCK(wallet.cs_wallet);
WalletBatch batch{wallet.GetDatabase()};
Copy link
Member

@furszy furszy Jan 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to call batch.TxnBegin() and batch.TxnCommit() to make this a real batch. (yes.. the WalletBatch name is misleading).

Extra note:
It's basically what have done in #25297. Batch entire processes where/when is possible.
Which.. should revive it soon and see how the current wallet behaves.

Copy link
Member

@aureleoules aureleoules left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 730e14a

I verified that the test fails on master.

auto purpose{addr_book_data.purpose};
auto label{addr_book_data.GetLabel()};
// don't bother writing default values (unknown purpose, empty label)
if (purpose != "unknown") batch.WritePurpose(address, purpose);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe unrelated but shouldn't these purpose strings be stored in a header file such as static const char* PURPOSE_RECEIVE = "receive" instead of inlining them?

Copy link
Member

@furszy furszy Jan 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, I remember doing this changes in the past. Moving the possible purposes to a separate file so it can be included in the GUI model and widgets without requiring wallet dependency (we want the GUI to be as abstracted as possible from the wallet internals).

@achow101 achow101 merged commit b4fb0a3 into bitcoin:master Jan 5, 2023
@theStack theStack deleted the 202212-migratewallet_persist_addressbook branch January 5, 2023 18:01
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Jan 6, 2023
…atchonly/solvable wallets

730e14a test: wallet: check that labels are migrated to watchonly wallet (Sebastian Falbesoner)
d5f4ae7 wallet: fully migrate address book entries for watchonly/solvable wallets (Sebastian Falbesoner)

Pull request description:

  Currently `migratewallet` migrates the address book (i.e. labels and purposes) for watchonly and solvable wallets only in RAM, but doesn't persist them on disk. Fix this by adding another loop for both of the special wallet types after which writes the corresponding NAME and PURPOSE entries to the database in a single batch. Also adds a corresponding test that checks if labels were migrated correctly for a watchonly wallet.

ACKs for top commit:
  achow101:
    ACK 730e14a
  furszy:
    code ACK 730e14a, left a non-blocking nit.
  aureleoules:
    ACK 730e14a

Tree-SHA512: 159487e11e858924ef762e0190ccaea185bdff239e3d2280c8d63c4ac2649ec71714dc4d53dec644f03488f91c3b4bbbbf3434dad23bc0fcecb6657f353ea766
fanquake pushed a commit to fanquake/bitcoin that referenced this pull request Jan 12, 2023
…lets

Currently `migratewallet` migrates the address book (i.e. labels and
purposes) for watchonly and solvable wallets only in RAM, but doesn't
persist them on disk. Fix this by adding another loop for both of the
special wallet types after which writes the corresponding NAME and
PURPOSE entries to the database in a single batch.

Github-Pull: bitcoin#26761
Rebased-From: d5f4ae7
fanquake pushed a commit to fanquake/bitcoin that referenced this pull request Jan 12, 2023
@fanquake fanquake mentioned this pull request Jan 12, 2023
@fanquake
Copy link
Member

Backported in #26878.

fanquake pushed a commit to fanquake/bitcoin that referenced this pull request Jan 12, 2023
…lets

Currently `migratewallet` migrates the address book (i.e. labels and
purposes) for watchonly and solvable wallets only in RAM, but doesn't
persist them on disk. Fix this by adding another loop for both of the
special wallet types after which writes the corresponding NAME and
PURPOSE entries to the database in a single batch.

Github-Pull: bitcoin#26761
Rebased-From: d5f4ae7
fanquake pushed a commit to fanquake/bitcoin that referenced this pull request Jan 12, 2023
fanquake pushed a commit to fanquake/bitcoin that referenced this pull request Feb 22, 2023
…lets

Currently `migratewallet` migrates the address book (i.e. labels and
purposes) for watchonly and solvable wallets only in RAM, but doesn't
persist them on disk. Fix this by adding another loop for both of the
special wallet types after which writes the corresponding NAME and
PURPOSE entries to the database in a single batch.

Github-Pull: bitcoin#26761
Rebased-From: d5f4ae7
fanquake pushed a commit to fanquake/bitcoin that referenced this pull request Feb 22, 2023
glozow added a commit that referenced this pull request Feb 27, 2023
784a754 wallet, rpc: Update migratewallet help text for encrypted wallets (Andrew Chow)
debcfe3 tests: Tests for migrating wallets by name, and providing passphrase (Andrew Chow)
ccc72fe wallet: Be able to unlock the wallet for migration (Andrew Chow)
50dd8b1 rpc: Allow users to specify wallet name for migratewallet (Andrew Chow)
648b062 wallet: Allow MigrateLegacyToDescriptor to take a wallet name (Andrew Chow)
ab3bd45 i2p: use consistent number of tunnels with i2pd and Java I2P (Vasil Dimov)
29cdf42 i2p: lower the number of tunnels for transient sessions (Vasil Dimov)
5027e93 i2p: reuse created I2P sessions if not used (Vasil Dimov)
a62c541 wallet: reuse change dest when recreating TX with avoidpartialspends (Matthew Zipkin)
64e7db6 Zero out wallet master key upon lock (John Moffett)
b7e242e Correctly limit overview transaction list (John Moffett)
cff6718 depends: fix systemtap download URL (fanquake)
7cf73df Add missing includes to fix gcc-13 compile error (MarcoFalke)
07397cd addrdb: Only call Serialize() once (Martin Zumsande)
91f83db hash: add HashedSourceWriter (Martin Zumsande)
5c824ac For feebump, ignore abandoned descendant spends (John Moffett)
428dcd5 wallet: Skip rescanning if wallet is more recent than tip (Andrew Chow)
cbcdafa test: wallet: check that labels are migrated to watchonly wallet (Sebastian Falbesoner)
342abfb wallet: fully migrate address book entries for watchonly/solvable wallets (Sebastian Falbesoner)

Pull request description:

  Backports:
  * #26595
  * #26675
  * #26679
  * #26761
  * #26837
  * #26909
  * #26924
  * #26944
  * bitcoin-core/gui#704
  * #27053
  * #27080

ACKs for top commit:
  instagibbs:
    ACK 784a754
  achow101:
    ACK 784a754
  hebasto:
    ACK 784a754, I've made backporting locally and got a diff between my branch and this PR as follows:

Tree-SHA512: 8ea84aa02d7907ff1e202e1302b441ce9ed2198bf383620ad40056a5d7e8ea88e1047abef0b92d85648016bf9b3195c974be3806ccebd85bef4f85c326869e43
auto label{addr_book_data.GetLabel()};
// don't bother writing default values (unknown purpose, empty label)
if (purpose != "unknown") batch.WritePurpose(address, purpose);
if (!label.empty()) batch.WriteName(address, label);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In commit "wallet: fully migrate address book entries for watchonly/solvable wallets" (d5f4ae7)

It seems like a bug to not write the label when then label is empty, because will make receiving address with empty labels labels appear to be change addresses. If the label isn't written CAddressBookData::SetLabel will not be called:

bitcoin/src/wallet/wallet.h

Lines 219 to 222 in f50fb17

void SetLabel(const std::string& label) {
m_change = false;
m_label = label;
}

so CAddressBookData::IsChange will return true

bool IsChange() const { return m_change; }

Probably this line should say:

if (!addr_book_data.IsChange()) batch.WriteName(address, addr_book_data.GetLabel());

Copy link
Member

@furszy furszy Mar 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Check #26836, bug should be fixed there. Have re-written the process without the persist_address_book calls (there by, no empty labels should be skipped).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks will check it out. Also would be good to have a test for the bug.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah 👌🏼.

ryanofsky added a commit to ryanofsky/bitcoin that referenced this pull request Mar 13, 2023
Instead of storing and passing around fixed strings for the purpose of
an address, use an enum.

This also rationalizes the CAddressBookData struct, documenting all fields and
making them public, and simplifying the representation to avoid bugs like
bitcoin#26761 (comment) and make
it not possible to invalid address data like change addresses with labels.

Co-authored-by: Ryan Ofsky <ryan@ofsky.org>
achow101 added a commit to achow101/bitcoin that referenced this pull request Mar 15, 2023
Instead of storing and passing around fixed strings for the purpose of
an address, use an enum.

This also rationalizes the CAddressBookData struct, documenting all fields and
making them public, and simplifying the representation to avoid bugs like
bitcoin#26761 (comment) and make
it not possible to invalid address data like change addresses with labels.

Co-authored-by: Ryan Ofsky <ryan@ofsky.org>
achow101 added a commit to achow101/bitcoin that referenced this pull request Mar 17, 2023
Instead of storing and passing around fixed strings for the purpose of
an address, use an enum.

This also rationalizes the CAddressBookData struct, documenting all fields and
making them public, and simplifying the representation to avoid bugs like
bitcoin#26761 (comment) and make
it not possible to invalid address data like change addresses with labels.

Co-authored-by: Ryan Ofsky <ryan@ofsky.org>
achow101 added a commit to achow101/bitcoin that referenced this pull request Mar 17, 2023
Instead of storing and passing around fixed strings for the purpose of
an address, use an enum.

This also rationalizes the CAddressBookData struct, documenting all fields and
making them public, and simplifying the representation to avoid bugs like
bitcoin#26761 (comment) and make
it not possible to invalid address data like change addresses with labels.

Co-authored-by: Ryan Ofsky <ryan@ofsky.org>
achow101 added a commit to achow101/bitcoin that referenced this pull request Mar 20, 2023
Instead of storing and passing around fixed strings for the purpose of
an address, use an enum.

This also rationalizes the CAddressBookData struct, documenting all fields and
making them public, and simplifying the representation to avoid bugs like
bitcoin#26761 (comment) and make
it not possible to invalid address data like change addresses with labels.

Co-authored-by: Ryan Ofsky <ryan@ofsky.org>
achow101 added a commit to achow101/bitcoin that referenced this pull request Apr 10, 2023
Instead of storing and passing around fixed strings for the purpose of
an address, use an enum.

This also rationalizes the CAddressBookData struct, documenting all fields and
making them public, and simplifying the representation to avoid bugs like
bitcoin#26761 (comment) and make
it not possible to invalid address data like change addresses with labels.

Co-authored-by: Ryan Ofsky <ryan@ofsky.org>
achow101 added a commit to achow101/bitcoin that referenced this pull request Apr 11, 2023
Instead of storing and passing around fixed strings for the purpose of
an address, use an enum.

This also rationalizes the CAddressBookData struct, documenting all fields and
making them public, and simplifying the representation to avoid bugs like
bitcoin#26761 (comment) and make
it not possible to invalid address data like change addresses with labels.

Co-authored-by: Ryan Ofsky <ryan@ofsky.org>
achow101 added a commit to achow101/bitcoin that referenced this pull request Apr 11, 2023
Instead of storing and passing around fixed strings for the purpose of
an address, use an enum.

This also rationalizes the CAddressBookData struct, documenting all fields and
making them public, and simplifying the representation to avoid bugs like
bitcoin#26761 (comment) and make
it not possible to invalid address data like change addresses with labels.

Co-authored-by: Ryan Ofsky <ryan@ofsky.org>
RandyMcMillan pushed a commit to RandyMcMillan/bitcoin that referenced this pull request May 27, 2023
Instead of storing and passing around fixed strings for the purpose of
an address, use an enum.

This also rationalizes the CAddressBookData struct, documenting all fields and
making them public, and simplifying the representation to avoid bugs like
bitcoin#26761 (comment) and make
it not possible to invalid address data like change addresses with labels.

Co-authored-by: Ryan Ofsky <ryan@ofsky.org>
janus pushed a commit to BitgesellOfficial/bitgesell that referenced this pull request Sep 3, 2023
Instead of storing and passing around fixed strings for the purpose of
an address, use an enum.

This also rationalizes the CAddressBookData struct, documenting all fields and
making them public, and simplifying the representation to avoid bugs like
bitcoin/bitcoin#26761 (comment) and make
it not possible to invalid address data like change addresses with labels.

Co-authored-by: Ryan Ofsky <ryan@ofsky.org>
backpacker69 pushed a commit to peercoin/peercoin that referenced this pull request Mar 5, 2024
Instead of storing and passing around fixed strings for the purpose of
an address, use an enum.

This also rationalizes the CAddressBookData struct, documenting all fields and
making them public, and simplifying the representation to avoid bugs like
bitcoin/bitcoin#26761 (comment) and make
it not possible to invalid address data like change addresses with labels.

Co-authored-by: Ryan Ofsky <ryan@ofsky.org>
@bitcoin bitcoin locked and limited conversation to collaborators Mar 12, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

10 participants