1 out of 2 multi sig setup scenario with hidden public keys

[Michiel]

Suppose I have a 1 out of 2 multi sig setup, which seed A in location A, seed B in location B and the public keys stored in location C.
question 1: If seed A is leaked, is it true the attacker still can't access the funds because he doesn't know the public key related to seed B?

question 2: Would this setup be safer compared to having one seed into two places?

question 3: Can the attacker extract info if the seed is part of a multi sig setup?

question 4: With the 1 out of 2 multi sig setup, can I put some small funds on addresses related to the seed in single sig setup, so the attacker would think he got bait, but in fact he only gained access to the small funds and not the full fund?

[AB de Royse777]

Since it is 1 of 2 means one key is enough to move funds. There are no point to have a 1 of x wallet.

[Michiel]

Since it is 1 of 2 means one key is enough to move funds. There are no point to have a 1 of x wallet.

You can move funds without knowing both public keys and with only one private key (seed)?

When I create a multi sig wallet with Electrum, it's showing the following warning:
"Warning: to be able to restore a multisig wallet, you should include the master public key for each cosigner in all of your backups."
This suggest you cannot send funds with ONLY one private key (seed). Am I reading this wrong?

[alexeyneu]

you've read this right. wallet has a single cosigner. either you or that guy can perform this duty

[AB de Royse777]

Since it is 1 of 2 means one key is enough to move funds. There are no point to have a 1 of x wallet.

You can move funds without knowing both public keys and with only one private key (seed)?

When I create a multi sig wallet with Electrum, it's showing the following warning:
"Warning: to be able to restore a multisig wallet, you should include the master public key for each cosigner in all of your backups."
This suggest you cannot send funds with ONLY one private key (seed). Am I reading this wrong?

To restore the wallet you need one key and both public key but to move funds you do not need more than one key.

[Michiel]

you've read this right. wallet has a single cosigner. either you or that guy can perform this duty

Sorry, it's not 100% clear for me. If that other guy doesn't have both public keys, can he still transfer the funds?

To restore the wallet you need one key and both public key but to move funds you do not need more than one key.

Sorry, it's not clear yet for me. I'm trying to ask questions which could be answered with yes or no, but your answer is confusing me. Without both public keys, it's not possible to move funds (question 1)?

I understand, if you have both public keys and have one private key, you can move the funds, but that's not what my confusion is about.

[LoyceV]

Suppose I have a 1 out of 2 multi sig setup, which seed A in location A, seed B in location B and the public keys stored in location C.
question 1: If seed A is leaked, is it true the attacker still can't access the funds because he doesn't know the public key related to seed B?

As far as I know: yes. But, if the address has been used to send a transaction in the past, the public keys can be found on the blockchain already.

question 2: Would this setup be safer compared to having one seed into two places?

It depends on your threat model: safer from an attacker means an increased risk of losing access by yourself.

question 3: Can the attacker extract info if the seed is part of a multi sig setup?

See 1.

question 4: With the 1 out of 2 multi sig setup, can I put some small funds on addresses related to the seed in single sig setup, so the attacker would think he got bait, but in fact he only gained access to the small funds and not the full fund?

Yes. But isn't that what passphrases are for (by extending the seed phrase with a custom passphrase)?

[hosemary]

The purpose of having a 1 of 2 multi-signature wallet is that you can make transaction with with having access to 1 out of 2 backups.
A 1 of 2 multi-signature wallet with such setup works like a 2 of 3 multi-signature wallet. Because, you have three backups and you need two of them for making transaction. So, why not go for a 2 of 3 multi-signature wallet?

[alexeyneu]

