path: root/e6/b3e9f77649077742a0e4539998224815159cf0

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 045ACC0010
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 30 Jul 2021 18:42:41 +0000 (UTC)
Received: by mail-ej1-x636.google.com with SMTP id yk17so10780033ejb.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <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>
In-Reply-To: <CAD5xwhhAcup2pKyazopqz7aYAWYmXCJsq1OPni94+OJ8ErUXjQ@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Fri, 30 Jul 2021 11:42:23 -0700
Message-ID: <CAGpPWDZcK7gV0ZC92NzWYk58mYxR6E_UOZ-3W8FPSRLe7cvnmA@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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
<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
>

--00000000000084f8fa05c85b95f3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks for taking another look Jeremy. That&#39;s an inter=
esting idea to split it up into simpler opcodes, however there are some lim=
itations/considerations there.<div><br></div><div>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 &#39;<a href=3D"https://github.com/fresheneesz/bip-efficient-=
bitcoin-vaults/blob/main/cd/bip-constraindestination.md#specifying-values-s=
ent-to-each-output">Specifying values sent to each output</a>&#39;. 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 <a href=3D"https://github.com/fresheneesz/bip-efficient-bitcoin-=
vaults/commit/9b2257410b5f0fc991f68e774c3faf601c02cc5d">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 that 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 wouldn&#39;t want to propose the ability to v=
alidate that specific amounts go to specific outputs. So unless there&#39;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&#39;t think these functionalities should be separated.=C2=A0</div><div><d=
iv><br></div><div>And about a fee-limit opcode, that could certainly be don=
e on its own. However, a version of OP_CD that doesn&#39;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</div><div=
><br></div><div>So I think it could make sense to split the fee limit off f=
rom the rest of OP_CD. I&#39;m curious 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 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</span><=
/div><div><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-=
serif"><br></span></div><div><span style=3D"color:rgb(0,0,0);font-family:ar=
ial,helvetica,sans-serif">Well, the transaction wouldn&#39;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</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 proposal.</span></div><div><span style=
=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></span></d=
iv><div><font color=3D"#000000" face=3D"arial, helvetica, sans-serif">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?</font></div></div></div></div><br><div class=3D"gmail_quo=
te"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jul 28, 2021 at 3:30 PM J=
eremy via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundati=
on.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><bloc=
kquote class=3D"gmail_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" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:rgb(0,0,0)">High level feedback:</div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rg=
b(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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).</div><div class=3D"gmail_default" style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><d=
iv class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:rgb(0,0,0)">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.</div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,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>

--00000000000084f8fa05c85b95f3--