From: Michael Folkson <michaelfolkson@protonmail•com>
To: Ali Sherief <ali@notatether•com>
Cc: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Transcript: Online Socratic on MuSig2
Date: Mon, 12 Sep 2022 16:00:52 +0000 [thread overview]
Message-ID: <EjQcONe5___52yZQzB5cSJfXjXB0S7fXT2FXo1NAD6F8h4kbbl-JZhu1C-4tZW2qxp7nMQJ9A08peU9U8FBrUc7DJDeCdJPJk-Rde9GaRak=@protonmail.com> (raw)
In-Reply-To: <ZSUlUBf8IO0xdA3QEaw8ytaD_2qTkfEa5vtU3t6F2OTMrOSOnrl1_Gy-zL75uhpJ3M5iWjVyeyImiCqW2c1F2xfllxyVTh8cd6ImFo0kYDk=@notatether.com>
[-- 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 --]
next prev parent reply other threads:[~2022-09-12 16:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-11 7:43 Ali Sherief
2022-09-12 16:00 ` Michael Folkson [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-09-08 11:19 Michael Folkson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='EjQcONe5___52yZQzB5cSJfXjXB0S7fXT2FXo1NAD6F8h4kbbl-JZhu1C-4tZW2qxp7nMQJ9A08peU9U8FBrUc7DJDeCdJPJk-Rde9GaRak=@protonmail.com' \
--to=michaelfolkson@protonmail$(echo .)com \
--cc=ali@notatether$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox