From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id BE6BAC000B for ; Fri, 4 Mar 2022 23:33:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 97D64841F2 for ; Fri, 4 Mar 2022 23:33:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 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_H2=-0.001, SPF_HELO_PASS=-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=protonmail.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 HqmkdPfbxFKZ for ; Fri, 4 Mar 2022 23:33:20 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130]) by smtp1.osuosl.org (Postfix) with ESMTPS id CA0B983313 for ; Fri, 4 Mar 2022 23:33:19 +0000 (UTC) Date: Fri, 04 Mar 2022 23:33:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1646436797; bh=BrwoxJtrl5NyQmbDUT7vlPzAjdijA74f6ByjpGz6tpo=; h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References: From:To:Cc:Date:Subject:Reply-To:Feedback-ID:Message-ID; b=q0L0mKoXzPXF52XtlKPyEXLf1QMiho6dYDYFZprwI6j7ZAYrqXT9EA6j7c6rHL+vT 8/keTvm37lLoM5EW7txJNalYaPTNzgFxPb32YRXxnEH29KSHmWboBgEK6hI9EUZmEx rrIOdw9e9xygT11dyq+4ojQ/9j8obbvqRFex4RpbnHSO/AhiG1maVHuVvwrpYelL9r ZuVgpYRHTtSBDKGU5O9f6BBO7sFlqcLFknFr1f5OuRnvatG+lfBPp0p0nYzM2PTAdA CSc9WoKA7aZe7fFjGVGEc6M0aBmOg/IbjJLdeehNtzKOzHudeifwB5rayHNMepGWlZ KuNjUj3GCmKbg== To: Jeremy Rubin , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [bitcoin-dev] Annex Purpose Discussion: OP_ANNEX, Turing Completeness, and other considerations 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: Fri, 04 Mar 2022 23:33:20 -0000 Good morning Jeremy, Umm `OP_ANNEX` seems boring .... > It seems like one good option is if we just go on and banish the OP_ANNEX= . Maybe that solves some of this? I sort of think so. It definitely seems l= ike we're not supposed to access it via script, given the quote from above: > > Execute the script, according to the applicable script rules[11], using t= he witness stack elements excluding the script s, the control block c, and = the annex a if present, as initial stack. > If we were meant to have it, we would have not nixed it from the stack, n= o? Or would have made the opcode for it as a part of taproot... > > But recall that the annex is committed=C2=A0to by=C2=A0the signature. > > So it's only a matter of time till we see some sort of Cat and Schnorr Tr= icks III the Annex Edition that lets you use G cleverly to get the annex on= to the stack again, and then it's like we had OP_ANNEX all along, or withou= t CAT, at least something that we can detect that the value has changed and= cause this satisfier looping issue somehow. ... Never mind I take that back. Hmmm. Actually if the Annex is supposed to be ***just*** for adding weight to the= transaction so that we can do something like increase limits on SCRIPT exe= cution, then it does *not* have to be covered by any signature. It would then be third-party malleable, but suppose we have a "valid" trans= action on the mempool where the Annex weight is the minimum necessary: * If a malleated transaction has a too-low Annex, then the malleated transa= ction fails validation and the current transaction stays in the mempool. * If a malleated transaction has a higher Annex, then the malleated transac= tion has lower feerate than the current transaction and cannot evict it fro= m the mempool. Regards, ZmnSCPxj