From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 045ACC0010 for ; Fri, 30 Jul 2021 18:42:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id F384940571 for ; Fri, 30 Jul 2021 18:42:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lS_3Q61hnO2l for ; Fri, 30 Jul 2021 18:42:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by smtp2.osuosl.org (Postfix) with ESMTPS id 1DEA8400D9 for ; Fri, 30 Jul 2021 18:42:41 +0000 (UTC) Received: by mail-ej1-x636.google.com with SMTP id yk17so10780033ejb.11 for ; Fri, 30 Jul 2021 11:42:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=jCW2omUddHFxvbRxpQSC/x58TFG22KvNUWLHsRobQUQ=; b=Upe1ld+vzg3Bf/VoZ3Za/Pz9Pp/kljk7xCpaLz3EIn8OrBSAUxTsv7z3Ufl3/F1zGC q2q6F40mhuh+oxzlUWmmAdGRKHyVT9XBWQam9GrhnQR805itJ+luEc6fmgldT9VM1QpC u4vAEuiQsyZ77W5imKJxTDI/mMsn9a6zNZhkfbW37qZN2Gcaa1S++BTiMhXWKSWfvkXj SeAabRAKnG2BsbJxR4PSTge+/e7DNHxJ3yEU7QSrfzkY49yPWaz0QjW173KBs738XQsn HcIbB8HU52vd5QjQ0O5fFUCf05sKcQ0rHmDfmEt828e/3IUbO6WxmSay6YriuXK6Eiua 8pfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=jCW2omUddHFxvbRxpQSC/x58TFG22KvNUWLHsRobQUQ=; b=KQnf20KBvYGi2/55dFx081RYAJad6TfgdMFXFC5xvBJuNdhM/KMmMidgAStvjPVSI7 9M6qYiE9FLM2ttDMw2EQd5tCtBarOmM5ca7RgUqVxTJIxm3I502UcWWLQ/WEbZq5H9Qo qnR2q3OxTTLA0GgxQMga4IkB4O/fcVy2EhsIM213GLlqbIj6PLrDN2dQVT1v/jq6Roob d0wc3swdk125XRUwwWEmjcDZi52V+CNj8GUsrFV/WzFyJ8La+jPZ+GxMK4f3EeS54ICc vlReVEk3EyOc+PC7LCqQGTt9XSCjkJ5gzL0QPua4429ktYc1eynIHF60Jo2bC/zzyaUE RRBA== X-Gm-Message-State: AOAM531Wa3MLS/rDQCLR3Wq+zG6gKm83QnIsdysfpPu7uF4FAF5MQfTz Jn0kdlHq59gNYrTQ1LkrGLELvUy7vZpVLToLKqI= X-Google-Smtp-Source: ABdhPJwQB564d6+Ll9MS/pxKyEjUEb/cXkHsRAM/jvTEwf7dkwjADuac3nKXFBdUD9JgSlNNr8kEtGc4/SAnjTTQzjs= X-Received: by 2002:a17:906:4d94:: with SMTP id s20mr3843577eju.152.1627670559651; Fri, 30 Jul 2021 11:42:39 -0700 (PDT) MIME-Version: 1.0 References: <20210725053803.fnmd6etv3f7x3u3p@ganymede> In-Reply-To: From: Billy Tetrud Date: Fri, 30 Jul 2021 11:42:23 -0700 Message-ID: To: Jeremy , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000084f8fa05c85b95f3" X-Mailman-Approved-At: Fri, 30 Jul 2021 20:01:02 +0000 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: Fri, 30 Jul 2021 18:42:44 -0000 --00000000000084f8fa05c85b95f3 Content-Type: text/plain; charset="UTF-8" Thanks for taking another look Jeremy. That's an interesting idea to split it up into simpler opcodes, however there are some limitations/considerations there. For example, with output addresses, I added specifying amounts to outputs in order to make script evaluation simpler and eliminate a potential DOS vector. I wrote about this in the section 'Specifying values sent to each output '. Originally, I designed OP_CD without specifying what amounts an input contributes to what outputs, but it seemed like this would require calculating various combinations of inequalities, which could get expensive in scenarios where many inputs had overlapping destinations. See the examples under the OP_CD section in this commit . Maybe there's an elegant and cheap way of verifying that a number of inputs that have destination address limitations is within limits, but if so I don't know how to do that. If there was a good way to do that, then I wouldn't want to propose the ability to validate that specific amounts go to specific outputs. So unless there's a simple and dos-vector-free way of evaluating what addresses an input goes to without knowing what amounts an input contributes to each output, I don't think these functionalities should be separated. And about a fee-limit opcode, that could certainly be done on its own. However, a version of OP_CD that doesn't specify fees would have to take the fee-limit into account, and the calculation for the stand-alone fee-limit operation would be moot for that output. So I think it could make sense to split the fee limit off from the rest of OP_CD. I'm curious to know what others think of 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 Well, the transaction wouldn't be quite twice as large. Each output would add 9 bytes to the transaction, and outputs already are a minimum of about 30 bytes I think? So for transactions with a lot of outputs, it could make the transaction about 1/3 larger. I'll add a section on this into my proposal. Perhaps it would be a reasonable optimization to allow omitting an output value in cases where the entire output amount is contributed by that input. This would reduce the overhead of specifying output amounts to 2 bytes for most outputs (1 byte for the index, another to indicate the full value), meaning that it would only make the transaction about 7% larger. What do you think about that idea? On Wed, Jul 28, 2021 at 3:30 PM Jeremy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --00000000000084f8fa05c85b95f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for taking another look Jeremy. That's an inter= esting idea to split it up into simpler opcodes, however there are some lim= itations/considerations there.

