From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id AB908C002D for ; Thu, 12 May 2022 13:31:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 8BD1D41996 for ; Thu, 12 May 2022 13:31:15 +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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fXQawgwAUPk for ; Thu, 12 May 2022 13:31:14 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yw1-x112b.google.com (mail-yw1-x112b.google.com [IPv6:2607:f8b0:4864:20::112b]) by smtp4.osuosl.org (Postfix) with ESMTPS id 410D741987 for ; Thu, 12 May 2022 13:31:14 +0000 (UTC) Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-2f7d7e3b5bfso56520687b3.5 for ; Thu, 12 May 2022 06:31:14 -0700 (PDT) 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 :cc; bh=aFYEuaCTC3t5vxoyNIE4qHCl/s4uUvDyVinhU12Fj7U=; b=PDkwdzo57gW1tdREf7JWayP3qo2Jq1E+Zu81M/WN02PEzF5mY3XGuHqgbh+0hbIbKR +WTcbnMgNMHha0GDCUAC+MigxcqfnFVb1PAyAzuS9L6OIZyvqxD16z4O/mdG+TkeIm+m XNxlgOrRbwEhKz2PcK4o5O6eUK7o5m2e0FBA4GepY5UXexi7r7IkqIJOM1NAei+zDJG7 IyQvBrENvn1kdwC9TbT1mbc4FONUhEjGThJpNn6bRZlqSoas+mskhEHqw24iJeOJRLAj ppN1N6DLqWekPpdZskmRvLK9GqBjkQ/qOQsq6RO4dpf7hFgGgO+PZgTgKkuMNrLXzL9z WuZQ== 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:cc; bh=aFYEuaCTC3t5vxoyNIE4qHCl/s4uUvDyVinhU12Fj7U=; b=W3AIgXaLG6/ihv6/X14+DdrJGVz8nltxSZ3ETdvAkZR3tI2Ljr4oYQeePcc1ZIfUF7 9SydvadAPRxnqtXfOyOdpdSMmPL5gVwUMf6QKMDgeKz6r0SBT1TKabPx7PlTYe5o4c9h yennRY2vPj2g9y+49uIuH7YqGNU/HoEe+tnH2y8/+q2Boq9niV9wKW04+5ZUC9xYI10Z NCC2+diigEE5o+3Dbqmo1bxtCR2xhV5bhhRQTIBvL20WRk4s2vXNqhVwlOJ9JnYfCHoA mXXYffMe/lDtSuhDEa+LiiNxTeqmeTKd85BViEKBzgAWlDlg3Q0SZfiISaIxEO6mfT7k rwCw== X-Gm-Message-State: AOAM531YV2V13eboghG8JKzDqA+3SyV+Y01n/mx/SkMh/iEirEBZ4J0o Cwdjt75eQTlr8F7Vj/XEn9WlI8tX/WufHo42JCQFySVz X-Google-Smtp-Source: ABdhPJzdOPBQyHJpdynFSYKsA3Gn4sHGyx1hGrpKFR0VRuorJi4EpCbuv+VNH9bLYRzMfEu7yR87eDQ/MCBEUOd5j8w= X-Received: by 2002:a81:6355:0:b0:2f1:aed6:ad17 with SMTP id x82-20020a816355000000b002f1aed6ad17mr30795803ywb.381.1652362273040; Thu, 12 May 2022 06:31:13 -0700 (PDT) MIME-Version: 1.0 References: <6a73b36724e6134a1cd57ea9277f2779@dtrt.org> In-Reply-To: <6a73b36724e6134a1cd57ea9277f2779@dtrt.org> From: Greg Sanders Date: Thu, 12 May 2022 09:31:02 -0400 Message-ID: To: "David A. Harding" Content-Type: multipart/alternative; boundary="000000000000532cb005ded092b8" Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Bringing a nuke to a knife fight: Transaction introspection to stop RBF pinning 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: Thu, 12 May 2022 13:31:15 -0000 --000000000000532cb005ded092b8 Content-Type: text/plain; charset="UTF-8" Great point in this specific case I unfortunately didn't consider! So basically the design degenerates to the last option I gave, where the counterparty can send off N(25) weight-bound packages. A couple thoughts: 0) Couldn't we relative-time lock update transactions's state input by 1 block as well to close the vector off? People are allowed one "update transaction package" at a time in mempool, so if detected in-mempool it can be RBF'd, or in-block can be immediately responded to. 1) other usages of ANYONECANPAY like behavior may not have these issues, like vault structures. On Thu, May 12, 2022, 3:17 AM David A. Harding wrote: > On 2022-05-10 08:53, Greg Sanders via bitcoin-dev wrote: > > We add OPTX_SELECT_WEIGHT(pushes tx weight to stack, my addition to > > the proposal) to the "state" input's script. > > This is used in the update transaction to set the upper bound on the > > final transaction weight. > > In this same input, for each contract participant, we also > > conditionally commit to the change output's scriptpubkey > > via OPTX_SELECT_OUTPUT_SCRIPTPUBKEY and OPTX_SELECT_OUTPUTCOUNT==2. > > This means any participant can send change back > > to themselves, but with a catch. Each change output script possibility > > in that state input also includes a 1 block > > CSV to avoid mempool spending to reintroduce pinning. > > I like the idea! However, I'm not sure the `1 CSV` trick helps much. > Can't an attacker just submit to the mempool their other eltoo state > updates? For example, let's assume Bob and Mallory have a channel with > >25 updates and Mallory wants to prevent update[-1] from being committed > onchain before its (H|P)TLC timeout. Mallory also has at least 25 > unencumbered UTXOs, so she submits to the mempool update[0], update[1], > update[...], update[24]---each of them with a different second input to pay > fees. > > If `OPTX_SELECT_WEIGHT OP_TX` limits each update's weight to 1,000 > vbytes[1] and the default node relay/mempool policy of allowing a > transaction and up to 24 descendants remains, Mallory can pin the > unsubmitted update[-1] under 25,000 vbytes of junk---which is 25% of > what she can pin under current mempool policies. > > Alice can't RBF update[0] without paying for update[1..24] (BIP125 rule > #3), and an RBF of update[24] will have its additional fees divided by > its size plus the 24,000 vbytes of update[1..24]. > > To me, that seems like your proposal makes escaping the pinning at most > 75% cheaper than today. That's certainly an improvement---yay!---but > I'm not sure it eliminates the underlying concern. Also depending on > the mempool ancestor/descendant limits makes it harder to raise those > limits in the future, which is something I think we might want to do if > we can ensure raising them won't increase node memory/CPU DoS risk. > > I'd love to hear that my analysis is missing something though! > > Thanks!, > > -Dave > > [1] 1,000 vbytes per update seems like a reasonable value to me. > Obviously there's a tradeoff here: making it smaller limits the amount > of pinning possible (assuming mempool ancestor/descendant limits remain) > but also limits the number and complexity of inputs that may be added. > I don't think we want to discourage people too much from holding > bitcoins in deep taproot trees or sophisticated tapscripts. > --000000000000532cb005ded092b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Great point in this specific case I unfo= rtunately didn't consider! So basically the design degenerates to the l= ast option I gave, where the counterparty
can send o= ff N(25) weight-bound packages.

