Is it possible to set up a 2 out of 3 multisig AND a separate '1 out of all'?

[PrivacyG]

As I was reading about some multisig setups, this curiosity came to my mind.

Say I have three secure, privately owned locations.  My house, my farm and my apartment.  I can now set up a 2 out of 3 multisig.

But say I also have a fourth, extra secure location, such as a bunker no one can find or enter, hidden deep in the Ocean.  In my bunker, knowing no one will ever access it, I could store an emergency backup for my Bitcoin that would not require going to two separate locations to grab the Keys.

I do know the most basic answer would be having two or even all three Keys in the bunker.  But I have this curiosity, is it possible at all to set up a fourth Key that acts as an 'universal' one?

[Antidote47k]

Technically it should be possible. Bitcoin scripting allows alternative spending conditions, you can construct and analyze bitcoin spending policies with Miniscrpt. You would end up with four keys, A, B, C and D. The first three being the multisig setup and Key D being the master override.
The policy would be something like:
- Either two keys of A, B and C must sign or
- Key D alone can authorize.

Code:

 
 (A ∧ B) ∨ (A ∧ C) ∨ (B ∧ C) ∨ D

In simpler terms (2-of-3 multisig) or (Key D).

I think Taproot also offers another alternative, a single key spending path alongside a script path that enforces multisig.
Personally, I feel the setup defeats the whole aim of a multisig, which is needing more than a single key to authorize spending. If Key D were ever to be compromised then the multisig protection becomes null and void!

[Karl_3000]

I do know the most basic answer would be having two or even all three Keys in the bunker.  But I have this curiosity, is it possible at all to set up a fourth Key that acts as an 'universal' one?

These backup are all universal:

Seed phrase A, Seed phrase B, Master public key C
Seed phrase A, Seed phrase C, Master public key B
Seed phrase B, Seed phrase C, Master public key A

You can use any of the three as the fourth backup which can be used to get access to your bitcoin on the 2 of 3 multisig wallet.

Having two seed phrases of the multisig wallet and the third would be the master public key of there third seed phrase.

This is where I saw it: https://bitcointalk.org/index.php?topic=5595963.msg67210236#msg67210236

[Zaguru12]

I do know the most basic answer would be having two or even all three Keys in the bunker.  But I have this curiosity, is it possible at all to set up a fourth Key that acts as an 'universal' one?

I am confident that this is a possible where one key actually overrides the other co signers, I have read about Decaying multi sig before where over time one of the keys can be able to sign transactions alone, while this is different from your setup I think you can look into mini scripts too where you write a custom scripts about spending the wallet like you want, i don’t know if Sparrow wallet has actually started to support miniscripts descriptors[1].

Or better still uses something like a weighted multisig of 2-of-4 multi sig where the fourth seed phrase has two keys that can simply be able to sign the transaction although different from what electrum multi sig wallet with trustedcoin as co signer offers but it’s same.

My trade off though is that there is a single point of failure which is the fourth seed phrase and any one holding getting access to it can easily override the other co signed and technically this isn’t a genuine Multi sig wallet to be me.

Plus you would need to proper back up the public keys and the exact redeem scripts to generate the right addresses because the fourth key alone cannot do that for you.

[1]. Add support for miniscript descriptors

These backup are all universal:

This not what the OP intends, this is indeed a standard back up for 2-of-3 multi sig but OP wants to use a fourth key to be able act as a single sig and sign the transaction without needing the other co signers and not lookin for a universal back up actually

[nc50lc]

But say I also have a fourth, extra secure location, such as a bunker no one can find or enter, hidden deep in the Ocean.  In my bunker, knowing no one will ever access it, I could store an emergency backup for my Bitcoin that would not require going to two separate locations to grab the Keys.

Isn't storing two seeds and one extended public key in that bunker enough for that use-case?
Examples in Karl's reply.

While it's possible with OP_IF, OP_ELSE and OP_ENDIF scripts with CHECKMULTISIG and CHECKSIG as the two options.
Adding a single-sig option would defeat the purpose of the whole setup.

[ABCbits]

i don’t know if Sparrow wallet has actually started to support miniscripts descriptors[1].

[1]. Add support for miniscript descriptors

Most likely no. If craigraw or other developer/contributor have started adding miniscript support, they would comment on that issue or at least mention that issue as reason why they work on it. So as stated by the one who create that GitHub issue, you need to use either nunchuk, Bitcoin Core or Liana. Although looking at https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md, Bitcoin Core is probably least user-friendly option.

[ercewubam]

is it possible at all to set up a fourth Key that acts as an 'universal' one?

Yes, for example:

Code:

OP_IF
  <bunkerKey> OP_CHECKSIG
