Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3AFEEC000E for ; Mon, 1 Nov 2021 01:20:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 2FC6740221 for ; Mon, 1 Nov 2021 01:20:01 +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 Wk0KSXzITWDV for ; Mon, 1 Nov 2021 01:19:59 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by smtp2.osuosl.org (Postfix) with ESMTPS id 6F5A94015F for ; Mon, 1 Nov 2021 01:19:59 +0000 (UTC) Received: by mail-ed1-x533.google.com with SMTP id s1so59225929edd.3 for ; Sun, 31 Oct 2021 18:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=M3hYR91C56rBkU5x08pk7KJjgO/qjR24v0dA+EhCdnw=; b=Z/RMt/EBzTH7qhTvtrKPnpJCQNEKz8pJRDCR2+AvS+LITzRj6O+Lw5VsrqoFM4MHx0 5bzVqNNMjqrQ2H9fulO+vBD8xu74s/hEuMN1SWWiu/uxsFd32RIvN3Jm/rwYWp+XbTud kr90lHnDwKCsGi/0fH/jqfQ8q98K8kS5x7DKlBwcXxQrgg2enj5bC8j7+dPLFm4CrZZ4 uqCHUR07yJIsDn05/+wqNJp9CLjttrG6v1MRzFhwH7/a892jklcOpMO+7Xn5yqNg9jda /Szu+seqv1xv7zuUIn3KZrggDJXDeWe5rauOUxUmZ+pU68vLFD0KKW9OttQMwTcAYlBl b9FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=M3hYR91C56rBkU5x08pk7KJjgO/qjR24v0dA+EhCdnw=; b=c5jDHdHswQjaYGqYezXVVvFBvCch9hULdsqkCmHyjLTOl580RtP8R2KmxhKGkYx/me XS1TSyjsTKtAK3Kn3ZrU/rMRYnO7Jl5U08RxdycI5NeN81EUI5wnP6t5MneWZW7lQLM5 XBPICabKLrY5H6em1DNGUEsLgwo40fAtmw3XfZOOd0hPF/Y2Hh/I8wtUhYC19cFcYOVf YGw07AshM3JVzqE7E2Yy+bQYGt+yAasPohaYvrcCQFhY5r6oU4VXeZK3BgYex7/OMQvo XcoC1qDICDE45S3Q/uXVTIHlAuJTDT01geuX70O4IlRUk3YO1q079yeHoSCXJKTJq+B2 uHdg== X-Gm-Message-State: AOAM530m716WIr30xevGy8qKpmO5DIlHXrmu9aBlJgL8JVpWLp9EsxK+ nJl07/AevzUATAV/d/eFbgM0FgeUMX5xDUt1ed4= X-Google-Smtp-Source: ABdhPJzSECqDQyG2R63gyO+mgRY4bXTRoMAFHbRrCFosx/pxGIynOR97hg1TPQy0FvVcivQsE/P/ss16Ifbu4HHWrt0= X-Received: by 2002:aa7:c553:: with SMTP id s19mr11691507edr.292.1635729597520; Sun, 31 Oct 2021 18:19:57 -0700 (PDT) MIME-Version: 1.0 References: <20210725053803.fnmd6etv3f7x3u3p@ganymede> In-Reply-To: From: Billy Tetrud Date: Sun, 31 Oct 2021 20:19:42 -0500 Message-ID: To: Jeremy , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000009bde8405cfaff9d0" X-Mailman-Approved-At: Mon, 01 Nov 2021 08:22:50 +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: Mon, 01 Nov 2021 01:20:01 -0000 --0000000000009bde8405cfaff9d0 Content-Type: text/plain; charset="UTF-8" FYI I broke out the fee limiting functionality from OP_CD into an opcode called OP_LIMITFEECONTRIBUTION as Jeremy suggested. On Fri, Jul 30, 2021 at 1:42 PM Billy Tetrud wrote: > 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 >> > --0000000000009bde8405cfaff9d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FYI I broke out the fee limiting functionality from OP_CD = into an opcode called OP_LIMITFEEC= ONTRIBUTION=C2=A0as Jeremy suggested.

On Fri, Jul 30, 2021 at 1:42 PM Bi= lly Tetrud <billy.tetrud@gmail= .com> wrote:
Thanks for taking another look Jeremy. That's an i= nteresting idea to split it up into simpler opcodes, however there are some= limitations/considerations there.

For example, with out= put addresses, I added specifying amounts to outputs in order to make scrip= t evaluation simpler and eliminate a potential DOS vector. I wrote about th= is in the section 'Specifying values sent to each ou= tput'. Originally, I designed OP_CD without specifying what amounts= an input contributes to what outputs, but it seemed like this would requir= e calculating various combinations of inequalities, which could get expensi= ve in scenarios where many inputs had overlapping destinations. See the exa= mples 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 t= hat have destination address limitations is within limits, but if so I don&= #39;t know how to do that. If there was a good way to do that, then I would= n'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 o= f evaluating what addresses an input goes to without knowing what amounts a= n input contributes to each output, I don't think these functionalities= should be separated.=C2=A0

And about a fee-l= imit 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.=C2=A0

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

= >=C2=A0all transactions are twice as large as they might otherwise need to = be for simple things like congestion control trees, since you have to repea= t all of the output data twice

Well, the t= ransaction wouldn't be quite twice as large. Each output would add 9 by= tes 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 tran= saction about 1/3 larger.=C2=A0I'll add a section on this into my p= roposal.

Perhaps it would be a reasonable optimiza= tion to allow omitting an output value in cases where the entire output amo= unt is contributed by that input. This would reduce the overhead of specify= ing output amounts to 2 bytes for most outputs (1 byte for the index, anoth= er to indicate the full value), meaning that it would only make the transac= tion about 7% larger. What do you think about that idea?
=

On Wed, Jul 28, 2021 at 3:30 PM Jeremy via bitcoin-dev <bitcoin-de= v@lists.linuxfoundation.org> wrote:
High level feedback:

you should spec out the opcodes as se= parate pieces of functionality as it sounds like OP_CD is really 3 or 4 opc= odes in one (e.g., amounts to outputs, output addresses, something with fee= s).

One major drawback of your approach is that all transaction= s are twice as large as they might otherwise need to be for simple things l= ike congestion control trees, since you have to repeat all of the output da= ta twice.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000009bde8405cfaff9d0--