side-effect of limiting density
Closed this issue · 9 comments
I think only O(N2) opcodes would be affected (assuming removal of int limits). Imagine you want to do a few more OP_MULs but they'd be over the budget. Couldn't you add some <garbage> OP_DROP to inflate the TX size to reduce density and then squeeze in more calls to OP_MUL?
The push/drop consumes budget too, could one try to dodge it by inflating non-Script parts of TX (adding filler inputs/outputs). If yes, then we might consider counting output size as if it was a push op.
should add something like this to rationale, also good to emphasize that hash & operation limits are based on density: #19
Thanks for the comments @A60AB5450353F40E! In an earlier back and forth with @cculianu, I'd committed to taking another look at input-based densities, and I finally managed to re-verify all the numbers today. Please take a look and let me know what you think, does this address what you were thinking about with #19? Base densities on input length rather than transaction length: 2c9c180
your change is addressing shared budget vs per-input budget considerations, and I agree that per-input is a better approach since it avoids inputs implicitly depending on TX context (as opposed to explicit dependency when introspection opcodes are used)
we still need a rationale for the general density-based approach, because the effect of it is that people can add filler bytes to get more budget (either to input script, or to transaction)
I have updated #19 accordingly
I guess you want to steel-man the argument that this creates incentives to pad txn with junk to get more opcost capacity?
And then we can/should counter that argument in the CHIP? Is that how I should interpret your recommendation? (Apologies, still jet lagged).
yes, exactly that, we need to show that some exotic cases of padding are ok, because the alternatives are worse or more complex
addressed in finalize branch, closing
hmm @bitjson you dropped a lot of text from #19
I only glanced over your final edit and saw you merged #19, but you only mention the "padding" side-effect in passing:
Finally, this proposal could also increase the operation cost limit proportionally to the per-byte mining fee paid or based on the declaration of “virtual” bytes, e.g. for fee rates of 2 satoshis-per-real-byte, the VM could allow a per-byte budget of 2000 (a 2.5 multiple, incentivizing contracts to pay the higher fee rate rather than simply padding the unlocking bytecode length). However, any allowed increase in per-real-byte operation cost also equivalently changes the variability of per-byte worst-case transaction validation time; such flexibility would need to be conservatively capped and/or interact with the block size limit to ensure predictability of transaction and block validation requirements. Additionally, future research based on real-world usage may support simpler alternatives, e.g. a one-time increase in the per-byte operation cost budget.
or add something to risks section to show why this is not a problem for the network
hanks @A60AB5450353F40E! I just added Rationale: Non-Impact on "Data Storage" Costs and Incentives. Going to close this issue now, but please open a new issue if you see other things we should improve or add.