Multi-sig vs single-sig wallets for future unknowns

[kcage1]

Hi folks, this is a very specific questions about multi-sig (2of2) vs single-sig.  I believe this was already asked, but not answered. Let’s imagine a future scenario where randomly generating a single-sig wallet is much easier and faster than today, or that there’s a yet unknown/undicovered bug that makes it explaoitable and in a matter of a few years or a decade, one could stumble upon single-sig wallets with ease.
I would like to understand if having a 2of2 would mitigate this, simply by the fact that one would not only have to generate/guess 2 keys instead of one, but those exact 2 keys. My quetions is specifically if in such an event, having a multi-sig could prevent coin acess unless the atacker can find those exact two keys. AFAIK, it’s not like multi-sig is a one biger key, it’s in fact 2 independent keys one would need to find, those exact two. Is this the case?

[Charles-Tim]

For online wallets, multisig wallet is better than single signature wallet because of security and coin safety reasons. If you know how to backup your seed phrase and also using the multisig in a way that you can not lose your coins, it is better than single signature wallet. I prefer 2-of-3. I have two mobile devices and a laptop which can be used for it. But 2-of-2 is also safer than single signature wallet.

[Churchillvv]

AFAIK, it's impossible to guess the exact 12 words of a wallet. But in the future scenario that you speculated it might be possible for a bug to be found in future for a single-sig wallet because everything usually gets weak as time goes on even the most secured wallet might not be secured in future that's how time evolution works but for now it's very impossible to find the 12/24 matching mnemonic seed phrase of a wallet. That's why a multi-sig wallet is very much safer than a single Sig wallet.

Perhaps this question has been answer several times and if you're new to the forum you wouldn't know if it's has been answered or not but if you're saying other wise then you are still very wrong.

[Charles-Tim]

It is worth adding that the problem single signature wallets can have pertaining to bitcoin and not wallet owners mistakes is when the 128 bits of security that it has can be compromised. Anything that can compromise the 128 bits security will also compromise multisig wallets because the private keys of each wallets have not more than 128 bits of security. In this regard, bugs are not what that are talked about but super computers that can be able to generate computational powers that can compromise the 128 bits of security within a reasonably short period of time. The 128 bits security is still safe as of now. But if need be to do something if it is no more safe, bitcoin developers will have someone to do about it.

[kcage1]

Perhaps this question has been answer several times and if you're new to the forum you wouldn't know if it's has been answered or not but if you're saying other wise then you are still very wrong.

Thank for chiming in! Yes, I'm new,  it may have been answered. I'll do another search. I am talking more specifically about the answer to the questions that: Would the attack have to generate/guess 2 keys instead of one, and moreover those exact 2 keys. Does it work in this way and would a 2of2 it help?

[Upgrade00]

Would the attack have to generate/guess 2 keys instead of one, and moreover those exact 2 keys. Does it work in this way and would a 2of2 it help?

Yes. If an attacker is trying to brute force their way into a wallet they will need both keys in a 2 of 2 wallet to sign a transaction from it. Hypothetically, yes it would help in this situation.

Change happens gradually. If there is any major change that renders single key wallet addresses vulnerable to attacks it will develop gradually as all technology does and there will be ample time to completely do away with single keys and make at least 2 of 2 or 2 of 3 wallets the default. Or we can opt for increasing the bits of entropy, for now 12 words is enough cause it isn't realistically possible to brute force. If that becomes possible there are higher bits that can be adopted to offer more security.

[Zaguru12]

Thank for chiming in! Yes, I'm new,  it may have been answered. I'll do another search. I am talking more specifically about the answer to the questions that: Would the attack have to generate/guess 2 keys instead of one, and moreover those exact 2 keys. Does it work in this way and would a 2of2 it help?

I think I get your question that Should there be a scenario that private keys and seed phrases are been brute force due to computational power what role will a multi sig play. It is same as now, the multi sig will still be safer than the single sig because the attacker will need to actually brute force two keys or seed phrases to get access to the wallet. Where the security for mult sig will come is the attacker will have to look for the private key or seed phrase that actually co-signs for the wallet before they will be able to brute force it which is another layer of security than the single sig.

