Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 777EBC002B for ; Sat, 4 Feb 2023 02:07:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 3759E610D4 for ; Sat, 4 Feb 2023 02:07:44 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 3759E610D4 Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=AZKo8xUM 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 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 OJZuZ4ccepSp for ; Sat, 4 Feb 2023 02:07:43 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 1506860D7B Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by smtp3.osuosl.org (Postfix) with ESMTPS id 1506860D7B for ; Sat, 4 Feb 2023 02:07:42 +0000 (UTC) Received: by mail-ej1-x636.google.com with SMTP id gr7so20166452ejb.5 for ; Fri, 03 Feb 2023 18:07:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=x9CvoHFOHxdomavzeOzaVFis8n4PtogKWskBpepckZo=; b=AZKo8xUMk63rBLQqV0ljAjAFpSj99B6WflSC+IYD9gAxT16fTsjk8hyV5TW/JTr2bp P27WyuqgpQLTwMERF9Pa236f73+ik33Ejqc6h4eDKY2j+MQoraEL0rN4aSMC0iIlNPjD 8GL7Ei0Ep9RvdZxop6HUhvC6X6lPhFuSDii8L1ek32wvNWFizW5KKf4JQ1z05wOmYJjw JIdr03X5vj0bNFwjgRoOaMx8OuVp2SKUJkG43jvNuSw2aBX1M/9+C8/VMl/dUdWC+x9o vIY6R7Y72ZLVbZozSSg2SQvUkCmKE5x9COAGeKpKScNztiCN1u8Pe272Qc+Tv8ggZSV6 RZQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=x9CvoHFOHxdomavzeOzaVFis8n4PtogKWskBpepckZo=; b=1QxTDmwbqOnCpDHFEM0QO2AhzXpcMaSiIYkNCpl2zFTCTd1zHcUNoHYLVUxI9xLSxr XYxttBjUmtFhIMa6tLsqRo/5iQEjAJEtTzfQsMGeBDiv+14SlQm3DGFoHQ8u4927GKxJ LFVK3EB2twpvxpgMnlesqIB5J4JuxcihYwmNv6Cp4SaOEndCXPiqzmhVbcV8vMqmZmc3 6bC3IqVxdA2FGWLV/ToMkAD+kAkKxT9CPV76nw9Ytkgo4tOY/BUDAoiO5J6h2ePkx0gw 6uol3Z94f2toKG8bMTNfmH4EUd+1rV2BClQ9CsemWGuMuQKKd3n/MeX5I02v3wnMXZ0j 6+9Q== X-Gm-Message-State: AO0yUKVSpdiKYZKQnLbYotC9LgC2P4/K3BJaW4jjuUncgDhLFJQGbXZC /IldzTXtetHTePMK1aOJb7SoeOGQUlMvoKjI/8KXsl8sZ6I= X-Google-Smtp-Source: AK7set+Pq2WPqoxANCIlM+/ryqaXWkcfeUhUvx4vR2eudDPLB99TdAA6yHmiPg3XzdH68HmzDuIabiJYw9X7cf++wiU= X-Received: by 2002:a17:907:6087:b0:889:7bef:3a9d with SMTP id ht7-20020a170907608700b008897bef3a9dmr4016509ejc.150.1675476460931; Fri, 03 Feb 2023 18:07:40 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Sanders Date: Fri, 3 Feb 2023 21:07:29 -0500 Message-ID: To: Peter Todd Content-Type: multipart/alternative; boundary="0000000000004891cc05f3d643e2" Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit 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: Sat, 04 Feb 2023 02:07:44 -0000 --0000000000004891cc05f3d643e2 Content-Type: text/plain; charset="UTF-8" I'm not particularly persuaded, but also not wedded to either idea. Fixed up tests for the OP_TRUE case here: https://github.com/instagibbs/bitcoin/tree/ephemeral-anchors-true On Fri, Feb 3, 2023 at 5:10 PM Peter Todd wrote: > On Thu, Feb 02, 2023 at 03:47:28PM -0500, Greg Sanders wrote: > > > OP_TRUE is the obvious way to do this, and it results with a 1 on the > > stack, > > which plays better with other standardness rules. > > > > What other standardness rules? MINAMALIF? How does that interact with the > > proposal? > > It makes sense to require scripts to leave just a single OP_TRUE on the > stack > at the end of execution, as otherwise that can be a source of malleability > in > certain circumstances where the scriptSig ends up providing the OP_TRUE. I > don't believe we actually implement this as a rule right now. But you could > easily imagine that happening in a future upgrade. > > Leaving an OP_2 on the stack doesn't achieve that and would require a > special-cased workaround. Spending the time now to do the obvious thing - > use > OP_TRUE as the canonical anyone-can-spend output - avoids this issue. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > --0000000000004891cc05f3d643e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not particularly persuaded, but also not wedded to= either idea.

Fixed up tests for the OP_TRUE case here:= =C2=A0https://github.com/instagibbs/bitcoin/tree/ephemeral-anchors-true<= /a>

On Thu, Feb 02, 2023 at 03:47:28PM -050= 0, Greg Sanders wrote:
> > OP_TRUE is the obvious way to do this, and it results with a 1 on= the
> stack,
> which plays better with other standardness rules.
>
> What other standardness rules? MINAMALIF? How does that interact with = the
> proposal?

It makes sense to require scripts to leave just a single OP_TRUE on the sta= ck
at the end of execution, as otherwise that can be a source of malleability = in
certain circumstances where the scriptSig ends up providing the OP_TRUE. I<= br> don't believe we actually implement this as a rule right now. But you c= ould
easily imagine that happening in a future upgrade.

Leaving an OP_2 on the stack doesn't achieve that and would require a special-cased workaround. Spending the time now to do the obvious thing - u= se
OP_TRUE as the canonical anyone-can-spend output - avoids this issue.

--
http= s://petertodd.org 'peter'[:-1]@petertodd.org
--0000000000004891cc05f3d643e2--