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:
  1. The opcode limits user/group A to send the output to user/group B
  2. 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




On Sat, Jul 24, 2021 at 10:39 PM David A. Harding via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Tue, Jul 20, 2021 at 10:56:10PM -0700, Billy Tetrud via bitcoin-dev wrote:
> This involves [...] constraining the amount of the fee that output is
> allowed to contribute to.  [...] fee is specified relative to recent
> median fee rates - details in the proposal).

Here are the relevant details:

> The medianFeeRate is defined as the median fee rate per vbyte for the
> most recent windowLength blocks. The maxFeeContribution is defined as
> medianFeeRate * 2^feeFactor of the fee. Note that this is a limitation
> on the fee, not on the fee-rate. If feeFactor is -1,
> maxFeeContribution is 0.

First, I don't think we want full nodes to have to store the feerate for
every transaction in a 3,000 block window (~2.5 million txes, assuming
all segwit).  I'm sure you could tweak this proposal to require a much
smaller dataset.

Second, I think this requires careful consideration of how it might
affect the incentives for miners.  Miners can include many small high-fee
pay-to-self transactions in their blocks to raise the median feerate,
but this puts them at increased risk of fee sniping from other miners,
which may incentivize fee-raisers to centralize their mining, which is
ultimately bad.  I'm not sure that's a huge concern with this proposal,
but I think it and other incentive problems require consideration.

Finally, I think this fee mechanism is redundant.  For any case where
this opcode will be used, you'll want to have two things:

    1. A mutual spend clause (e.g. a multisignature taproot keypath
       spend) where all parties agree on a spend of the output and so
       can set an appropriate feerate at that time.  You want this
       because it'll be the most efficient way to spend.

    2. A fee override that allows paying additional fees beyond what
       OP_CONSTRAINDESTINATION allows, either through attaching an
       additional input or through CPFP.  You want this because you
       will know more about feerate conditions at spend time than you
       did when you created the receiving script.

If you have the ability to choose feerates through the above mechanisms,
you don't need a constrained feerate mechanism that might be
manipulable by miners.

(I haven't looked closely at the rest of your proposal; the above just
caught my attention.)

-Dave
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev