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 EA372C002D for ; Thu, 12 May 2022 07:17:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id D2CA540142 for ; Thu, 12 May 2022 07:17:09 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 aJYHdzKT53px for ; Thu, 12 May 2022 07:17:08 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from smtpauth.rollernet.us (smtpauth.rollernet.us [208.79.240.5]) by smtp4.osuosl.org (Postfix) with ESMTPS id 9554440133 for ; Thu, 12 May 2022 07:17:08 +0000 (UTC) Received: from smtpauth.rollernet.us (localhost [127.0.0.1]) by smtpauth.rollernet.us (Postfix) with ESMTP id E951A280005E; Thu, 12 May 2022 00:17:05 -0700 (PDT) Received: from webmail.rollernet.us (webmail.rollernet.us [IPv6:2607:fe70:0:14::a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by smtpauth.rollernet.us (Postfix) with ESMTPSA; Thu, 12 May 2022 00:17:05 -0700 (PDT) MIME-Version: 1.0 Date: Wed, 11 May 2022 21:17:05 -1000 From: "David A. Harding" To: Greg Sanders , Bitcoin Protocol Discussion In-Reply-To: References: User-Agent: Roundcube Webmail/1.4.10 Message-ID: <6a73b36724e6134a1cd57ea9277f2779@dtrt.org> X-Sender: dave@dtrt.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rollernet-Abuse: Contact abuse@rollernet.us to report. Abuse policy: http://www.rollernet.us/policy X-Rollernet-Submit: Submit ID 1d4c.627cb471.a3fde.0 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 07:17:10 -0000 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.