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: Sun, 31 Oct 2021 20:19:42 -0500	[thread overview]
Message-ID: <CAGpPWDawafVC+HMcyRo-H-QOvb_KGuHb=SrhM1=PgXvathx_4Q@mail.gmail.com> (raw)
In-Reply-To: <CAGpPWDZcK7gV0ZC92NzWYk58mYxR6E_UOZ-3W8FPSRLe7cvnmA@mail.gmail.com>

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

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

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