OP_ELSE
  2 <firstKey> <secondKey> <thirdKey> 3 OP_CHECKMULTISIG
OP_ENDIF

Translating it to example opcodes:

Code:

decodescript 632102c97d38ea1aaa4255d3099c8246769786c1bee5cc1e6a77a0887e3d951370ed7cac67522103a23de4741e786742a90880307462e5f565cae79a6d7dde88276385272c5c8b3321025e202dfb049a31e086e0f048961a3bb5c915703da942e4f187f08fad885d72542103e8b2761c54a1ff5a81334420cf6bbe217633fefb5036f002fcfb4d2b5e95555153ae68
{
  "asm": "OP_IF 02c97d38ea1aaa4255d3099c8246769786c1bee5cc1e6a77a0887e3d951370ed7c OP_CHECKSIG OP_ELSE 2 03a23de4741e786742a90880307462e5f565cae79a6d7dde88276385272c5c8b33 025e202dfb049a31e086e0f048961a3bb5c915703da942e4f187f08fad885d7254 03e8b2761c54a1ff5a81334420cf6bbe217633fefb5036f002fcfb4d2b5e955551 3 OP_CHECKMULTISIG OP_ENDIF",
  "desc": "raw(632102c97d38ea1aaa4255d3099c8246769786c1bee5cc1e6a77a0887e3d951370ed7cac67522103a23de4741e786742a90880307462e5f565cae79a6d7dde88276385272c5c8b3321025e202dfb049a31e086e0f048961a3bb5c915703da942e4f187f08fad885d72542103e8b2761c54a1ff5a81334420cf6bbe217633fefb5036f002fcfb4d2b5e95555153ae68)#95hd75yv",
  "type": "nonstandard",
  "p2sh": "2N1zCctJEuiNfJcjHr95DAu7PcoMmNqQWCJ",
  "segwit": {
    "asm": "0 ae7bfe26e1033b5c1cbf1b8bd0ba3168a8541c48030c73d43c65ea659116ebec",
    "desc": "wsh(or_i(pk(02c97d38ea1aaa4255d3099c8246769786c1bee5cc1e6a77a0887e3d951370ed7c),multi(2,03a23de4741e786742a90880307462e5f565cae79a6d7dde88276385272c5c8b33,025e202dfb049a31e086e0f048961a3bb5c915703da942e4f187f08fad885d7254,03e8b2761c54a1ff5a81334420cf6bbe217633fefb5036f002fcfb4d2b5e955551)))#ntn9sszf",
    "hex": "0020ae7bfe26e1033b5c1cbf1b8bd0ba3168a8541c48030c73d43c65ea659116ebec",
    "address": "tb1q4ealufhpqva4c89lrw9apw33dz59g8zgqvx884puvh4xtygka0kq6sdtfr",
    "type": "witness_v0_scripthash",
    "p2sh-segwit": "2NAeLEj1TdCgabjrXMsur4EQQ1z1s1CNxwi"
  }
}

And then, you can test address tb1q4ealufhpqva4c89lrw9apw33dz59g8zgqvx884puvh4xtygka0kq6sdtfr (or similar, with your keys), if you can move test coins from here.

Edit: You can analyze these examples:

Spending by a single "bunker" key: https://mempool.space/signet/tx/1f44edd2663a0b7492f092cd83a41aa4083462837066cdffde31da9e19302ed2?showDetails=true#vin=0
Spending by 2-of-3 multisig: https://mempool.space/signet/tx/b7b08e914cc7112d533b4e6c690ba1997c735cfafb83293d19aa838481ed3dd7?showDetails=true#vin=0

Edit:

I do know the most basic answer would be having two or even all three Keys in the bunker.

I don't know if it is an upside or downside for you, but in this way, "bunker usage" would look exactly like a regular usage. Depending on your use case, you may want to know, which key signed which coins, or you can try to hide it. In the same way 1-of-N multisig can be always achieved by having a single key, and sending it to all N parties. However, then you don't know, which key signed the message.

In my example above, you always explicitly know, if coins were spent by a "bunker key", or not. Also, you may want to add more or less restrictions between the bunker, and the rest of the keys, for example timelock.

[BlackHatCoiner]

Bitcoin is programmable, and as explained above by ercewubam, it is possible to construct a script that would require the condition to either use one key, or several if the one fails, to be true to spend, however in practice, this is not recommended because it is not standard and no wallet has implemented it.

If this is a hypothetical question, then yes, you can play with scripts. You can construct even more complicated scripts such as those where the second layers, such as those lightning and Ark rely on. However, if you're thinking of putting real money into this, I strongly recommend you avoid playing with matches, and just place all M keys into the bunker.

[Mia Chloe]

~snip

