Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2F6EEC000E for ; Wed, 28 Jul 2021 22:30:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 0BD20402C6 for ; Wed, 28 Jul 2021 22:30:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 f67jjMpPUqDE for ; Wed, 28 Jul 2021 22:30:33 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp4.osuosl.org (Postfix) with ESMTPS id 378B1402A9 for ; Wed, 28 Jul 2021 22:30:32 +0000 (UTC) Received: from mail-io1-f53.google.com (mail-io1-f53.google.com [209.85.166.53]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 16SMUUwn029825 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 28 Jul 2021 18:30:31 -0400 Received: by mail-io1-f53.google.com with SMTP id l18so4559472ioh.11 for ; Wed, 28 Jul 2021 15:30:31 -0700 (PDT) X-Gm-Message-State: AOAM533TwFDKpeSCc+gAJ+RYWSeSUTeuGi5shIMBF+NSsRl1kgs3WZjR ZU5huFFuJ8tbuFM00Dld8O13Xx6JD1yK50xMPDo= X-Google-Smtp-Source: ABdhPJzhyvNZVtTjtCcFrCoQ2u+sh5Xf0kYdHsOunId+fLnV1SG1TfHv6g1Dowbq1gZjtvI0o02ROs0XhxaHG2MBzCk= X-Received: by 2002:a6b:f91a:: with SMTP id j26mr1406503iog.97.1627511430737; Wed, 28 Jul 2021 15:30:30 -0700 (PDT) MIME-Version: 1.0 References: <20210725053803.fnmd6etv3f7x3u3p@ganymede> In-Reply-To: From: Jeremy Date: Wed, 28 Jul 2021 15:30:19 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000b2794105c836886a" Subject: Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) 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: Wed, 28 Jul 2021 22:30:34 -0000 --000000000000b2794105c836886a Content-Type: text/plain; charset="UTF-8" High level feedback: you should spec out the opcodes as separate pieces of functionality as it sounds like OP_CD is really 3 or 4 opcodes in one (e.g., amounts to outputs, output addresses, something with fees). One major drawback of your approach is that all transactions are twice as large as they might otherwise need to be for simple things like congestion control trees, since you have to repeat all of the output data twice. --000000000000b2794105c836886a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
High level feedback:

you should spec out the opcodes as separate pieces of functional= ity as it sounds like OP_CD is really 3 or 4 opcodes in one (e.g., amounts = to outputs, output addresses, something with fees).

One major d= rawback of your approach is that all transactions are twice as large as the= y might otherwise need to be for simple things like congestion control tree= s, since you have to repeat all of the output data twice.
--000000000000b2794105c836886a--