The only exception will be if the seed phrase brute force contains two master private key needed to spend from the wallet just like the seed phrase of a 2FA electrum wallet when deactivated. This way the attacker needs to only brute force only one seed phrase.

[kcage1]

Thank for chiming in! Yes, I'm new,  it may have been answered. I'll do another search. I am talking more specifically about the answer to the questions that: Would the attack have to generate/guess 2 keys instead of one, and moreover those exact 2 keys. Does it work in this way and would a 2of2 it help?

The only exception will be if the seed phrase brute force contains two master private key needed to spend from the wallet just like the seed phrase of a 2FA electrum wallet when deactivated. This way the attacker needs to only brute force only one seed phrase.

Yes, you that was the essence of my question. Can you please explain this last part more in detail? I dind't quite understand the exception. Thank you!

[ranochigo]

In short, there is no reason for someone to choose MultiSig over P2WPKH because it would be insecure in the future; they are somewhat providing the same level of security. To answer that, you have to understand what makes up a valid transaction. Some of the responses above are strictly assuming that the redeem script can become vulnerable if and only if addresses can easily be cracked, but that is hardly a concern at all.

Given that we've already established pre-image of 160bit hashes to be difficult and infeasible, there is really no reason why you would care about the security of the individual keys. If you were to get an attack, a pre-image of your hash would be used to attack rather than exhausting the entire key space of your keys. For P2WSH, it would be 256bits and P2PWKH is 160 bits, which is not a sufficient security increase. While on the topic, even if you use more keys in your locking script, your security level assumes the security of your hash of your redeem script; used to generate your address.

Any rational attacker would not bruteforce individual seeds because it would be too inefficient, but finding the pre-images of hashes that would hash to the different addresses would naturally be more efficient. There is also no reason to believe that there would be flaws in the cryptography that we're using; it won't be cracked overnight and marginal speedups would be more reasonable.

[pooya87]

Let’s imagine a future scenario where randomly generating a single-sig wallet is much easier and faster than today,

It is already as easy and fast as it can be. Not to mention that the steps for generating a multi-sig wallet is the same as a single-sig wallet but with more steps. Meaning the former is always slower but not slow enough to be noticeable (we are talking about fraction of a second).

or that there’s a yet unknown/undicovered bug that makes it explaoitable and in a matter of a few years or a decade, one could stumble upon single-sig wallets with ease.

That would mean the cryptography used by Bitcoin is broken and in such a scenario it doesn't matter how protected YOUR coins are because unless the algorithm is replaced, your coins won't be worth anything.

I would like to understand if having a 2of2 would mitigate this, simply by the fact that one would not only have to generate/guess 2 keys instead of one, but those exact 2 keys.

If by "guess" you mean a scenario where you can brute force keys or solve ECDLP within reasonable time, then there is no reason to believe multiple keys can not be broken as well.

My quetions is specifically if in such an event, having a multi-sig could prevent coin acess unless the atacker can find those exact two keys. AFAIK, it’s not like multi-sig is a one biger key, it’s in fact 2 independent keys one would need to find, those exact two. Is this the case?

Theoretically 2 keys makes it 2 times harder but as I said if breaking one key became possible, breaking 2 keys is also possible. And at the same time Bitcoin as a whole becomes worthless so it won't matter if your coins are safe or not.

[satscraper]

Main reason to use multisig is to mitigate the threat to wallet caused either by compromised device and/or potential backdoor in firmware/release in its cosigners. The likelihood that such bad stuff  could happen simultaneously    with all cosigners is equal to the product of relevant probability for each single cosigner.

[nc50lc]

Let’s imagine a future scenario where randomly generating a single-sig wallet is much easier and faster than today, or that there’s a yet unknown/undicovered bug that makes it explaoitable and in a matter of a few years or a decade, one could stumble upon single-sig wallets with ease.
I would like to understand if having a 2of2 would mitigate this, simply by the fact that one would not only have to generate/guess 2 keys instead of one, but those exact 2 keys.

