Thank you ššš«
Itās a little misleading to non experts like me that two different options let you do the same thing. Maybe a short explanation or example below the options could help.
Discussion
Yeah, thatās a good idea.
As a general rule of thumb, you pretty much always want to use New Wallet. Thatās what I always do.
Itās fairly low effort to create new wallets, so I encourage you to try out different settings and observe how the generated addresses change.
Great advice!
So sparrow understands wallet not really as a whole wallet but rather as a window looking into a wallet. And thus i can create multiple windows looking into the same wallet via different options. Does that come close?
Tried to zap you, but canāt do it unfortunately š
No worries, I heard my node is having some kind of issue. Just havenāt looked into it yet.
Yes. To be precise, #Bitcoin does not have an āaccountā model. It has a transaction model. Transactions involve previously unspent outputs (UTXOs) and yield new outputs. Outputs are locked using scripts, the hashes of which we call āaddressesā.
So then what is a wallet? A wallet is, essentially, information that allows the user to:
1. Generate addresses.
2. Create transactions involving those addresses.
3. Determine whether a transaction involves its addresses.
The wallet is the closest thing you have to an āaccountā in Bitcoin. To discover incoming payments, your wallet needs to connect to a node, which has visibility into all transactions. (The exact mechanism for how the wallet talks to the node can vary).
Strictly speaking the wallet doesnāt need any secret information. It works on what are called āpublicā data, such as your XPUB, which can be used to generate addresses. You donāt necessarily want to leak this data for privacy reasons, but an entity that gets a hold of it cannot spend your coins.
A keystore, in Sparrow parlance, is something that stores the secret informationāthe ākeysā or seed material. While your wallet needs to at least occasionally connect to a node to discover transactions or broadcast new ones, a keystore has no such need. Its job is solely to secure the seed material while in use.
(Aside: Super strictly speaking, Sparrow allows keystores which contain only public info, such as an XPUB to create watch-only wallets. But the core idea here is that keystores hold secrets and wallets interface with the world.)
So when you create a wallet in Sparrow, it sets up a file with info about the keystores in use. This file has a name and lives on your hard drive. You can create a password to encrypt the file, which protects against malicious code on your computer reading its contents.
If you create two wallet files with different names, but all the same parameters (keystores, etc.) those two wallets will generate the same sequences of addresses and have the same signing capabilities. Itās the same as if you made two text files and pasted the same information into both. The two text files are different files but contain the same information. Same with making duplicate wallets.
In fact, itās a good practice to make a duplicate right away as practice. Making a duplicate wallet is the same as your recovery procedure. That is, your recovery procedure consists of making a ānewā wallet that yields the same addresses to receive and sign.
Thanks for the detailed explanation. I am very interested in this.
So is it also possible to grab that wallet file created by sparrow and copy it into the same directory on another computer? Or do i need to use the Export option for that?
Either should work. You can copy the file directly from ~/.sparrow, IIRC, or export in Sparrow format.
Will try that. Is there any risk involved in moving files around that cointain xpub data? Obviously not going to upload it to the cloud but it will live on multiple devices
Leaking your XPUB is a privacy risk. Whoever gets that knows every address that belongs to your wallet: past, present and future. They donāt necessarily know those addresses belong to *you* personally, but they know the addresses go together.
The most likely way youāll leak your XPUBs is by connecting to an Electrum server, or a vendorās wallet that collects this data.
When you start up Sparrow, itāll ask how you want to connect to your node. Options include Bitcoin Core, private Electrum server, and public Electrum server. For maximum privacy and speed, itās best to run your own Electrum server. Iāve used ElectrumX and Fulcrum. Iāve heard good things about electrs but I havenāt tried it.
If your wallet has previously been connected to some other service, like, say, your hardware vendorās app, then your XPUB has in all likelihood already been leaked. The only way to keep this private is to set up your own wallet from scratch and ensure that your wallet software (Sparrow) only connects to a private Electrum server (preferred self-hosted).
Awesome infos. You helped a ton ššŖ
Planning to spin um my own node soon (hardware is on the way). But i didnāt know that i have to set up a completely new seed then
Well, you donāt *have to* set up a new seed. Only if youāre concerned about privacy.
Iām pretty extreme on the seed security front. Personally, I advocate rolling oneās own seeds offline. That way you know for sure the entropy couldnāt have been known by anyone else. But like I said, this is an extreme position. If you use a passphrase with your hardware-wallet-generated seed youāre probably fine.
Iām also an advocate of multivendor multisig for similar reasons. But here again it increases the complexity of the setup.
Wow! Ton of information here indeed!
I mean. Using the XPUB to generate a watch-only wallet (for instance on Blockstream green) comes in handy I think. But indeedā¦ it āleaksā all your addresses to some software you donāt own. However, that software being open source is āsaferā?
If you donāt control the Electrum server you connect to, you canāt know what logging or monitoring theyāre using.
For example, they could be running a free and open source Electrum server implementation like Fulcrum, but put it behind a reverse proxy that logs all traffic.
The software running on your wallet and/or hardware signing device canāt protect you against a logging third-party server.
So if youāre running your own node and connect your wallet to electrs, you should be good to go then. Only problem is, I canāt run my node at the moment š
Thanks again for your huge help š
I thought through this and have another question:
When i set up a completely fresh keysore because i am afraid my xpub was leaked and then send the funds to the new keystore, arenāt they still trackable by the entity that knows the previous xpub? canāt they just link the transaction to the new adress? š¤
Most likely yesā¦ I mean, with logical thinking people could assume that youāre sending it to a new wallet you still own
From the public blockchain perspective, the viewer knows that the coins got sent to a new address, but not that that address belongs to the same entity as the sender. They may infer this, but they canāt know it for sure.
Also, while the viewer knows all the addresses from the previous wallet, at most they can infer one address of the new wallet. Every transaction after that is a mystery. So IMO, youāre better off, even if all you do is shift to a new wallet with a keystore you rolled yourself.
There are other things you can do to mildly improve privacy on chain, such as avoiding exact values in either fiat or Bitcoin terms. Avoiding payments of, say $100 exactly or 0.001 BTC etc.
On-chain privacy is its own field of study. People who are serious about it use CoinJoins to obfuscate UTXO history. Sparrow implemented support for Whirlpool, the backend to Samuraiās CoinJoin implementation, but I havenāt tried it.
Personally, I would say that rolling your own seeds and connecting to your own node is more important.
I see. Thanks for the good explanation šš«š
I heard about coinjoins but i havenāt tried it yet because i also heard of people having trouble sending their btc to exchanges after a coinjoin. Not that i plan to cash out, i know what i have, but maybe someday i want to exchange a bigger amount to buy a house.