these pubkeys may only have something to do with redeemscript (which you'll not have with electrum anyway). anyone who knows private key and wallet address(which you wont know from that private key) can do createrawtx , signrawtx , then broadcast it .

https://bitcoin.stackexchange.com/a/51366

[apogio]

question 4: With the 1 out of 2 multi sig setup, can I put some small funds on addresses related to the seed in single sig setup, so the attacker would think he got bait, but in fact he only gained access to the small funds and not the full fund?

Please, do it, but pray that if they try to compromise your wallets, they 'll do it without you being there.

It's such a violent act, being tied up in a room, forced to reveal your wallets. (see here for incidents like this: https://github.com/jlopp/physical-bitcoin-attacks/blob/master/README.md)

Unfortunately, the attackers that know what bitcoin wallets are, are not ignorant anymore.

They 'll know your trick, they 'll be prepared for it.

[alexeyneu]

in your plan they already know you have big cash that's why they came. how i understand  you have no plans to be involved in firefight or so means you'll take a hot shower (law and disorder in jo-burg) so you'll have somewhat new mindset you know

[nc50lc]

these pubkeys may only have something to do with redeemscript (which you'll not have with electrum anyway). anyone who knows private key and wallet address(which you wont know from that private key) can do createrawtx , signrawtx , then broadcast it .

https://bitcoin.stackexchange.com/a/51366

The redeem script may not be displayed in Electrum,
but the information to produce it on demand is saved in the wallet file since it's required to be included to the signed raw transaction.
A client/wallet will not be able to sign by having only the private key of a single signer without the redeem script or cosigner's public key to reproduce it.

In the link's instructions, the redeem script is saved in the wallet after using "addmultisigaddress" command.
That enables it to sign using "signrawtx" without adding the redeem script, otherwise (if the wallet just contains the private key via importprivkey), it will fail to sign.

The key point is written in the "Details" part below that post.

But I agree that it's not recommended to use 1-of-2 MultiSig.

[alexeyneu]

it's required to be included to the signed raw transaction.
A client/wallet will not be able to sign by having only the private key of a single signer without the redeem script or cosigner's public key to reproduce it.

no, it doesn't.
it'll be able.



think for yourself if it's true or not checking the replies.

https://github.com/bitcoinjs/bitcoinjs-lib/issues/1034

[nc50lc]

it's required to be included to the signed raw transaction.
A client/wallet will not be able to sign by having only the private key of a single signer without the redeem script or cosigner's public key to reproduce it.

no, it doesn't.
it'll be able.

https://github.com/bitcoinjs/bitcoinjs-lib/issues/1034

That reference doesn't even support your reply since they're trying to add the redeem script.
The issue is in OP's raw transaction created by his code which was fixed by a series of replies including the last.
If you're talking about the replies about "coinb.in" that can include it, it's because for P2SH, the redeem script is the first requirement to create a transaction there.
If inputs are manually included, the redeem script should be manually provided.

Here's a reference:
The redeem script is required as stated in BIP16 (P2SH) standard: https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#specification
As per number 2 in its rules, its hash needs to match the hash in the outpoint's sciptPubkey for validation to succeed.

[Michiel]

@LoyceV
Thank you for your answers.

RE Q1:
I understand the public key will be available on the blockchain if transactions are already done, but how does the attacker know which transaction? The public key of a seed differs if it's part of a multi sig wallet or a single sig wallet right?
RE Q2:
Safer from an attacker
RE Q4: That's also an option, but passphrases can be forgotten. I'm not saying this setup is a good idea, I just want to know the details and make a good decision.

@alexeyneu
I'll read that stack exchange page. Thanks.

@hosseinimr93
This is for a wallet with less funds and I want it to be able to manage it with max 2 wallets.

@apogio
Thanks for the link.

@alexeyneu
It's not a given attackers know how much you have.

@nc50lc
"A client/wallet will not be able to sign by having only the private key of a single signer without the redeem script or cosigner's public key to reproduce it."
Clear! It's essential to store the public key of each cosigner. If they are not leaked, the private key can't move funds.

[nc50lc]

@nc50lc
"A client/wallet will not be able to sign by having only the private key of a single signer without the redeem script or cosigner's public key to reproduce it."
Clear! It's essential to store the public key of each cosigner. If they are not leaked, the private key can't move funds.

Just to clarify, since you're using Electrum, you need the cosigner's 'Master Public Key' listed under "keystore" in your wallet info window (Menu: Wallet->Information).
The public keys leaked in your spend transactions' redeem script are for the specific MultiSig address used in the input, can't be used to your other addresses.

And to expand that quote, it's possible to generate a signature without the redeem script because the 'message hash' can be generated without it.
But (for example) an Electrum wallet that only contains the signer's private key without the pubkey of the cosigner will not try since the signed raw transaction has to include the redeem script for the transaction to be valid.
It can be tested by creating a sample 1-of-2 MultiSig Electrum wallet and restore one of the seed phrase as a standard Electrum wallet.
Despite having the correct private keys, it will not sign the (unsigned) PSBT provided by the MultiSig wallet.

In Bitcoin Core (legacy), you can test by using signrawtransactionwithkey and provide only the private key without the redeem script.
Or signrawtransactionwithwallet using a wallet containing only the private key imported via importprivkey without the redeem script from addmultisigaddress command.
Both will fail to sign the raw transaction.

[LoyceV]

I understand the public key will be available on the blockchain if transactions are already done, but how does the attacker know which transaction?

Maybe, maybe not. But are you willing to risk it? If it's a targeted attack, chances are they know your address. I'm no expert on multisig cryptography, but as far as I know they could just test every multisig public key ever used.

I'm not saying this setup is a good idea, I just want to know the details and make a good decision.

You're basically turning a 1-of-2 multisig into something where you need 2-of-3 locations to recover the funds. Why not use a 2-of-3 multisig the way it's intended, and add all public keys to each share?

Maybe I can add an option: have you seen "split mnemonic cards"? To me, this is a lot more intuitive than multisig (although I've never used it in practice).
Example:

Code:

Card 1: tiny XXXX fetch dash hint XXXX minute XXXX XXXX XXXX belt ship XXXX XXXX system XXXX globe engine type country chief filter muscle tray
Card 2: tiny knock XXXX dash hint ranch XXXX job inch chief XXXX XXXX manual liar system have XXXX XXXX type country chief XXXX XXXX tray
Card 3: XXXX knock fetch XXXX XXXX ranch minute job inch chief belt ship manual liar XXXX have globe engine XXXX XXXX XXXX filter muscle XXXX

This accomplishes exactly what you want: you need 2-of-3 locations to restore the private key, and if someone gets their hand on one share, I don't think brute-forcing 8 missing words is viable any time soon.

[Catenaccio]

Maybe I can add an option: have you seen "split mnemonic cards"? To me, this is a lot more intuitive than multisig (although I've never used it in practice).
Example:

Code:

Card 1: tiny XXXX fetch dash hint XXXX minute XXXX XXXX XXXX belt ship XXXX XXXX system XXXX globe engine type country chief filter muscle tray
Card 2: tiny knock XXXX dash hint ranch XXXX job inch chief XXXX XXXX manual liar system have XXXX XXXX type country chief XXXX XXXX tray
Card 3: XXXX knock fetch XXXX XXXX ranch minute job inch chief belt ship manual liar XXXX have globe engine XXXX XXXX XXXX filter muscle XXXX

This accomplishes exactly what you want: you need 2-of-3 locations to restore the private key, and if someone gets their hand on one share, I don't think brute-forcing 8 missing words is viable any time soon.

Seed splitting is a bad idea according to Antonopoulos.
Bitcoin Q&A: Why is Seed Splitting a Bad Idea?
It is hard if you don't have full mnemonic seed to recover your wallet later and it's possible issue with seed splitting.

How to Back Up a Seed Phrase

[LoyceV]

Seed splitting is a bad idea according to Antonopoulos.
Bitcoin Q&A: Why is Seed Splitting a Bad Idea?

I don't have time for a 10 minutes video (what happened to just writing text?), can you give a summary?

It is hard if you don't have full mnemonic seed to recover your wallet

If you don't have your full multisig it's hard too

[Michiel]

...

Thanks for the clarification. This confirms my assumptions.

I don't have time for a 10 minutes video (what happened to just writing text?), can you give a summary?

Not a summary, but my own opinion: partially leaked seeds are vulnerable for brute forcing at some point in time. Shamir's secret sharing can be used instead.

You're basically turning a 1-of-2 multisig into something where you need 2-of-3 locations to recover the funds. Why not use a 2-of-3 multisig the way it's intended, and add all public keys to each share?

That's a good question. A difference is that with 1-of-2 you don't need to deal with partially signed transactions, which might be a convenience with less experienced bitcoiners (like my heirs).