Let me introduce you to my good friend, the ideal gas law. https://en.wikipedia.org/wiki/Ideal_gas_law

You could DM yourself. That would let you save encrypted notes that link out to other notes.

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.

Thanks everyone for confirming! Back online 💪

BTCPayServer

My node had been stuck synching. Could someone send me a small test zap to confirm it’s working again?

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).

Sparrow is my favorite desktop wallet by a pretty large margin. Its philosophy is to show you what’s going on, in as user-friendly a way as possible. It’s not going to hide things from you if it can help it.

Either should work. You can copy the file directly from ~/.sparrow, IIRC, or export in Sparrow format.

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.

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.

Right. When you create a New Wallet in Sparrow, it doesn’t initially know anything about what keystores you intend to use to generate addresses and sign transactions.

If you intend to make a new seed, I believe Sparrow calls this a Software keystore. It can generate 12 or 24 word BIP-39 seed phrases for you, and will require you to record them and reenter them.

It’s possible, for example, to make a 2-of-2 where one keystore is your hardware wallet, and the other keystore is a Software keystore. This is kinda like a poor-man’s multivendor multisig. It would require both Sparrow and your hardware device to leak seed material for someone to compromise your coins.

No, absolutely not. Your hardware device’s one job is to protect the seed material while the device is in use. Leaking that seed to your computer would be a fundamental failure of its intended purpose.

What your wallet can report however is its XPUB and master key fingerprint (XFP) from which Sparrow can derive addresses and prepare transactions for signing.

I recommend “New Wallet” because it will make explicit what your keystore is and how it relates to the wallet proper.

Don’t be afraid of trying different options. As long as each produces the same sequence of addresses, then the wallets are identical and behave the same.

Sparrow calls hardware wallets “keystores”. So if you import a hardware wallet, what Sparrow will actually do is create a new, single-sig wallet with that hardware device as its only keystore.

Either path will yield the same outcome, which you can validate by doing both and comparing the generated addresses.

Import wallet is if you already have a wallet in a different format and want to make it into a full Sparrow wallet.

For example, you could make a 2-of-3 using entirely offline ColdCards. Then, on one of them, export the wallet to a microSD card. That text file basically contains only the XPUBs and master key fingerprints.

You can then import that file to Sparrow, which will set up its own internal storage for UTXO labels etc.

You can even mitigate the vendor attack vector by using multisig. As long as no vendor has quorum, you can be fairly sure you’re protected. It’s unlikely that multiple vendors will have vulnerabilities at the same time that are exploitable by the same party.

New Wallet. Then, in the new wallet settings, add your hardware wallet as a Keystore.

This guy gets it