diff options
| author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2022-02-18 23:39:49 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-02-18 23:40:02 +0000 |
| commit | 669695858d306fd748cbf1b7a9b4e8ecee65e6b9 (patch) | |
| tree | 47d8cbbdd9d1a49d67576dbd248dc51862ba0f75 | |
| parent | 7b9a8c31e6a595a500a974f547bf3e44a1d2932f (diff) | |
| download | pi-bitcoindev-669695858d306fd748cbf1b7a9b4e8ecee65e6b9.tar.gz pi-bitcoindev-669695858d306fd748cbf1b7a9b4e8ecee65e6b9.zip | |
Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`
| -rw-r--r-- | a4/7d558902392211cc1cfdaff63ba198c1752503 | 262 |
1 files changed, 262 insertions, 0 deletions
diff --git a/a4/7d558902392211cc1cfdaff63ba198c1752503 b/a4/7d558902392211cc1cfdaff63ba198c1752503 new file mode 100644 index 000000000..71a335efc --- /dev/null +++ b/a4/7d558902392211cc1cfdaff63ba198c1752503 @@ -0,0 +1,262 @@ +Return-Path: <ZmnSCPxj@protonmail.com> +Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 222A7C000B + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 18 Feb 2022 23:40:02 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp3.osuosl.org (Postfix) with ESMTP id 0A04E60B0A + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 18 Feb 2022 23:40:02 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -1.599 +X-Spam-Level: +X-Spam-Status: No, score=-1.599 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_FROM=0.001, + FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H5=0.001, + RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] + autolearn=ham autolearn_force=no +Authentication-Results: smtp3.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=protonmail.com +Received: from smtp3.osuosl.org ([127.0.0.1]) + by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id I1aEqjhX2eBF + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 18 Feb 2022 23:40:00 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 +Received: from mail-4325.protonmail.ch (mail-4325.protonmail.ch [185.70.43.25]) + by smtp3.osuosl.org (Postfix) with ESMTPS id B81EE60AFC + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 18 Feb 2022 23:40:00 +0000 (UTC) +Date: Fri, 18 Feb 2022 23:39:49 +0000 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; + s=protonmail3; t=1645227596; + bh=ntct/vAb6+a4+eGXCxYMGeh/D3OeVMLiF7dLSPbVA80=; + h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: + References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: + Message-ID; + b=LfKWrm5562akWEomxMCPV29/rlP5lwpEUlo+6UdiPZDRDo5TzjLkIwsiJ24SFr5xY + G9b0KdUkcjPAM8D43CxUc2M0R3aUXjn9LVJ0bnHvBY2BynW4hANHk0m1029VuSHJZh + NYHubPFX/deszKUTwjIEw6iubocmcivq0oJfGmbKVT2dzr+EKPHtbz3HJm4+IDUdmE + BsbykUJ+LON3QWJo/M+QpIVTP1uqYyYDKL19cH+D+lRH4N4NlMUy6wp4I+AJgsw/5g + apUgCp9d8X0ZIq9p3SkmbQdcoigOgRFw7xRpJ7CVFms5kiNFrZV+j+e2wOMhXrq0Z5 + KDE4fbWVnJRqw== +To: Antoine Riard <antoine.riard@gmail.com> +From: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Message-ID: <0mhhHzTun8dpIcLda1CLFihMsgLoWQUEE8woKUKhf_UHYps2w7jVzbJAUJ302kQEB1ZdvMfakP9IBUHLM8bGns-pg0NHmpuak3yjpphjJnw=@protonmail.com> +In-Reply-To: <CALZpt+Ee9kuVjpXYgOb_7dB7Yr8HYmicdRhfgXsQkey2szNDHg@mail.gmail.com> +References: <6nZ-SkxvJLrOCOIdUtLOsdnl94DoX_NHY0uwZ7sw78t24FQ33QJlJU95W7Sk1ja5EFic5a3yql14MLmSAYFZvLGBS4lDUJfr8ut9hdB7GD4=@protonmail.com> + <CALZpt+Ee9kuVjpXYgOb_7dB7Yr8HYmicdRhfgXsQkey2szNDHg@mail.gmail.com> +MIME-Version: 1.0 +Content-Type: text/plain; charset=utf-8 +Content-Transfer-Encoding: quoted-printable +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` +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Fri, 18 Feb 2022 23:40:02 -0000 + +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 context o= +f multi-party construction is still an unsolved issue. If an invalidated st= +ate is published on-chain, how do you guarantee that the punished output va= +lue 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 publi= +cation is attached, the ordering constraint might not present the same comp= +lexity. +> +> 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 +> > 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 th= +e pool unanimity in case of irresponsive participants and b) unilateral wit= +hdrawal by a participant because of the liquidity allocation policy. I thin= +k the distinction is worthy, as the pool participant should be stable and t= +he eviction not abused. +> +> I'm not sure if TLUV enables b), at least without transforming the unilat= +eral withdrawal into an eviction. To ensure the TLUV operation is correct= +=C2=A0 (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 t= +he 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` +> ---------- +> +> > =C2=A0* If it is `1` that simply means "use the Taproot internal +> > =C2=A0 =C2=A0pubkey", as is usual for `OP_CHECKSIG`. +> +> IIUC, this assumes the deployment of BIP118, where if the=C2=A0 public ke= +y 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") outputs. +> +> I think public key duplication must not be verified. If a duplicated publ= +ic key is present, the point is subtracted twice from the internal pubkey a= +nd therefore the aggregated +> key remains unknown ? So it sounds to me safe against replay attacks. + +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 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, 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` Tapscript +> > 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 par= +ticipant 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 evic= +ting everyone else (and paying for those evictions, as sort of a "nuisance = +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 pr= +omises signatures are shared at state setup, therefore no additional contri= +bution 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 t= +he promised output are ultimately restrained by a signature of the updated = +internal pubkey, this set of signers verify that promised output N does bin= +d 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 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 si= +gnature validation=C2=A0 (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 e= +viction of participants here: https://lists.linuxfoundation.org/pipermail/l= +ightning-dev/2022-February/003479.html + + +Regards, +ZmnSCPxj + |