* Re: [bitcoin-dev] Transcript: Online Socratic on MuSig2
@ 2022-09-11 7:43 Ali Sherief
2022-09-12 16:00 ` Michael Folkson
0 siblings, 1 reply; 3+ messages in thread
From: Ali Sherief @ 2022-09-11 7:43 UTC (permalink / raw)
To: michaelfolkson; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 730 bytes --]
Hi Michael.
I read the transcript of the Socratic and I have to say that it is quite detailed and touches a lot of problems including the well-known theft/offline problems which also has forms elsewhere such as for passwords.
My question is, do you or anyone else in the Socratic know of any research to this that's don't involve a trade-off of theft or online connectivity?
ROAST and Liquid is perhaps the farthest I know of that addresses this problem, but it's using centralized nodes right now. I was thinking, maybe these federated nodes can be decentralized into a few of these "lite nodes" managed by each service wanting a payment, that make a threshold signature out of many subscribers paying at the same time.
- Ali
[-- Attachment #2: Type: text/html, Size: 905 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] Transcript: Online Socratic on MuSig2
2022-09-11 7:43 [bitcoin-dev] Transcript: Online Socratic on MuSig2 Ali Sherief
@ 2022-09-12 16:00 ` Michael Folkson
0 siblings, 0 replies; 3+ messages in thread
From: Michael Folkson @ 2022-09-12 16:00 UTC (permalink / raw)
To: Ali Sherief; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 3593 bytes --]
Hi Ali
> do you or anyone else in the Socratic know of any research to this that's don't involve a trade-off of theft or online connectivity?
Any generation of a signature(s), whether that be single key (e.g. OP_CHECKSIG), multisig with multiple signatures going onchain (e.g. OP_CHECKMULTISIG, OP_CHECKSIGADD) or key aggregation multisig with only a single signature going onchain (e.g. OP_CHECKSIG), requires private key(s) and hence has concerns with regards to security and theft of those private keys. Clearly funds locked behind any kind multisig arrangement is better than no multisig arrangement as otherwise theft of a single private key can result in loss of funds.
With regards to connectivity or interactivity key aggregation multisig does increase the interactivity requirements so if you wanted to minimize interactivity requirements you'd probably stick to OP_CHECKMULTISIG, OP_CHECKSIGADD that only requires you to generate a signature and then pass it onto the next signer.
> ROAST and Liquid is perhaps the farthest I know of that addresses this problem, but it's using centralized nodes right now. I was thinking, maybe these federated nodes can be decentralized into a few of these "lite nodes" managed by each service wanting a payment, that make a threshold signature out of many subscribers paying at the same time.
I'm not sure what you mean here. In the realm of generating signatures there isn't really a concept of a "lite node". That makes more sense in the realm of verification where you may or may not be doing full verification. In the generating signatures realm you are either contributing to the aggregated signature or generating a standalone signature yourself. If you are not doing either of those and aren't doing some kind of coordination then you are entirely irrelevant to the scheme. In the case of Liquid there is a 11-of-15 threshold signature arrangement where currently 11 signatures go onchain when funds are moved but if Liquid used a key aggregation scheme like FROST only a single signature would need to go onchain. With regards to centralization/decentralization you could increase the 11-of-15 to say a 22-of-30. Or you could have a nested MuSig/FROST scheme behind one of the 11 signers of the 11-of-15. But you can't get around the fact that you are either generating a signature that ultimately contributes to the moving of the funds or you aren't. If you aren't generating a signature then you are just verifying the signature(s) that go onchain like all other full nodes on the network.
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Sunday, September 11th, 2022 at 08:43, Ali Sherief <ali@notatether•com> wrote:
> Hi Michael.
>
> I read the transcript of the Socratic and I have to say that it is quite detailed and touches a lot of problems including the well-known theft/offline problems which also has forms elsewhere such as for passwords.
>
> My question is, do you or anyone else in the Socratic know of any research to this that's don't involve a trade-off of theft or online connectivity?
>
> ROAST and Liquid is perhaps the farthest I know of that addresses this problem, but it's using centralized nodes right now. I was thinking, maybe these federated nodes can be decentralized into a few of these "lite nodes" managed by each service wanting a payment, that make a threshold signature out of many subscribers paying at the same time.
>
> - Ali
[-- Attachment #2: Type: text/html, Size: 7214 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* [bitcoin-dev] Transcript: Online Socratic on MuSig2
@ 2022-09-08 11:19 Michael Folkson
0 siblings, 0 replies; 3+ messages in thread
From: Michael Folkson @ 2022-09-08 11:19 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]
Hi
We had an online Socratic on August 11th with Tim Ruffing (co-author of MuSig2 draft BIP) and Elizabeth Crites (co-author of research papers on MuSig(2), FROST). It was previously announced here [0] but ended up being rescheduled.
The transcript is here [1], the video is here [2] and a reading list collecting together a number of resources on MuSig(2), FROST, ROAST etc is here [3].
We discussed a retrospective look at BIP340, handling x-only public keys in MuSig2 and the proposed TLUV covenant opcode, the history from initially broken MuSig1 through MuSig-DN to MuSig2, how MuSig2 and FROST compare for multisig schemes (i.e. n-of-n), why MuSig2 doesn't use proofs of possession and the current state of the draft MuSig2 BIP.
We covered a lot of topics and it was rather long (~2.5 hours) so check out the transcript or video if you are interested in any of the above topics. Many thanks to those who participated.
Jonas Nick recently tweeted [4] that the MuSig2 BIP [5] is approaching a stable version 1.0 which should be helpful to those who are interested (or already!) using it in the wild.
[0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020772.html
[1]: https://btctranscripts.com/london-bitcoin-devs/2022-08-11-tim-ruffing-musig2/
[2]: https://www.youtube.com/watch?v=TpyK_ayKlj0
[3]: https://gist.github.com/michaelfolkson/5bfffa71a93426b57d518b09ebd0998c
[4}: https://twitter.com/n1ckler/status/1567168267025874944
[5]: https://github.com/jonasnick/bips/blob/musig2/bip-musig2.mediawiki
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
[-- Attachment #2: Type: text/html, Size: 5637 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-09-12 16:01 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-11 7:43 [bitcoin-dev] Transcript: Online Socratic on MuSig2 Ali Sherief
2022-09-12 16:00 ` Michael Folkson
-- strict thread matches above, loose matches on Subject: below --
2022-09-08 11:19 Michael Folkson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox