Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 96AA1C000B for ; Sat, 19 Feb 2022 01:46:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 7ED3C83E83 for ; Sat, 19 Feb 2022 01:46:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MBsX_3k9ryk for ; Sat, 19 Feb 2022 01:46:19 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yw1-x112e.google.com (mail-yw1-x112e.google.com [IPv6:2607:f8b0:4864:20::112e]) by smtp1.osuosl.org (Postfix) with ESMTPS id 6857F826DE for ; Sat, 19 Feb 2022 01:46:19 +0000 (UTC) Received: by mail-yw1-x112e.google.com with SMTP id 00721157ae682-2d07ae0b1bfso84121037b3.6 for ; Fri, 18 Feb 2022 17:46:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=n/o/UlfappvxeZQgcdKJS9/WIJC+p0aVClWQM4iun0E=; b=avtNmB9n4d/z7CMwH/2PvV84oOqt015z0GW0cFaYj/XAL4vLF/m+Kd2xfl2z4kg3oO eeoQ3KLMt5tU2Ojwb0+LrjEhQ0dd29uR2LMZ2ULJhO/CrzItC9F5Ra1jEZogiYBBTOQT /KRdPXrr3dhxrO9DW5nDR0zxeAPC/MpE049wE1TU1liMPuK2tGa2p3Se9k/sw0k/MvW1 rJRr4m9W+k7GwBmRT++Za52kDpny79SwqKGTCDZ6jlEvJm6Q65dBfxuTSz0sfTG22QoF 920saBeP00nd7d0wrtx8kbryQKvq5o6blDmNoK3amE7ZNGNrzTCdVFQUR9oBAcdJuT6G JpKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=n/o/UlfappvxeZQgcdKJS9/WIJC+p0aVClWQM4iun0E=; b=Wcj0BoetOW6000doTlWE7QH1IK1BQn8hJ9AWRfTf4ENIVWD5z3i2SnC/4Ffrt9p0vf wqRfQbw+mCD3lrZkVeuzyOzb4zwIXGUWEIGI3otWLzGqPREc2ujWrAK+32eu66jOELFQ JbxzXHtmtvk1VU+ScZCJkNK1yD2bQu/n+pl78bOdEgVN+LsgEBobl3puXvifD0my4yvy XkIxao6D7UkwQidxvBnpXsU+PpbS8+PLcWAz1L7tm8JumDBl5kki+FzEWfBlRFTS1eKq L3xCD+5xS1+nrdgmczDeYhsdg1gPuKE+CKIFePzRZaI2KVaw7S67OKpwItO9K8YOqWyQ abGw== X-Gm-Message-State: AOAM530hWotOVnDet7Cu0nYLUjlo26mfj7RDYQVMaf7pwL2Dg0tpm2bT F2QJg/hdBlRi5oBZKmN3Uf/FIDqXpVzfUd8WCTD7laZnvBw= X-Google-Smtp-Source: ABdhPJy2g/vqU4MxywmaWWxciAiFN7AnGYKDEY+LQJH2CXuWCoPbygImSitc92KrLvpLpEQ3dFX72874nqUdE+7ceqQ= X-Received: by 2002:a0d:f844:0:b0:2d6:8761:8a2b with SMTP id i65-20020a0df844000000b002d687618a2bmr10743900ywf.403.1645235178241; Fri, 18 Feb 2022 17:46:18 -0800 (PST) MIME-Version: 1.0 References: <6nZ-SkxvJLrOCOIdUtLOsdnl94DoX_NHY0uwZ7sw78t24FQ33QJlJU95W7Sk1ja5EFic5a3yql14MLmSAYFZvLGBS4lDUJfr8ut9hdB7GD4=@protonmail.com> <0mhhHzTun8dpIcLda1CLFihMsgLoWQUEE8woKUKhf_UHYps2w7jVzbJAUJ302kQEB1ZdvMfakP9IBUHLM8bGns-pg0NHmpuak3yjpphjJnw=@protonmail.com> In-Reply-To: From: Greg Sanders Date: Sat, 19 Feb 2022 09:46:07 +0800 Message-ID: To: Jeremy Rubin , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000005f028f05d8552a3c" Subject: Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY` X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2022 01:46:21 -0000 --0000000000005f028f05d8552a3c Content-Type: text/plain; charset="UTF-8" > One point of discomfort I have with Eltoo that I think is not universal, but is shared by some others, is that non-punitive channels may not be good for high-value channels as you do want, especially in a congested blockspace world, punishments to incentivize correct behavior (otherwise cheating may look like a free option). Without derailing the conversation too far, "fully" punitive channels also make large value channels more dangerous from the perspective of bugs causing old states to be published. High value channels you'll need to have very high uptime. If you're available, your counterparty is incentivized to do a mutual close to reduce fees and remove timelocks on outputs. I think these tradeoffs will result in both types existing for N==2. On Sat, Feb 19, 2022 at 8:56 AM Jeremy Rubin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > This is a fascinating post and I'm still chewing on it. > > Chiming in with two points: > > Point 1, note with respect to evictions, revivals, CTV, TLUV: > > CTV enables 1 person to be evicted in O(log N) or one person to leave in > O(log N). TLUV enables 1 person to leave in O(1) O(log N) transactions, but > evictions take (AFAICT?) O(N) O(log N) transactions because the un-live > party stays in the pool. Hence OP_EVICT helps also make it so you can kick > someone out, rather than all having to leave, which is an improvement. > > CTV rejoins work as follows: > > suppose you have a pool with 1 failure, you need to do log N txns to evict > the failure, which creates R * log_R(N) outputs, which can then do a > transaction to rejoin. > > For example, suppose I had 64 people in a radix 4 tree. you'd have at the > top level 4 groups of 16, then 4 groups of 4 people, and then 1 to 4 txns. > Kicking 1 person out would make you do 3 txns, and create 12 outputs total. > A transaction spending the 11 outputs that are live would capture 63 people > back into the tree, and with CISA would not be terribly expensive. To be a > bit more economical, you might prefer to just join the 3 outputs with 16 > people in it, and yield 48 people in one pool. Alternatively, you can > lazily re-join if fees make it worth it/piggybacking another transaction, > or operate independently or try to find new, better, peers. > > Overall this is the type of application that necessitates *exact* byte > counting. Oftentimes things with CTV seem inefficient, but when you crunch > the numbers it turns out not to be so terrible. OP_EVICT seems promising in > this regard compared to TLUV or accumulators. > > Another option is to randomize the CTV trees with multiple outputs per > party (radix Q), then you need to do Q times the evictions, but you end up > with sub-pools that contain more people/fractional liquidity (this might > happen naturally if CTV Pools have channels in them, so it's good to model). > > > Point 2, on Eltoo: > > One point of discomfort I have with Eltoo that I think is not universal, > but is shared by some others, is that non-punitive channels may not be good > for high-value channels as you do want, especially in a congested > blockspace world, punishments to incentivize correct behavior (otherwise > cheating may look like a free option). > > Thus I'm reluctant to fully embrace designs which do not permit nested > traditional punitive channels in favor of Eltoo, when Eltoo might not have > product-market-fit for higher valued channels. > > If someone had a punitive-eltoo variant that would ameliorate this concern > almost entirely. > > Cheers, > > Jeremy > > > > -- > @JeremyRubin > > On Fri, Feb 18, 2022 at 3:40 PM ZmnSCPxj via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Good morning ariard, >> >> >> > > A statechain is really just a CoinPool hosted inside a >> > > Decker-Wattenhofer or Decker-Russell-Osuntokun construction. >> > >> > Note, to the best of my knowledge, how to use LN-Penalty in the context >> of multi-party construction is still an unsolved issue. If an invalidated >> state is published on-chain, how do you guarantee that the punished output >> value is distributed "fairly" among the "honest" set of users ? At least >> > where fairness is defined as a reasonable proportion of the balances >> they owned in the latest state. >> >> LN-Penalty I believe is what I call Poon-Dryja? >> >> Both Decker-Wattenhofer (has no common colloquial name) and >> Decker-Russell-Osuntokun ("eltoo") are safe with N > 2. >> The former has bad locktime tradeoffs in the unilateral close case, and >> the latter requires `SIGHASH_NOINPUT`/`SIGHASH_ANYPREVOUT`. >> >> >> > > In principle, a set of promised outputs, if the owners of those >> > > outputs are peers, does not have *any* inherent order. >> > > Thus, I started to think about a commitment scheme that does not >> > > impose any ordering during commitment. >> > >> > I think we should dissociate a) *outputs publication ordering* from the >> b) *spends paths ordering* itself. Even if to each spend path a output >> publication is attached, the ordering constraint might not present the same >> complexity. >> > >> > Under this distinction, are you sure that TLUV imposes an ordering on >> the output publication ? >> >> Yes, because TLUV is based on tapleaf revelation. >> Each participant gets its own unique tapleaf that lets that participant >> get evicted. >> >> In Taproot, the recommendation is to sort the hashes of each tapleaf >> before arranging them into a MAST that the Taproot address then commits to. >> This sort-by-hash *is* the arbitrary ordering I refer to when I say that >> TLUV imposes an arbitrary ordering. >> (actually the only requirement is that pairs of scripts are >> sorted-by-hash, but it is just easier to sort the whole array by hash.) >> >> To reveal a single participant in a TLUV-based CoinPool, you need to >> reveal O(log N) hashes. >> It is the O(log N) space consumption I want to avoid with `OP_EVICT`, and >> I believe the reason for that O(log N) revelation is due precisely to the >> arbitrary but necessary ordering. >> >> > > With `OP_TLUV`, however, it is possible to create an "N-of-N With >> > > Eviction" construction. >> > > When a participant in the N-of-N is offline, but the remaining >> > > participants want to advance the state of the construction, they >> > > instead evict the offline participant, creating a smaller N-of-N >> > > where *all* participants are online, and continue operating. >> > >> > I think we should dissociate two types of pool spends : a) eviction by >> the pool unanimity in case of irresponsive participants and b) unilateral >> withdrawal by a participant because of the liquidity allocation policy. I >> think the distinction is worthy, as the pool participant should be stable >> and the eviction not abused. >> > >> > I'm not sure if TLUV enables b), at least without transforming the >> unilateral withdrawal into an eviction. To ensure the TLUV operation is >> correct (spent leaf is removed, withdrawing participant point removed, >> etc), the script content must be inspected by *all* the participant. >> However, I believe >> > knowledge of this content effectively allows you to play it out against >> the pool at any time ? It's likely solvable at the price of a CHECKSIG. >> >> Indeed, that distinction is important. >> `OP_TLUV` (and `OP_EVICT`, which is just a redesigned `OP_TLUV`) supports >> (a) but not (b). >> >> > `OP_EVICT` >> > ---------- >> > >> > > * If it is `1` that simply means "use the Taproot internal >> > > pubkey", as is usual for `OP_CHECKSIG`. >> > >> > IIUC, this assumes the deployment of BIP118, where if the public key >> is a single byte 0x01, the internal pubkey is used >> > for verification. >> >> I thought it was part of Taproot? >> >> > >> > > * Output indices must not be duplicated, and indicated >> > > outputs must be SegWit v1 ("Taproot") outputs. >> > >> > I think public key duplication must not be verified. If a duplicated >> public key is present, the point is subtracted twice from the internal >> pubkey and therefore the aggregated >> > key remains unknown ? So it sounds to me safe against replay attacks. >> >> Ah, right. >> >> > > * The public key is the input point (i.e. stack top) >> > > **MINUS** all the public keys of the indicated outputs. >> > >> > Can you prevent eviction abuse where one counterparty threatens to >> evict everyone as all the output signatures are known among participants >> and free to sum ? (at least not considering fees) >> >> No, I considered onchain fees as the only mechanism to avoid eviction >> abuse. >> The individual-evict signatures commit to fixed quantities. >> The remaining change is then the only fund that can pay for onchain fees, >> so a single party evicting everyone else has to pay for the eviction of >> everyone else. >> >> >> > > Suppose however that B is offline. >> > > Then A, C, and D then decide to evict B. >> > > To do so, they create a transaction that has an output >> > > with "B := 6", and they reveal the `OP_EVICT` Tapscript >> > > as well as sign(b, "B := 6"). >> > > This lets them change state and spend their funds without >> > > B being online. >> > > And B remains secure, as they cannot evict B except using >> > > the pre-signed output, which B certifies as their expected >> > > promised output. >> > >> > I think in the context of (off-chain) payment pool, OP_EVICT requires >> participant cooperation *after* the state update to allow a single >> participant to withdraw her funds. >> >> How so? >> >> A single participant withdrawing their funds unilaterally can do so by >> evicting everyone else (and paying for those evictions, as sort of a >> "nuisance fee"). >> The signatures for each per-participant-eviction can be exchanged before >> the signature exchange for the Decker-Wattenhofer or >> Decker-Russell-Osuntokun. >> >> >> > > The combined fund cannot be spent except if all participants >> > > agree. >> > >> > If all participants agree minus the evicted ones, correct ? The output >> promises signatures are shared at state setup, therefore no additional >> contribution from the evicted participant (I think). >> >> Yes. >> >> > >> > > To prevent signature replay, each update of an updateable >> > > scheme like CoinPool et al should use a different pubkey >> > > for each participant for each state. >> > >> > I'm not even sure if it's required with OP_EVICT, as the publication of >> the promised output are ultimately restrained by a signature of the updated >> internal pubkey, this set of signers verify that promised output N does >> bind to the published state N ? >> >> If the internal pubkey is reused (for example, if all participants are >> online and want to change state cooperatively) then the component keys need >> to be re-tweaked each time. >> >> The tweaking can be done with non-hardened derivation. >> >> >> > > Its advantage is reduced number of eviction transactions, >> > > as multiple evictions, plus the revival of the CoinPool, >> > > can be put in a single transaction. >> > > It has the disadvantage relative to `OP_TLUV` of requiring >> > > point operations. >> > > I have not explored completely, but my instinct suggests >> > > that `OP_TLUV` use may require at least one signature >> > > validation anyway. >> > >> > I believe you can slightly modify TLUV to make it functional for >> CoinPool revival, where you want to prevent equivocation among the >> remaining set of signers. Though, I'm leaning to agree that you may require >> at least one signature validation (first to restrain spend authorization >> inside the pool participants, second to attach fees at broadcast-time). >> >> Yes, TLUV does have that advantage relative to CTV, and `OP_EVICT` is >> "just" a redesigned `OP_TLUV`. >> >> In particular, I first developed my thoughts on revivable constructs with >> eviction of participants here: >> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003479.html >> >> >> Regards, >> ZmnSCPxj >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000005f028f05d8552a3c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0One point of discomfort I have with Eltoo that I th= ink is not universal, but is shared by some others, is that non-punitive ch= annels may not be good for high-value channels as you do want, especially i= n a congested blockspace world, punishments to incentivize correct behavior= (otherwise cheating may look like a free option).

Without derailing=C2=A0the conversation too= far, "fully" punitive channels also make large value channels mo= re dangerous from the perspective of bugs causing old=C2=A0states to be pub= lished. High value channels you'll need to have very high uptime. If yo= u're available, your counterparty is incentivized to do a mutual close = to reduce fees and remove timelocks on=C2=A0outputs. I think these tradeoff= s will result in both types existing for N=3D=3D2.

On Sat, Feb 19, 202= 2 at 8:56 AM Jeremy Rubin via bitcoin-dev <bitcoin-dev@lists.linuxfounda= tion.org> wrote:
This is a fascinating post and I'm still chewing on it.

Chiming in with two points:

=
Point 1, note with respect to evi= ctions, revivals, CTV, TLUV:

<= /div>
CTV enables 1 person to be evicted= in O(log N) or one person to leave in O(log N). TLUV enables 1 person to l= eave in O(1) O(log N) transactions, but evictions take (AFAICT?) O(N) O(log= N) transactions because the un-live party stays in the pool. Hence OP_EVIC= T helps also make it so you can kick someone out, rather than all having to= leave, which is an improvement.
<= br>
CTV rejoins work as follows:

suppose you have a pool with 1 failure, you need to do log N txn= s to evict the failure, which creates R * log_R(N) outputs, which can then = do a transaction to rejoin.

For example, suppose I had 64 peopl= e in a radix 4 tree. you'd have at the top level 4 groups of 16, then 4= groups of 4 people, and then 1 to 4 txns. Kicking 1 person out would make = you do 3 txns, and create 12 outputs total. A transaction spending the 11 o= utputs that are live would capture 63 people back into the tree, and with C= ISA would not be terribly expensive. To be a bit more economical, you might= prefer to just join the 3 outputs with 16 people in it, and yield 48 peopl= e in one pool. Alternatively, you can lazily re-join if fees make it worth = it/piggybacking another transaction, or operate independently or try to fin= d new, better, peers.

Overall this is the type of application t= hat necessitates *exact* byte counting. Oftentimes things with CTV seem ine= fficient, but when you crunch the numbers=C2=A0it turns out not to be so te= rrible. OP_EVICT seems promising in this regard compared to TLUV or accumul= ators.

Another option is to randomize the CTV trees with multip= le outputs per party (radix Q), then you need to do Q times the evictions, = but you end up with sub-pools that contain more people/fractional liquidity= (this might happen naturally if CTV Pools have channels in them, so it'= ;s good to model).


Point 2, on Eltoo:

One point of discomfort I have with Eltoo = that I think is not universal, but is shared by some others, is that non-pu= nitive channels may not be good for high-value channels as you do want, esp= ecially in a congested blockspace world, punishments to incentivize correct= behavior (otherwise cheating may look like a free option).

Thu= s I'm reluctant to fully embrace designs which do not permit nested tra= ditional punitive channels in favor of Eltoo, when Eltoo might not have pro= duct-market-fit for higher valued channels.

If someone had a pu= nitive-eltoo variant that would ameliorate this concern almost entirely.

Cheers,

Jeremy




On = Fri, Feb 18, 2022 at 3:40 PM ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists= .linuxfoundation.org> wrote:
Good morning ariard,


> > A statechain is really just a CoinPool hosted inside a
> > =C2=A0Decker-Wattenhofer or Decker-Russell-Osuntokun construction= .
>
> Note, to the best of my knowledge, how to use LN-Penalty in the contex= t of multi-party construction is still an unsolved issue. If an invalidated= state is published on-chain, how do you guarantee that the punished output= value is distributed "fairly" among the "honest" set o= f users ? At least
> where fairness is defined as a reasonable proportion of the balances t= hey owned in the latest state.

LN-Penalty I believe is what I call Poon-Dryja?

Both Decker-Wattenhofer (has no common colloquial name) and Decker-Russell-= Osuntokun ("eltoo") are safe with N > 2.
The former has bad locktime tradeoffs in the unilateral close case, and the= latter requires `SIGHASH_NOINPUT`/`SIGHASH_ANYPREVOUT`.


> > In principle, a set of promised outputs, if the owners of those > > outputs are peers, does not have *any* inherent order.
> > Thus, I started to think about a commitment scheme that does not<= br> > > impose any ordering during commitment.
>
> I think we should dissociate a) *outputs publication ordering* from th= e b) *spends paths ordering* itself. Even if to each spend path a output pu= blication is attached, the ordering constraint might not present the same c= omplexity.
>
> Under this distinction, are you sure that TLUV imposes an ordering on = the output publication ?

Yes, because TLUV is based on tapleaf revelation.
Each participant gets its own unique tapleaf that lets that participant get= evicted.

In Taproot, the recommendation is to sort the hashes of each tapleaf before= arranging them into a MAST that the Taproot address then commits to.
This sort-by-hash *is* the arbitrary ordering I refer to when I say that TL= UV imposes an arbitrary ordering.
(actually the only requirement is that pairs of scripts are sorted-by-hash,= but it is just easier to sort the whole array by hash.)

To reveal a single participant in a TLUV-based CoinPool, you need to reveal= O(log N) hashes.
It is the O(log N) space consumption I want to avoid with `OP_EVICT`, and I= believe the reason for that O(log N) revelation is due precisely to the ar= bitrary but necessary ordering.

> > With `OP_TLUV`, however, it is possible to create an "N-of-N= With
> > Eviction" construction.
> > When a participant in the N-of-N is offline, but the remaining > > participants want to advance the state of the construction, they<= br> > > instead evict the offline participant, creating a smaller N-of-N<= br> > > where *all* participants are online, and continue operating.
>
> I think we should dissociate two types of pool spends : a) eviction by= the pool unanimity in case of irresponsive participants and b) unilateral = withdrawal by a participant because of the liquidity allocation policy. I t= hink the distinction is worthy, as the pool participant should be stable an= d the eviction not abused.
>
> I'm not sure if TLUV enables b), at least without transforming the= unilateral withdrawal into an eviction. To ensure the TLUV operation is co= rrect=C2=A0 (spent leaf is removed, withdrawing participant point removed, = etc), the script content must be inspected by *all* the participant. Howeve= r, I believe
> knowledge of this content effectively allows you to play it out agains= t the pool at any time ? It's likely solvable at the price of a CHECKSI= G.

Indeed, that distinction is important.
`OP_TLUV` (and `OP_EVICT`, which is just a redesigned `OP_TLUV`) supports (= a) but not (b).

> `OP_EVICT`
> ----------
>
> > =C2=A0* If it is `1` that simply means "use the Taproot inte= rnal
> > =C2=A0 =C2=A0pubkey", as is usual for `OP_CHECKSIG`.
>
> IIUC, this assumes the deployment of BIP118, where if the=C2=A0 public= key is a single byte 0x01, the internal pubkey is used
> for verification.

I thought it was part of Taproot?

>
> > =C2=A0* Output indices must not be duplicated, and indicated
> > =C2=A0 =C2=A0outputs must be SegWit v1 ("Taproot") outp= uts.
>
> I think public key duplication must not be verified. If a duplicated p= ublic key is present, the point is subtracted twice from the internal pubke= y and therefore the aggregated
> key remains unknown ? So it sounds to me safe against replay attacks.<= br>
Ah, right.

> > =C2=A0* The public key is the input point (i.e. stack top)
> > =C2=A0 =C2=A0**MINUS** all the public keys of the indicated outpu= ts.
>
> Can you prevent eviction abuse where one counterparty threatens to evi= ct everyone as all the output signatures are known among participants and f= ree to sum ? (at least not considering fees)

No, I considered onchain fees as the only mechanism to avoid eviction abuse= .
The individual-evict signatures commit to fixed quantities.
The remaining change is then the only fund that can pay for onchain fees, s= o a single party evicting everyone else has to pay for the eviction of ever= yone else.


> > Suppose however that B is offline.
> > Then A, C, and D then decide to evict B.
> > To do so, they create a transaction that has an output
> > with "B :=3D 6", and they reveal the `OP_EVICT` Tapscri= pt
> > as well as sign(b, "B :=3D 6").
> > This lets them change state and spend their funds without
> > B being online.
> > And B remains secure, as they cannot evict B except using
> > the pre-signed output, which B certifies as their expected
> > promised output.
>
> I think in the context of (off-chain) payment pool, OP_EVICT requires = participant cooperation *after* the state update to allow a single particip= ant to withdraw her funds.

How so?

A single participant withdrawing their funds unilaterally can do so by evic= ting everyone else (and paying for those evictions, as sort of a "nuis= ance fee").
The signatures for each per-participant-eviction can be exchanged before th= e signature exchange for the Decker-Wattenhofer or Decker-Russell-Osuntokun= .


> > The combined fund cannot be spent except if all participants
> > agree.
>
> If all participants agree minus the evicted ones, correct ? The output= promises signatures are shared at state setup, therefore no additional con= tribution from the evicted participant (I think).

Yes.

>
> > To prevent signature replay, each update of an updateable
> > scheme like CoinPool et al should use a different pubkey
> > for each participant for each state.
>
> I'm not even sure if it's required with OP_EVICT, as the publi= cation of the promised output are ultimately restrained by a signature of t= he updated internal pubkey, this set of signers verify that promised output= N does bind to the published state N ?

If the internal pubkey is reused (for example, if all participants are onli= ne and want to change state cooperatively) then the component keys need to = be re-tweaked each time.

The tweaking can be done with non-hardened derivation.


> > Its advantage is reduced number of eviction transactions,
> > as multiple evictions, plus the revival of the CoinPool,
> > can be put in a single transaction.
> > It has the disadvantage relative to `OP_TLUV` of requiring
> > point operations.
> > I have not explored completely, but my instinct suggests
> > that `OP_TLUV` use may require at least one signature
> > validation anyway.
>
> I believe you can slightly modify TLUV to make it functional for CoinP= ool revival, where you want to prevent equivocation among the remaining set= of signers. Though, I'm leaning to agree that you may require at least= one signature validation=C2=A0 (first to restrain spend authorization insi= de the pool participants, second to attach fees at broadcast-time).

Yes, TLUV does have that advantage relative to CTV, and `OP_EVICT` is "= ;just" a redesigned `OP_TLUV`.

In particular, I first developed my thoughts on revivable constructs with e= viction of participants here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022= -February/003479.html


Regards,
ZmnSCPxj
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000005f028f05d8552a3c--