358 sats \ 6 replies \ @suidoc OP 27 Oct 2022 freebie \ parent \ on: The feeling of being self-sovereign bitcoin
I am still in the process of deciding the best strategy. What I've done so far is basically just generating 3 different keys and engraved it into 3 different metal cards.
As I see it, I have a couple of options, but I would love to hear anyones elses opinion on what would be safest.
#1 Making use of a third party like Casa or Unchained Capital. As I see it, there is a lot of benefits of using a third party custodial like one of those, as they can help on the technical side of the stuff, in case I decide to provide the last key to my wife, kid or other trusted family/friend.
A small drawdown is that it is still a relatively new space, so who knows how these custodials will be in the future and whether they could have their keys seized. This would not have a huge impact, only in the case one of the other 2 keys are lost - which has to happen rather simultaneously.
#2 Only make use of trusted family members or friends. I like this option, but at the same time I am also a bit in doubt of the attack surface. Anyone who would know my whereabouts would be able to make a coordinated attack on obtaining the keys from myself, and the relatives having the keys. However, this also somewhat applies to the first option.
Another drawdown to option #2 is it also comes with a great responsibility of the family member and/or friend. Losing the key could wipe out all the savings in case this is not communicated and quickly fixed by moving the sats to a new key.
#3 Last option I can think of is keeping all 3 keys, but in different places (bank deposits, vault at home, somewhere in the woods etc.) and let my relatives (kid and wife) know about one of the places, while having a friend or paid third party knowing of another key (like in a bank vault).
I haven't decided which of the 3 options to go with, as they all have their pros and cons, so I would love to hear what thoughts you may have.
The custodial key does have many practical benefits as you mention, another of the drawbacks though is that every signer will also know your balance and history of transactions. So you lose some privacy..
This is definitely a hot topic that deserves more discussion.
In creating your multisig, what was the cost of the transaction? Was it significantly more than a regular (single-sig) transaction?
reply
I did not think about the privacy part and I believe that to be a very real concern. We see from time to time major companies having their data compromised and essentially if your single key gets in the hand of other people, they would be able to track all of your transactions - and not just the ones you make moving forward but every single transaction from the past too. Thank you for that point!
The transaction to the multisig costed me 158 sats while sending from my multisig costed me 368 sats, so it is quite a jump in fees (x2.3 increase). These may vary as I get more UTXOs unto the wallet. But I think the benefits are worth the extra costs as the base costs is quite low as long as you don't send small amounts at a time.
reply
368 sats? Are you sure? Maybe you meant 3680 sats?
Are you handling the saving / sharing of the metadata (signing data) yourself, or does your multi-sig app handle it for you?
As I understand, you need to have the details of ALL the signators to enable each signature
reply
I do indeed mean 368 sats - have you experienced higher costs?
Right now I am in possession of all 3 keys of my 2 of 3 multisig, so I am signing the transaction myself. I ran a similar transaction on testnet before setting up on mainnet. Here the fees are 200 sats.
https://mempool.space/testnet/tx/be7cd5c8dfd905c40fbe352901c1d1e48ce6fa529b2b346f8a5664467efa3e00
With a 2 of 3 multisig wallet you would only need 2 of the 3 keys to succesfully sign a transaction.
reply
Wow! On-chain transactions are super cheap right now!
reply
Well it depends on how much you want to pay pr. byte. Since I am moving sats between savings, I would never pay more than 1sat/byte.
reply