From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Erik Aronesty <erik@q32•com>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
Anthony Towns <aj@erisian•com.au>
Subject: Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`
Date: Fri, 18 Feb 2022 14:48:38 +0000 [thread overview]
Message-ID: <mSBTc8Bl5YIXe7LSX_fCNUYhd0wjepa_XhF6uhtwzF7s5h9-AEGWbkfrPA58nn431SjAqTkWEzd7YJ5mC0M7aZf-NmS5eDTN8LKEGQOFGcY=@protonmail.com> (raw)
In-Reply-To: <CAJowKg+cK3ZjPCjcDK8v5qFA=uCHD7gcR8ymroXBFicU5jzY8Q@mail.gmail.com>
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 prev parent reply other threads:[~2022-02-18 14:48 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-18 2:45 ZmnSCPxj
2022-02-18 13:53 ` Erik Aronesty
2022-02-18 14:48 ` ZmnSCPxj [this message]
2022-02-18 15:50 ` Erik Aronesty
2022-02-18 16:06 ` ZmnSCPxj
2022-02-18 13:55 ` Jonas Nick
2022-02-18 18:09 ` Antoine Riard
2022-02-18 23:39 ` ZmnSCPxj
2022-02-19 0:56 ` Jeremy Rubin
2022-02-19 1:17 ` ZmnSCPxj
2022-02-19 1:46 ` Greg Sanders
2022-02-19 7:21 ` Billy Tetrud
2022-02-19 11:41 ` ZmnSCPxj
2022-02-19 21:59 ` Billy Tetrud
2022-02-22 0:17 ` Antoine Riard
2022-02-23 11:42 ` ZmnSCPxj
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='mSBTc8Bl5YIXe7LSX_fCNUYhd0wjepa_XhF6uhtwzF7s5h9-AEGWbkfrPA58nn431SjAqTkWEzd7YJ5mC0M7aZf-NmS5eDTN8LKEGQOFGcY=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=erik@q32$(echo .)com \
/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