path: root/59/77aeb8ca30a1fabf242f0ba95ccf1fa11cda00

Return-Path: <fresheneesz@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 3AFEEC000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  1 Nov 2021 01:19:59 +0000 (UTC)
Received: by mail-ed1-x533.google.com with SMTP id s1so59225929edd.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAGpPWDZ0aos5qHw2=popCpjuH7OXC0geEj8i3dwDTfP0j=or4w@mail.gmail.com>
 <20210725053803.fnmd6etv3f7x3u3p@ganymede>
 <CAGpPWDZ8EWd7kGV5pFZadQM1kqETrTK2zybsGF1hW9fx2oZb7w@mail.gmail.com>
 <CAH+Axy7cPufMUCMQbCz2MUgRqQbgenAozPBFD8kPYrSjwcRG8w@mail.gmail.com>
 <CAGpPWDb8yzGO-VtCO-x09e-phKHT7ezOms+DzeWc9vS3rN1AAw@mail.gmail.com>
 <CAJ4-pEDWuNfdE4NXkZBsOnuSQ4YOv28YVwGavyiU+FPvpC6y1w@mail.gmail.com>
 <CAGpPWDZL6BpzoNa0Qgf-Ux60fyWPjZH=NESkgbhEQO_My=XiAg@mail.gmail.com>
 <CAJ4-pEBwdUJ3kg=yb-kWZLoaX5f_2t353K7Tr+dJy+JpAoKTmQ@mail.gmail.com>
 <CAGpPWDYMZ+w3VSaLhR68f4WVq7NCUp3SedwW2e8QnRHOgLQqQg@mail.gmail.com>
 <CAD5xwhhAcup2pKyazopqz7aYAWYmXCJsq1OPni94+OJ8ErUXjQ@mail.gmail.com>
 <CAGpPWDZcK7gV0ZC92NzWYk58mYxR6E_UOZ-3W8FPSRLe7cvnmA@mail.gmail.com>
In-Reply-To: <CAGpPWDZcK7gV0ZC92NzWYk58mYxR6E_UOZ-3W8FPSRLe7cvnmA@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Sun, 31 Oct 2021 20:19:42 -0500
Message-ID: <CAGpPWDawafVC+HMcyRo-H-QOvb_KGuHb=SrhM1=PgXvathx_4Q@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/lfc/bip-limit-fee-contribution.md>
as
Jeremy suggested.

On Fri, Jul 30, 2021 at 1:42 PM Billy Tetrud <billy.tetrud@gmail.com> 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
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md#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
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/commit/9b2257410b5f0fc991f68e774c3faf601c02cc5d>
> .
>
> 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

<div dir=3D"ltr">FYI I broke out the fee limiting functionality from OP_CD =
into an opcode called <a href=3D"https://github.com/fresheneesz/bip-efficie=
nt-bitcoin-vaults/blob/main/lfc/bip-limit-fee-contribution.md">OP_LIMITFEEC=
ONTRIBUTION</a>=C2=A0as Jeremy suggested.</div><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jul 30, 2021 at 1:42 PM Bi=
lly Tetrud &lt;<a href=3D"mailto:billy.tetrud@gmail.com">billy.tetrud@gmail=
.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr">Thanks for taking another look Jeremy. That&#39;s an i=
nteresting idea to split it up into simpler opcodes, however there are some=
 limitations/considerations there.<div><br></div><div>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 &#39;<a href=3D"https://github.com/fresheneesz/bip-effici=
ent-bitcoin-vaults/blob/main/cd/bip-constraindestination.md#specifying-valu=
es-sent-to-each-output" target=3D"_blank">Specifying values sent to each ou=
tput</a>&#39;. 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 <a href=3D"https://github.com/fresheneesz/=
bip-efficient-bitcoin-vaults/commit/9b2257410b5f0fc991f68e774c3faf601c02cc5=
d" target=3D"_blank">this commit</a>.=C2=A0</div><div><br></div><div>Maybe =
there&#39;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&#39;t want to propose the ability to validate that specific amounts go to=
 specific outputs. So unless there&#39;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&#39;t think these functionalities=
 should be separated.=C2=A0</div><div><div><br></div><div>And about a fee-l=
imit opcode, that could certainly be done on its own. However, a version of=
 OP_CD that doesn&#39;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</div><div><br></div><div>So I think it could=
 make sense to split the fee limit off from the rest of OP_CD. I&#39;m curi=
ous to know what others think of that.=C2=A0</div><div><div><br></div><div>=
&gt;=C2=A0<span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-=
serif">all 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</span></div><div><span style=3D"color:rgb(0,=
0,0);font-family:arial,helvetica,sans-serif"><br></span></div><div><span st=
yle=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">Well, the t=
ransaction wouldn&#39;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=A0</span><span style=3D"color:rgb(0,0,0);font-=
family:arial,helvetica,sans-serif">I&#39;ll add a section on this into my p=
roposal.</span></div><div><span style=3D"color:rgb(0,0,0);font-family:arial=
,helvetica,sans-serif"><br></span></div><div><font color=3D"#000000" face=
=3D"arial, helvetica, sans-serif">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?</font></div></div>=
</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_=
attr">On Wed, Jul 28, 2021 at 3:30 PM Jeremy via bitcoin-dev &lt;<a href=3D=
"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-de=
v@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_default" st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0=
,0)">High level feedback:</div><div class=3D"gmail_default" style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></di=
v><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:rgb(0,0,0)">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).</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:rgb(0,0,0)">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.</div><div class=3D"gmail_default" style=3D"font-family:arial,helv=
etica,sans-serif;font-size:small;color:rgb(0,0,0)"></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div>

--0000000000009bde8405cfaff9d0--