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"
Subject: Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION
 (an alternative to OP_CTV)
Precedence: list

--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--