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?