Those are exactly my concerns as well. Going redundant, i.e. adding more dead-man-switch-services, payed for a year in advance might make it better, but still, not ideal. But where is the difference to a service like Casa Hodl and Unchained Capitals multi-sig-service? It's still a 3rd party...

Does anybody know of more dead-man-switch services?

The seeds would be on paper with the hardware wallets in an envelope. I'm not too concerned about the seeds being encrypted, because if one location gets compromised, i.e. I realize the seal on the envelope has been broken, I have to create a new multi-sig-setup, rotating the compromised seed out.

Sorry for the confusion.


Here a little clearer, hopefully:

2-of-3 Multi-Sig-Setup Alice and Bob

Alice and Bob share the physical devices Trezor1, TrezorT and LedgerS.

But, Alice and Bob have different passphrases, in order to have different xpub's.

That means:

House: There's a Trezor1, its recovery seed and two passphrases, Passphrase_Alice and Passphrase_Bob.
Vacation Home: There's a Ledger, its recovery seed and two passphrases, Passphrase_Alice and Passphrase_Bob.
Safe Deposit Box: There's a TrezorT, its recovery seed and two passphrases, Passphrase_Alice and Passphrase_Bob.

The passphrases are per person the same across locations, but different for Alice and Bob, in order for them to have logically different wallets.

3-of-4

Too little redundancy, that's out.



3-of-5

Charlie creates the following wallets:

Trezor1 using its seed and the passphrase "Passphrase_Charlie" (substituted for an actual strong passphrase, of course)

TrezorT using its seed and the passphrase "Passphrase_Charlie" (same as with the Trezor1, but the seed is different, hence different wallet)

LedgerS using its seed and the passphrase "Passphrase_Charlie" (same as with the Trezor1, but the seed is different, hence different wallet)

Electrum_Seed_Brain: An Electrum wallet to which he remembers the seed, but also writes the seed on paper.

Electrum_Seed_GFM: Another Electrum wallet, but the seed is encrypted using Passphrase_GFM. It's intended to be sent out using GMail's scheduled sending and FinalMessage.io.

Additionally, he calculates the sha256sum of Electrum_Seed_Brain and uses that hex-string as the passphrase to encrypt the seed of TrezorT.


Locations:

Home:
  * Trezor1 and Passphrase_Charlie
  * Passphrase_GFM
  * encrypted TrezorT-Seed, using sha256sum of Electrum_Seed_Brain

Safe-Deposit-Box:
  * TrezorT, Passphrase_Charlie
  * Electrum_Seed_Brain.
  * Passphrase_GFM
So here are 2 of the 5 wallet seeds needed.

Vacation Home
  * LedgerS and Passphrase_Charlie
  * Passphrase_GFM
  * encrypted TrezorT-Seed, using sha256sum of Electrum_Seed_Brain

He then uploads the encrypted Electrum_Seed_GFM to FinalMessage.io and GMail.

And he remembers the seed to Electrum_Seed_Brain.

How can Charlie lose his bitcoins? Ideally, a 3-of-5 should survive the loss of 2 seeds.



If he loses:

Home & Safe-Deposit-Box: He still has vacation home, he hopes that FinalMessage.io and GMail deliver the encrypted seed of Electrum_Seed_GFM, so that's 2 and now he has to remember the brain-wallet Electrum_Seed_Brain, that's 3 out of 5. Actually it's 4, because with the brain-wallet he can recreate TrezorT of the now gone Safe-Deposit-Box too.

(Uppercase OR and AND are to be understood in the logical sense, not in the colloquial)

Dependency: He's dependent on (FinalMessage.io OR GMail) AND brain.



If he loses:

Home & Vacation-Home: He still has Safe-Deposit-Box, that's 2 seeds and now has to hope that FinalMessage.io OR Gmail delivers.

Dependency: Safe-Deposit-Box AND (FinalMessage OR Gmail). A little better than before, because at least he's not dependent on his brain.


If he loses:

Vacation-Home and Safe-Deposit-Box: Same as "Home & Safe-Deposit-Box".


If he loses:

Brain and Safe-Deposit-Box (i.e. death): Trezor1 at home, plus LedgerS in Vacation Home, plus FinalMessage OR Gmail.

Dependency: Home AND Vacation-Home AND (FinalMessage OR Gmail)


If he loses:

Brain and something else, except Safe-Deposit-Box (i.e. forgot brain-wallet): Trezor1 at Home, TrezorT in Safe-Deposit-Box, LedgerS in Vacation-Home, also Brain-Wallet backed up in Safe-Deposit-Box.

Dependency: Only physical locations.


If he loses:

