Topic: schnorr signature weakness, why did they do it this way? - page 2. (Read 501 times)

It affects multisig, where multiple entities are involved. By birthday paradox, the attacker can run through 2^80 combinations of their public keys with the other party's public key and produce a collision. The victim would be left in the dark, which is why we've pre-emptively introduced SHA256 with P2WSH.

Not really. The conditions are only required provided that the redeem script that you're providing in the transaction states so. If I were to somehow give a redeem script which hashes out to the corresponding hash in the UTXO, then the conditions in that redeem script is considered for unlocking those outputs. For example, if I were to somehow have a redeem script which is a 2-of-3 Multisig and its hash somehow is the same as another completely different P2SH with differing requirements, then by fulfilling the former redeem script requirements, I can spend the outputs tied to the latter P2SH script.

It is a totally hypothetical and incredibly unlikely scenario, but it proves that for a specific P2SH, we can define an alternative script to bypass the requirements in the first place completely.

Well congratulations you just summed up what true multisignature is. But you call it "fake". Not sure why. Multisignature needs as you said "a bunch of regular signatures", in fact it needs M of them. And then it also needs to apply "logic after the fact" as you also pointed out, to figure out that out of the N public keys that M of the signatures belong to N of those public keys. I think that's really the only way you could really ensure that M of the N private keys were used. There's no other way.


I'm assuming when you say collisions you mean hash collissions? never thought of that. so i guess even the legacy multisig is no more secure than a single public key. that's the problem with multisig in general is it works but u can't be sure there's not another way to spend the funds other than YOUR way which is the m of n private keys. until they get something like that, i guess it's not true multisig ever. kind of disappointing that bitcoin has this limitation of such a small address space what is it 2^160?

well actually i guess here's another question though, just because you have a multisig address that starts with 3 I'm not sure how someone would go about finding a script that would hash to that. wouldn't it be harder than just finding a private key for a bitcoin address that starts with a 1? how would you even know something exists that hashes to the thing that starts with 3 other than the script you created it with? and then even if you could do that would it be recognized as a valid script by the network? it seems like it would be really hard not sure how hard though. but probably alot harder than brute forcing a single btc 1 address.

[moderator's note: consecutive posts merged]

That is extremely vague. Do you expect a useful reply?  Your non-question post seems like a fake question.

In reality the old checkmultisig is the fake multisignature:  It's not a true multisignature but one faked by just having a bunch of regular signatures and applying some logic after the fact.

You can still use that kind of explicit fake multisig if you want to, but but it's inefficient.  M*32 bytes + N*64 bytes ... instead of just 32+64 bytes. You can also do other variants with different tradeoffs.  Like a tree of N choose M leaves (size 32*ceil(log2(n choose m))) plus a M of M signature (size 32+64).


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.

Legacy Bitcoin multisig is more vulnerable to collisions being able to defraud the other parties. Not practical currently but might be in the future, which is why P2WSH came with a larger collision resistance. So, not really as secure as you think it is.

For the security proofs, I've linked it in the post in your other thread a few hours ago.

First of all, Schnorr signatures do not require that multisigs must use key aggregation. You can still have a traditional multisig where keys are listed explicitly and each key has a signature. There's nothing that prevents that. Specifically with Taproot, OP_CHECKMULTISIG was replaced with OP_CHECKSIGADD because it is much more efficient. Taproot also allows for more keys to be in the multisig and OP_CHECKSIGADD allows very large multisigs to be efficiently verified.

Furthermore, Schnorr signature merely allow key and signature aggregation schemes to work. This is just a property of the algorithm. There is no required method for key aggregated multisigs. There are many different ways you could do key aggregation; some are unsafe and some are safe (with rigorous mathematical proofs to back them up).

It still requires multiple signatures to be spent.
The single public key that is revealed and used for verification doesn't have a known private key and it can not be guessed or computed which means there is no weakness here.

 i think the legacy bitcoin multisig actually require m of n signatures because it checks each signature. schnorr doesn't.  it just checks the aggregated public key. seem like a fake multisig.