I think I understand what you're thinking when you asked this;
Since MultiSig's "redeemscript" isn't public until you spend any of its UTXO, the bruteforce attacker wont have any idea which "exact 2 keys" to use to spend your MultiSig output(s).

It makes sense in some degree but if it's easy to count 2^256 in that theoretical future, (humans are traveling across the galaxy by then I assume)
I won't be surprised if generating a redeemscript with a hash that matches the hash in your scriptPubKey will be relatively easy as well.
The attacker wont even have to guess your private keys.

As for the Bug scenario, it's not specified aside from "stumbling upon single sig wallets" so there's no telling if using MultiSig will be safe from it.

[vjudeu]

It makes sense in some degree but if it's easy to count 2^256 in that theoretical future

1. You have to count only to 2^128 to break a given public key.
2. If you have P2SH, then knowing the hash requires counting to 2^160.
3. If you are one of the party in P2SH, then you have to count only to 2^80.
4. You can use raw multisig, then it is not wrapped in any hash, like in P2SH, which means, there are no shortcuts for hash collisions.

[kcage1]

Thank you all, learned somehting in the process. I'm trying to summarize and conclude: The term "pre-image" refers to the original input data that undergoes hashing to generate a fixed-size output, known as a hash. Essentially, a pre-image is the initial value fed into a hash function, while the hash denotes the output generated by the function.
In comparison, P2PWKH (predominantly used in single-sig) is generally perceived as more secure than P2WSH (predominantly used in multi-sig) due to its simplified script, hashed public key, reduced script complexity, enhanced script verification, and increased resistance to replay attacks. Nonetheless, each script possesses distinct advantages and limitations, and selecting between them is just a matter of one's particular use case and requirements.

Would splitting coins into multiple single-sig wallets may be more secure than having all on one multi-sig? For example splitting my coins into 10 single-sig wallets vs all in one multi-sig?

[ranochigo]

Would splitting coins into multiple single-sig wallets may be more secure than having all on one multi-sig? For example splitting my coins into 10 single-sig wallets vs all in one multi-sig?

Depends on how you think the security can be weakened. If you think that a random hacker cannot exhaustively search the key space and can randomly stumble upon your private key, then splitting it into 10 would be the better idea. If you think that the vulnerability would affect each of the addresses and their key pair, then neither would be effective.

The chances of it happening is exceedingly low. Maintaining 10 separate seeds and addresses is too much of a hassle to justify any possible security improvement, for which there is practically close to none. Most people confidently keeps their funds without any splitting whatsoever.

[nc50lc]

It makes sense in some degree but if it's easy to count 2^256 in that theoretical future

1. You have to count only to 2^128 to break a given public key.

OP's original question is actually naïve and haven't considered those attacks.
It's easy to spot that with the main question anyways.

He talking about blind bruteforce by saying "stumble upon" not an ECDLP attack on the public key.
So in his scenario, every address, even those that aren't used to spend yet.

4. You can use raw multisig, then it is not wrapped in any hash, like in P2SH, which means, there are no shortcuts for hash collisions.

No one uses that these days and practically, OP isn't talking about bare MultiSig even if it's not mentioned since modern clients do not use that anymore.

[larry_vw_1955]

4. You can use raw multisig, then it is not wrapped in any hash, like in P2SH, which means, there are no shortcuts for hash collisions.

i never heard of "raw multisig" before. it must be expensive. but it's probably worth it.

because it sounds like OP wants to double the difficulty of hacking a single bitcoin address. you can't do that with P2SH multisig apparently.

[vjudeu]

No one uses that these days and practically, OP isn't talking about bare MultiSig even if it's not mentioned since modern clients do not use that anymore.

https://blockchair.com/bitcoin/outputs?s=time(desc)&q=type(multisig)#f=transaction_hash,index,time,value,value_usd,recipient,is_spent,spending_transaction_hash,spending_time,spending_value_usd,cdd,type

And of course, Bitcoin Core can still support raw multisig. In the same way, you could say that "nobody uses P2PK", but in practice, all standard address types are active: https://blockchair.com/bitcoin/outputs?s=time(desc)&q=type(pubkey)#f=transaction_hash,index,time,value,value_usd,recipient,is_spent,spending_transaction_hash,spending_time,spending_value_usd,cdd,type