FinalMessage.io and GMail (i.e. they don't deliver for whatever reason): Trezor1 at Home, LedgerS in Vacation-Home.

Now his relatives are fucked, if they don't get the content of the Safe-Deposit-Box.

This might be a problem.

Involved are 3 Bitcoin holding parties: Alice, Bob and Charlie.

Alice and Bob are considered to be one household, but for accounting purposes, still want separate wallets.

Charlie wants a separate wallet, but also doesn't want either Alice or Bob being able to spend his funds, in order to mitigate against 5-Dollar-wrench-attacks against them. Only after Charlie dies, he wants Alice and Bob to have access. He doesn't trust lawyers.


Secure physical locations:

 * H: Alice and Bob's [H]ouse, all 3 have access
 * V: [V]acation-home, all 3 have access
 * S: \[S\]afe-Deposit-Box, only Charlie has access


2-of-3 Multi-Sig-Setup Alice and Bob

 * H: Trezor1 + Passphrase_Alice + Passphrase_Bob
 * V: LedgerS + Passphrase_Alice + Passphrase_Bob
 * S: TrezorT + Passphrase_Alice + Passphrase_Bob
 


2-of-3 Multi-Sig-Setup Charlie

 * H: Trezor1 + encrypted Passphrase_Charlie
 * V: LedgerS + encrypted Passphrase_Charlie
 * S: TrezorT + plaintext Passphrase_Charlie + decryption passphrase for encrypted Passphrase_Charlie
 * FinalMessage.io GMail's delayed sending to Alice and Bob: Decryption passphrase for Passphrase_Charlie

OR


3-of-4 Multi-Sig-Setup Charlie

 * H: Trezor1 + Passphrase_Charlie
 * S: TrezorT + Passphrase_Charlie
 * V: LedgerS + Passphrase_Charlie
 * FinalMessage.io and GMail's delayed sending to Alice and Bob: Electrum Seed


OR

Since S and Charlie's brain B have a certain connection, they can backups of one another. If Charlie dies, S and B are inaccessible.

So alternativley:

3-of-5 Multi-Sig-Setup Charlie

* H: Trezor1 + Passphrase_Charlie
* S: TrezorT + Passphrase_Charlie + Electrum_Seed_Brain
* V: LedgerS + Passphrase_Charlie
* GMail & FinalMessage: Electrum_Seed_GFM
* Brain: Electrum_Seed_Brain

plus sha256sum of Electrum_Seed_Brain as a passphrase to encrypt content of S (TrezorT+Passphrase_Charlie) and storing this with H and V.

If Charlie dies: H+V+Gmail&FinalMessage

If Charlie forgets Electrum_Seed_Brain: Nothing really happens

If Safe Deposit Box gets nuked: H+V+Brain


What do you think? What's the best way forward? Or something completely different?

The idea was, that an attacker might rainbow-table the N shortest (as in number of characters) seeds. Like WarpWallet, the e-mail salt would mitigate any such broad attack which isn't specifically aimed at a particular person.

Is it general good practice to salt your Electrum seed with for example your e-mail address in the seed extension? Kind of like WarpWallet does?

I'm afraid that doesn't answer my question, tough.

How do you claim BZX, if you held BTC in your own wallet on the date of the snapshot?

You can add a custom password aka seed extension. If its entropy source is something like dice rolls and it's 128-bits of entropy strong or stronger, even with a bad RNG on the Trezor, your funds are secure.

Yes, definitely, I would have done the WarpWallet thing on an airgapped machine.

The thing is, every time I create a new seed, I also have to recreate and re-test all my backups. One of those backups is memorizing the seed. If this one is the last seed I have to memorize, that's great.

Thanks so much. This really calms my mind.

Of course. I always move them first. But they're still within the same xpriv.

Maybe in the future, I just create a new xpriv using the seed extension.

What do you think about this:

Using the example mnemonic: marine annual label breeze dice organ tunnel burst mad hand success author, which produces the xpriv

xprv9s21ZrQH143K2Hene3ragUxFzuqm84Juqy5HWqa7q9MHeKXDanZ74kTuA1h8voKgCPaimDAwhtN 6zSLrEMXwAVDZrCYjK9HJSMiYtonWKtc.

Then when the time comes, I use WarpWallet [1], using as input

marine annual label breeze dice organ tunnel burst mad hand success author-1

and the resulting private key 5KSE1...C7Zv7ts as seed extension, giving me the xpriv

xprv9s21ZrQH143K3uAeNvnfBTXpeaXj9VJ7UPSr5jnfEkB9KMhiFQmUtzPRPn3mqVLmzgjyDvJCtbW hFhyEm5D6MkgjaXRYRGHn5JEqF4Ss6Vc.

Then send everything over to the new wallet, claim the fork-coins, and repeat with appended -2 the next time I do something risky involving the xpriv.



[1] https://keybase.io/warp/warp_1.0.9_SHA256_a2067491ab582bde779f4505055807c2479354633a2216b22cf1e92d1a6e4a87.html

Yes, I would have used a seed extension.

What makes me question the one-way'ness of mnemonic > seed > xpriv are the functions mnemonic_encode and mnemonic_decode in https://github.com/spesmilo/electrum/blob/master/electrum/mnemonic.py.

If it's one-way, why can you freely en- and decode between the two?

But yea, mnemonic_to_seed does salt and hash the mnemonic.

The thing is, that with all the shitcoin-hardforks of bitcoin, you always have to handle individual private keys. And while I'm super caution to never let a private key and the master public key touch the same physical machine, I'm still paranoid. Especially about shitcoin clients, which may unannounced to me, leak the private key to a 3rd party, that then just waits for the corresponding xpub to emerge one day and cleans out my wallet.

I went for option B, and created a new seed.

Thanks

Hi,

can anyone describe to me, what the relationship between the 12 word seed in Electrum and the extended private key is?

If someone were to get the master private key, or the master public key PLUS one or more private keys, should I go for

Option A: simply add one word to the seed as a password, thus totally changing the master private key and have a secure wallet once again.

Or could an attacker calculate the seed from the master public key and thus trivially brute force the one additional word? Which would mean I should opt for

Option B: make a completely new seed.

Thanks in advance.

I would just send the bitcoins over to the new wallet and archive the schildbach-wallet-file.