search

BitcoinDesign / Guide

A free, open-source community resource for designers, developers and others working on non-custodial bitcoin products.
https://bitcoin.design/guide/
Other
450 stars 97 forks source link

Revise ⚡ to `Case Studies` > `Shared account` #618

Closed pavlenex closed 2 years ago

sbddesign commented 2 years ago

Perhaps this page needs Lightning content?

A common real-world use case for shared accounts are couples managing their monthly spending, with both parties being able to spend from the account ... The other person does not need to co-sign every transaction, but we might want a spending limit, above which both parties need to approve the transaction.

So you could imagine a situation where the two people can make small daily purchases over Lightning on their own, but need to consult each other before making a larger payment.

I'm not sure about having more than one private key responsible for one side of a Lightning channel. (Would it work? Has it been implemented?)

Is this the kind of content we should save for a later date?

GBKS commented 2 years ago

I don't think multi-sig on Lightning is possible, is it? @johnsBeharry do you maybe know?

sbddesign commented 2 years ago

I think it's absolutely possible in a theoretical sense. Lightning signer lists "multi-party signing" in their project roadmap. But just being theoretically possible doesn't mean it's been implemented yet.

moneyball commented 2 years ago

Once LN is upgraded to support taproot (Schnorr), then multi-sig will be possible in the sense that the tapscript used won't know if the single signature is 1 or more keys. If something like musig2 is used then N-of-N could be supported and something like FROST is used then K-of-N could be supported. Perhaps this is possible within a year...we'll see.

GBKS commented 2 years ago

Created a PR for this with a single note that multi-key on Lightning is still in development. See #632.