Thanks for taking a look at the proposal David. I appreciate it.
> I don't think we want full nodes to have to store the feerate for every transaction in a 3,000 block window
That's a good point. It would probably be just as good to find the median fee-rate for each block and store that, then calculate the average of those stored per-block median numbers. Do you think that would be sufficiently cheap to store?
> Miners can include many small high-fee pay-to-self transactions in their blocks to raise the median feerate
Definitely a reasonable thing to consider. One point I want to make about that tho is that the opcode only limits how much of a particular output can be put towards the transaction fee - for the vast majority of transactions using this opcode, a lower fee would be used and the limit would be irrelevant (and therefore raising the median fee rate would not affect those transactions). The point of limiting the fee is to limit an attacker's ability to grief a victim by sending all their funds as transaction fee. So the only situations where miners would gain something from raising the fee rate is for griefing situations, which should be so rare as to be completely insignificant to miners. If griefing is not rare, something else is pretty broken.
> I think this fee mechanism is redundant
See above, but to break down that situation a bit further, these are the two situations I can think of:
- The opcode limits user/group A to send the output to user/group B
- The opcode limits user A to send from one address they own to another address they own.
In case 1, user/group A could be the attacker that attempts to direct as much of the outputs as possible towards the fee (instead of the agreed upon recipient user/group B). In case 2, the attacker would be someone that steals a key from the user (eg in the case the attacker gets access to 1 key of the wallet vault keys) and attempts to grief them by making a transaction with the highest possible fee. In both these scenarios, the fee limit helps limit the amount of damage these attackers could do to their victim. Without a fee limit, these attack vectors could spend up to the full output amount as fee, which could be very damaging.
> A mutual spend clause
Have you considered the use case of wallet vaults? I designed this opcode primarily with wallet vaults in mind. In such a case there is a "mutual spend clause" of a kind - but all the keys may be owned by a single individual. One of the keys would be kept close at hand, and other keys would be kept in more secure and more difficult-to-access places (like a safe in a remote location). While the key-spend-path would be cheapest on chain, traveling to get the key itself might often be more expensive than using the script spend-path (because it takes time and effort to travel to those locations and access the keys). It might be informative to take a look at
these wallet vault scripts that could use this opcode or the
larger vision I have for wallet vaults (which involves 2 other new opcodes). There are certainly also multi-user multisig use cases for OP_CD that have similar properties to this single-user use case.
> A fee override that allows paying additional fees .. through attaching an additional input or through CPFP
I definitely agree those are desirable mechanisms. To reiterate what I said above, the fee limitation is there to limit griefing attack vectors that spend an unreasonable amount of a particular output towards the fee. Spending *other* outputs (via either of those mechanisms) towards a transaction's fee is perfectly acceptable and doesn't undermine the purpose of the fee limitation.
At its core, the limitation is there because the miner is another destination that the output's funds can be sent to, and while it wouldn't be wise to prevent an output from being spent as fee at all (because then the output is unspendable on its own, or with any other similarly constrained outputs), if OP_CD allowed spending the entire output as a fee then it wouldn't be successful in constraining the destination to the listed addresses.
Do you see my points here, or do you still think the limitation is redundant?
Thanks,
BT