Is there a need to actually do that? Alternatively you can just store more than one key in that bunker since the end goal is to ensure that the bunker can access the seed without having to to visit any of the other locations.

Basically you have the option to store keys A&B or A&C or B&C or even all 3 keys too in the bunker and it sounds logical though since from your illustration so far the bunker is actually the safest possible location.

~snip

I wouldn’t risk my holdings on a new script either.

[ercewubam]

it is not standard

It is standard, if it is wrapped in P2WSH or P2TR. Only for P2SH or raw scripts it is non-standard.

no wallet has implemented it

Well, Bitcoin Core can handle it. And you don't need the whole chain to sign it, you only need to know, where your coins are, what amounts are in use, and where you want to send your coins. Then, "signrawtransactionwithwallet" can handle it, through descriptors, and you don't have to manually calculate z-value for your transaction.

However, if you're thinking of putting real money into this, I strongly recommend you avoid playing with matches, and just place all M keys into the bunker.

That's why we have testnets, to check things, before deploying them into production. If you can handle test coins correctly, then you should be able to handle mainnet coins as well. Also, if you want to test it on mainnet, then you can always set allowed fees to zero, disconnect, and check, if your transaction will be accepted by your own node. Then, the rest of the network won't see your transaction, but you will get more confidence, that your coins are spendable, if your own node will accept it, and include into produced block template.

Is there a need to actually do that?

Why not? The scripting language was invented to allow custom contracts like that. If everyone would stick with only well-known and standardized scripts, then we wouldn't need Script at all. We could instead allow only well-tested ways of handling coins, and introduce every new use case through yet another soft-fork. But Satoshi decided, that this approach is too limited, and invented Script instead.

I wouldn’t risk my holdings on a new script either.

At the time of writing, someone put 0.18890000 BTC on a P2WSH with OP_CODESEPARATOR, see bc1qqe0mf9qd47cvsxhpz470456ed6gppax7rx9rdyjdwvynwzettznqsv48l4. I guess there are more Bitcoin Core users than I anticipated, because I don't know any other wallet, which would handle scripts like that correctly.

[Zaguru12]

~snip

I wouldn’t risk my holdings on a new script either.

Nobody will advice anyone to holding on a new script, I do think this is an hypothetical question and nothing more because there are better and more convenient options for the OP like the one you highlighted.

But if OP is still interested in having this custom spending option then he can build the Script and simply test by sending in small amount and also sending out for testing to confirm if script is correct.

[Mia Chloe]

I wouldn’t risk my holdings on a new script either.

At the time of writing, someone put 0.18890000 BTC on a P2WSH with OP_CODESEPARATOR, see bc1qqe0mf9qd47cvsxhpz470456ed6gppax7rx9rdyjdwvynwzettznqsv48l4. I guess there are more Bitcoin Core users than I anticipated, because I don't know any other wallet, which would handle scripts like that correctly.

There’s a big margin between an OG bitcoiner and a new age bitcoiner. If that particular user has over 100 bitcoins and decides to do that he’s only taking a risk with a minimum fraction of of what he has. It’s a different case from have all your holdings there.

I bet you he wouldn’t risk the approximately 99.82 on a script if that’s all he has. There’s definitely a technical work around but a logical solution is still worth considering first.

[ercewubam]

Nobody will advice anyone to holding on a new script

You define using P2WSH as "new"? It exists since 2017. And in P2TR, experimenting with Script is even easier, because you can always spend all coins by a single key, and skip the whole TapScript, even if it is invalid, as long as your private key to the on-chain-revealed external public key is valid.

Also, I gave at least two ways, to play it safe: one is to use testnet first, and another one is to send a self-transfer to your own node with zero fees, from a wallet, which is disconnected from the network.

Another thing is you can see a perfectly standard descriptor, shown by "decodescript", which is:

Code:

wsh(or_i(pk(02c97d38ea1aaa4255d3099c8246769786c1bee5cc1e6a77a0887e3d951370ed7c),multi(2,03a23de4741e786742a90880307462e5f565cae79a6d7dde88276385272c5c8b33,025e202dfb049a31e086e0f048961a3bb5c915703da942e4f187f08fad885d7254,03e8b2761c54a1ff5a81334420cf6bbe217633fefb5036f002fcfb4d2b5e955551)))#ntn9sszf

If it would be not recognized by Core, you would see "addr(...)" instead.

It’s a different case from have all your holdings there.

It is up to the user, how many coins should be sent. As long as we don't have opcodes, which explore the transaction, and check the amount, existing scripts can work in a similar way, no matter if you put 0.01 BTC or 1000 satoshis on it. We don't have OP_AMOUNT, which would be valid in one case, and invalid in another.