A couple thoughts:

0) Couldn= 9;t we relative-time lock update transactions's state input by 1 block = as well to close the vector off? People are allowed
one "upd= ate transaction package" at a time in mempool, so if detected in-mempo= ol it can be RBF'd, or in-block can be immediately responded to.
<= div dir=3D"auto">1) other usages of ANYONECANPAY=C2=A0like behavior may not= have these issues, like vault structures.=C2=A0

On Thu, May 12, 2022, 3:17 AM David A. Harding <dave@dtrt.org> wrote:
On 2022-05-10 08:53, Greg Sanders via bitcoin= -dev wrote:
> We add OPTX_SELECT_WEIGHT(pushes tx weight to stack, my addition to > the proposal) to the "state" input's script.
> This is used in the update transaction to set the upper bound on the > final transaction weight.
> In this same input, for each contract participant, we also
> conditionally commit to the change output's scriptpubkey
> via OPTX_SELECT_OUTPUT_SCRIPTPUBKEY and OPTX_SELECT_OUTPUTCOUNT=3D=3D2= .
> This means any participant can send change back
> to themselves, but with a catch. Each change output script possibility=
> in that state input also includes a 1 block
> CSV to avoid mempool spending to reintroduce pinning.

I like the idea!=C2=A0 =C2=A0However, I'm not sure the `1 CSV` trick he= lps much.=C2=A0
Can't an attacker just submit to the mempool their other eltoo state updates?=C2=A0 For example, let's assume Bob and Mallory have a channel= with
=C2=A0>25 updates and Mallory wants to prevent update[-1] from being com= mitted onchain before its (H|P)TLC timeout.=C2=A0 Mallory also has at least= 25 unencumbered UTXOs, so she submits to the mempool update[0], update[1],= update[...], update[24]---each of them with a different second input to pa= y fees.

If `OPTX_SELECT_WEIGHT OP_TX` limits each update's weight to 1,000
vbytes[1] and the default node relay/mempool policy of allowing a
transaction and up to 24 descendants remains, Mallory can pin the
unsubmitted update[-1] under 25,000 vbytes of junk---which is 25% of
what she can pin under current mempool policies.

Alice can't RBF update[0] without paying for update[1..24] (BIP125 rule=
#3), and an RBF of update[24] will have its additional fees divided by
its size plus the 24,000 vbytes of update[1..24].

To me, that seems like your proposal makes escaping the pinning at most 75% cheaper than today.=C2=A0 That's certainly an improvement---yay!---= but
I'm not sure it eliminates the underlying concern.=C2=A0 Also depending= on
the mempool ancestor/descendant limits makes it harder to raise those
limits in the future, which is something I think we might want to do if we can ensure raising them won't increase node memory/CPU DoS risk.

I'd love to hear that my analysis is missing something though!

Thanks!,

-Dave

[1] 1,000 vbytes per update seems like a reasonable value to me.=C2=A0
Obviously there's a tradeoff here: making it smaller limits the amount =
of pinning possible (assuming mempool ancestor/descendant limits remain) but also limits the number and complexity of inputs that may be added.=C2= =A0
I don't think we want to discourage people too much from holding
bitcoins in deep taproot trees or sophisticated tapscripts.
--000000000000532cb005ded092b8--