Erik Aronesty [ARCHIVE] on Nostr: 📅 Original date posted:2022-02-18 📝 Original message:> As I understand your ...
📅 Original date posted:2022-02-18
📝 Original message:> As I understand your counterproposal, it would require publishing one
transaction per evicted participant.
if you also pre-sign (N-2, N-3, etc), you can avoid this
> In addition, each participant has to store `N!` possible orderings in
which participants can be evicted, as you cannot predict the future and
cannot predict which partiicpants will go offline first.
why would the ordering matter? these are unordered pre commitments to move
funds, right? you agree post the one that represents "everyone that's
offline"
> But yes, certainly that can work, just as pre-signed transactions can be
used instead of `OP_CTV`
i don't see how multiple users can securely share a channel (allowing
massive additional scaling with lighting) without op_ctv
On Fri, Feb 18, 2022 at 9:48 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Erik,
>
> > hey, i read that whole thing, but i'm confused as to why it's necessary
> >
> > seems like N of N participants can pre-sign an on-chain transfer of
> funds for each participant to a new address that consists of (N-1) or (N-1)
> participants, of which each portion of the signature is encrypted for the
> same (N-1) participants
> >
> > then any (N-1) subset of participants can collude publish that
> transaction at any time to remove any other member from the pool
> >
> > all of the set up (dkg for N-1), and transfer (encryption of partial
> sigs) is done offchain, and online with the participants that are online
>
>
> As I understand your counterproposal, it would require publishing one
> transaction per evicted participant.
> In addition, each participant has to store `N!` possible orderings in
> which participants can be evicted, as you cannot predict the future and
> cannot predict which partiicpants will go offline first.
>
> Finally, please see also the other thread on lightning-dev:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003479.html
> In this thread, I point out that if we ever use channel factories, it
> would be best if we treat each channel as a 2-of-2 that participates in an
> overall N-of-N (i.e. the N in the outer channel factory is composed of
> 2-of-2).
> For example, instead of the channel factory being signed by participants
> `A`, `B`, `C`, `D`, instead the channel factory is signed by `AB`, `AC`,
> `AD`, `BC`, `BD`, `CD`, so that if e.g. participant B needs to be evicted,
> we can evict the signers `AB`, `BC`, and `BD`.
> This means that for the channel factory case, already the number of
> "participants" is quadratic on the number of *actual* participants, which
> greatly increases the number of transactions that need to be evicted in
> one-eviction-at-a-time schemes (which is how I understand your proposal) as
> well as increasing the `N!` number of signatures that need to be exchanged
> during setup.
>
>
> But yes, certainly that can work, just as pre-signed transactions can be
> used instead of `OP_CTV` or pretty much any non-`OP_CHECKMULTISIG` opcode,
> xref Smart Contracts Unchained.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220218/6b0a0376/attachment.html>;
📝 Original message:> As I understand your counterproposal, it would require publishing one
transaction per evicted participant.
if you also pre-sign (N-2, N-3, etc), you can avoid this
> In addition, each participant has to store `N!` possible orderings in
which participants can be evicted, as you cannot predict the future and
cannot predict which partiicpants will go offline first.
why would the ordering matter? these are unordered pre commitments to move
funds, right? you agree post the one that represents "everyone that's
offline"
> But yes, certainly that can work, just as pre-signed transactions can be
used instead of `OP_CTV`
i don't see how multiple users can securely share a channel (allowing
massive additional scaling with lighting) without op_ctv
On Fri, Feb 18, 2022 at 9:48 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Erik,
>
> > hey, i read that whole thing, but i'm confused as to why it's necessary
> >
> > seems like N of N participants can pre-sign an on-chain transfer of
> funds for each participant to a new address that consists of (N-1) or (N-1)
> participants, of which each portion of the signature is encrypted for the
> same (N-1) participants
> >
> > then any (N-1) subset of participants can collude publish that
> transaction at any time to remove any other member from the pool
> >
> > all of the set up (dkg for N-1), and transfer (encryption of partial
> sigs) is done offchain, and online with the participants that are online
>
>
> As I understand your counterproposal, it would require publishing one
> transaction per evicted participant.
> In addition, each participant has to store `N!` possible orderings in
> which participants can be evicted, as you cannot predict the future and
> cannot predict which partiicpants will go offline first.
>
> Finally, please see also the other thread on lightning-dev:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003479.html
> In this thread, I point out that if we ever use channel factories, it
> would be best if we treat each channel as a 2-of-2 that participates in an
> overall N-of-N (i.e. the N in the outer channel factory is composed of
> 2-of-2).
> For example, instead of the channel factory being signed by participants
> `A`, `B`, `C`, `D`, instead the channel factory is signed by `AB`, `AC`,
> `AD`, `BC`, `BD`, `CD`, so that if e.g. participant B needs to be evicted,
> we can evict the signers `AB`, `BC`, and `BD`.
> This means that for the channel factory case, already the number of
> "participants" is quadratic on the number of *actual* participants, which
> greatly increases the number of transactions that need to be evicted in
> one-eviction-at-a-time schemes (which is how I understand your proposal) as
> well as increasing the `N!` number of signatures that need to be exchanged
> during setup.
>
>
> But yes, certainly that can work, just as pre-signed transactions can be
> used instead of `OP_CTV` or pretty much any non-`OP_CHECKMULTISIG` opcode,
> xref Smart Contracts Unchained.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220218/6b0a0376/attachment.html>;