Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV)

From: Billy Tetrud <billy.tetrud@gmail•com>
To: "David A. Harding" <dave@dtrt•org>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV)
Date: Sun, 25 Jul 2021 12:49:38 -0700	[thread overview]
Message-ID: <CAGpPWDZ8EWd7kGV5pFZadQM1kqETrTK2zybsGF1hW9fx2oZb7w@mail.gmail.com> (raw)
In-Reply-To: <20210725053803.fnmd6etv3f7x3u3p@ganymede>

[-- Attachment #1: Type: text/plain, Size: 7092 bytes --]

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
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/op_cdWalletVault1.md>
that
could use this opcode or the larger vision
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/README.md>
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
>

[-- Attachment #2: Type: text/html, Size: 8332 bytes --]