For example, with output = addresses, I added specifying amounts to outputs in order to make script ev= aluation simpler and eliminate a potential DOS vector. I wrote about this i= n the section 'Specifying values sent to each output'. Origina= lly, I designed OP_CD without specifying what amounts an input contributes = to what outputs, but it seemed like this would require calculating various = combinations of inequalities, which could get expensive in scenarios where = many inputs had overlapping destinations. See the examples under the OP_CD = section in this commit.=C2= =A0

Maybe there's an elegant and cheap way of = verifying that a number of inputs that have destination address limitations= is within limits, but if so I don't know how to do that. If there was = a good way to do that, then I wouldn't want to propose the ability to v= alidate that specific amounts go to specific outputs. So unless there's= a simple and dos-vector-free way of evaluating what addresses an input goe= s to without knowing what amounts an input contributes to each output, I do= n't think these functionalities should be separated.=C2=A0

And about a fee-limit opcode, that could certainly be don= e on its own. However, a version of OP_CD that doesn't specify fees wou= ld have to take the fee-limit into account, and the calculation for the sta= nd-alone fee-limit operation would be moot for that output.=C2=A0

So I think it could make sense to split the fee limit off f= rom the rest of OP_CD. I'm curious to know what others think of that.= =C2=A0

>=C2=A0all transactions are twice as l= arge as they might otherwise need to be for simple things like congestion c= ontrol trees, since you have to repeat all of the output data twice<= /div>

Well, the transaction wouldn't be quite twice= as large. Each output would add 9 bytes to the transaction, and outputs al= ready are a minimum of about 30 bytes I think? So for transactions with a l= ot of outputs, it could make the transaction about 1/3 larger.=C2=A0= I&#= 39;ll add a section on this into my proposal.

Perha= ps it would be a reasonable optimization to allow omitting an output value = in cases where the entire output amount is contributed by that input. This = would reduce the overhead of specifying output amounts to 2 bytes for most = outputs (1 byte for the index, another to indicate the full value), meaning= that it would only make the transaction about 7% larger. What do you think= about that idea?

On Wed, Jul 28, 2021 at 3:30 PM J= eremy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
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 th= at all transactions are twice as large as they might otherwise need to be f= or simple things like congestion control trees, since you have to repeat al= l of the output data twice.
=
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000084f8fa05c85b95f3--