Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV)

From: Billy Tetrud <billy.tetrud@gmail•com>
To: Jeremy <jlrubin@mit•edu>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV)
Date: Fri, 30 Jul 2021 11:42:23 -0700	[thread overview]
Message-ID: <CAGpPWDZcK7gV0ZC92NzWYk58mYxR6E_UOZ-3W8FPSRLe7cvnmA@mail.gmail.com> (raw)
In-Reply-To: <CAD5xwhhAcup2pKyazopqz7aYAWYmXCJsq1OPni94+OJ8ErUXjQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3520 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 5423 bytes --]