pull down to refresh
6 sats \ 1 reply \ @meduzot 15h \ on: ShowSN: multisigbackup.com - Recover your 2-of-3 multisig with only 2 seeds bitcoin
First of all, kudos for the novel idea to do this because it is a legitimate problem. I'm torn that you're using OP_RETURN because normally I think it should be used very sparingly but this might be a use case that is deserving. However, I feel this doesn't scale and is ultimately the wrong approach.
You mentioned the SeedHammer project but they're actually using the Uniform Resources standard which need not be stamped onto metal. So in a multisig setup where you store each private key (in whatever medium) you should also store the descriptor in UR format to allow for proper recovery (and aide privacy).
I think the bigger issue here is that the backup procedure of wallets should also include the descriptor (and for multisig in UR) in addition to the seed. This seems to be a cultural change though.
Thanks for the support. I see this first and foremost as a solution to a UX problem. A whole ecosystem already exists guiding users through the process of creating and backing up seeds, either on paper or on metal. Asking an already cautious user to back up additional data offline doesn't make for the best user experience and adds additional risk, where none needs to exist. Why go through the hassle when your descriptor can be inscribed once and forgotten about? A third party provider could even do this behind the scenes during setup, making for a more seamless user experience.
People are rightfully weary of applications that involve inscribing data on Bitcoin, either because they congest the network or because they get priced out when fee rates go up. In this case, the data is directly related to the security of user's funds, and the actual amount of data is small. The cost of inscribing is the same as making ~4 taproot transactions, so if you can afford a multisig, you can probably afford to inscribe your descriptor.
I should clarify that the data is inscribed in a taproot witness, not in a OP_RETURN output. The difference is minor, since I create the reveal transaction with a single OP_RETURN output, which avoids bloating the UTXO set. Meanwhile, we benefit from the witness discount and avoid the 80 byte OP_RETURN limit.
reply