Quote from: vjudeu on Today at 05:48:43 AM

Quote

Password Recovery

When it comes to any puzzles, there is for example this puzzle: https://bitcointalk.org/index.php?topic=5469657.0

And then, people may think, that SHA-1 was used, to create them, and make TapScripts, unspendable by key:

Code:

1) OP_SHA1 <3045ae6fc8422f64ed579528d38120eae12196d5> OP_EQUAL
2) OP_SHA1 <bd71344799d5c7fcdc45b59fa3b9ab8f6a948bc5> OP_EQUAL
3) OP_SHA1 <c49d360886e704936a6678e1139d26b7819f7e90> OP_EQUAL
4) OP_SHA1 <a335926aa319a27a1d00896a6773a4827acdac73> OP_EQUAL
5) OP_SHA1 <d09e8800291cb85396cc6717393284aaa0da64ba> OP_EQUAL

Imagine, how the person solving that would feel, if it would turn out, that those coins are unspendable, because of the wrong endianness.

So, instead of using unspendable key-path, it can be just "multisig behind all interested parties". It is possible to start with a single key, just like the creator of the famous puzzle, where keys #120 and #125 are sweeped, but nobody knows, if those keys are really broken, or if the author just moved those funds.

And if you have any kind of reward, then by using multisig, you can start with a single key, and then move those coins by key, to combine the same rewards into bigger coins. Which means, if Alice and Bob sent funds to some different keys, with the same attached TapScript, then they could move them to a multisig, and a TapScript. And that move may be more attractive to the puzzle solver, because having single coin is cheaper to move, than having thousands of small deposits (not to mention address reuse, which is a bad practice, and should be avoided).

Quote

Recursive Covenants + Trustless peg-in/peg-out for layer 2s

If you have more than one person, behind some coin, then it may be possible, that all of them will be online. In that case, there is no reason to use expensive TapScript path, and reveal the whole covenant on-chain. The group, which wants to be detached, can just propose a withdrawal transaction, and collect all signatures from all parties, and then it will look the same, as if everything would be owned by a single user.

To sum up: I cannot see a reason, why not to use multisig. If you are alone, then it gives you a chance to experiment with TapScript, without trapping your coins in unspendable paths. If there are at least two people (for example: Alice tells Bob that she will pay for Password Recovery), then, 2-of-2 multisig is applicable. If there are more than two people, then N-of-N multisig is applicable in a general case.

And then, for example if Bob cannot provide the password, Alice can say: "well, you tried cracking it for 10 years, and you failed, it is now useless information for me, so I sweep my funds, you don't have to work longer on that". And if Bob agrees, then it is at least possible for Alice to get her funds back. But if it is behind TapScript-only, then it may be unspendable forever. Also, there are obvious mistakes possible, for example wrong endianness, and then, key-path can be used to fix those cases, instead of losing coins forever.

Quote from: vjudeu on Today at 05:48:43 AM

So, instead of using unspendable key-path, it can be just "multisig behind all interested parties".

Totally agree!
I think the rule of thumb is: use a multisig if you know the interested parties ahead of time, otherwise use NUMS.
For the example of the puzzle/hash cracking, one may have to spend a significant portion of time/compute to crack the hash, so if they original challenge holder can just transfer away the funds at will, it may be a disincentive to commit resources to the problem.

In the case of the layer 2, I would push back, however. To be secure, the multisig should be controlled by the owners of layer 2 wrapped BTC so they can reclaim the BTC on Layer 1 back whenever they like. This is impossible if the layer 2 BTC is transferrable.

Consider the following scenario:
3 bitcoin holders each bridge 10 BTC to layer 2, locking a total of 30 BTC in a multisig (lets call the set of keys in the multisig K), minting a total 30 l2BTC on the layer 2. Since the K should proportionally represent owners of l2BTC, they should each control a key in the multisig. The 3 original users then purchase NFTs on the L2 with their l2BTC on an L2-DEX, spending all 30 BTC. Now the original set K does not represent the token holders and is instead controlled by a group which owns no l2BTC.