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 <a...@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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