And of course, there were even some proposals to make those transactions non-standard, but so far, they didn't succeed: https://github.com/bitcoin/bitcoin/pull/28217

i never heard of "raw multisig" before.

Huh? You never heard of that, and you created a topic, when you explicitly said about "legacy bitcoin multisig"? https://bitcointalk.org/index.php?topic=5350872

Did you have OP_CHECKMULTISIG behind some hash in mind, and never thought, that it can be directly used inside scriptPubKey?

BIP-11 introducing OP_CHECKMULTISIG as a standard transaction type, up to three keys: https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki

it must be expensive

It depends, how do you count bytes. Because if you use OP_CHECKMULTISIG, that is wrapped behind any hash, then it is more expensive, if you count the full cost of handling that (sending and receiving). But of course, it can be cheaper, if you are only on one of those sides (and for example only spend from 1-of-20 raw multisig, or only send to some 160-bit hash).

But yes, in general, OP_CHECKMULTISIG is expensive. It has at least O(n^2) complexity, and it can be linearized and simplified, if you replace it with OP_CHECKSIG, used several times, or if you express it as a bunch of Schnorr signatures, using some combined public keys instead.

but it's probably worth it

It is not. If someone can break a single key, then breaking more keys is not that much harder, especially if they are related, and were generated from the same deterministic wallet. Also note, that even if your coins, behind some 20-of-20 multisig, would be somehow safer, then everyone else's coins wouldn't be, so if the majority of the coins will be stolen, then your coins will be worthless anyway, if the whole economy will be destroyed.

Also, you already received the answer to that question in the old topic, mentioned above:

Any M of N multisig is only as secure as the N-Mth most secure key in it.  Same is true for a fake-multisig as it is for a true threshold signature.

[nc50lc]

No one uses that these days and practically, OP isn't talking about bare MultiSig even if it's not mentioned since modern clients do not use that anymore.

https://blockchair.com/bitcoin/outputs?s=time(desc)&q=type(multisig)#f=transaction_hash,index,time,value,value_usd,recipient,is_spent,spending_transaction_hash,spending_time,spending_value_usd,cdd,type

And of course, Bitcoin Core can still support raw multisig. In the same way, you could say that "nobody uses P2PK", but in practice, all standard address types are active -snip-

When I said "no one uses" that doesn't mean it's now non-standard, more like "deprecated".
Of course Bitcoin Core supports old scripts, its wallet just doesn't generate those by default.
And arguably, most of those transactions are probably for "something else" rather than actual utility since almost all txns in the list just created dust P2MS outputs.

Let me nickpic as well, P2MS and P2PK aren't "address types" 

[larry_vw_1955]

i never heard of "raw multisig" before.

Huh? You never heard of that, and you created a topic, when you explicitly said about "legacy bitcoin multisig"? https://bitcointalk.org/index.php?topic=5350872

i know about that topic but that was about using OP_CHECKMULTISIG with P2SH.

Did you have OP_CHECKMULTISIG behind some hash in mind, and never thought, that it can be directly used inside scriptPubKey?

i'm not sure what you mean exactly.

BIP-11 introducing OP_CHECKMULTISIG as a standard transaction type, up to three keys: https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki

it can go up to 15 compressed keys apparently. not just 3.

It is not. If someone can break a single key, then breaking more keys is not that much harder, especially if they are related, and were generated from the same deterministic wallet.

so first of all why would parties use keys from the same deterministic wallet as private keys for their multisig wallet. that wouldn't really make much sense.

Also, you already received the answer to that question in the old topic, mentioned above:

Any M of N multisig is only as secure as the N-Mth most secure key in it.  Same is true for a fake-multisig as it is for a true threshold signature.

think of it like this. for a true threshhold signature it just takes more work to compute all the private keys from their public keys. instead of doing it one time, you have to do it M times. so it's M times the amount of work. i just need to look into how the raw multisig works because i've never heard of it before really.