FYI I broke out the fee limiting functionality from OP_CD into an opcode called OP_LIMITFEECONTRIBUTION as Jeremy suggested. On Fri, Jul 30, 2021 at 1:42 PM Billy Tetrud 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 > '. > 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 > > . > > 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 >> >