public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "David A. Harding" <dave@dtrt.org>
To: Billy Tetrud <billy.tetrud@gmail.com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV)
Date: Sat, 24 Jul 2021 19:38:03 -1000	[thread overview]
Message-ID: <20210725053803.fnmd6etv3f7x3u3p@ganymede> (raw)
In-Reply-To: <CAGpPWDZ0aos5qHw2=popCpjuH7OXC0geEj8i3dwDTfP0j=or4w@mail.gmail.com>

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2021-07-25  5:39 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-21  5:56 [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) Billy Tetrud
2021-07-25  5:38 ` David A. Harding [this message]
2021-07-25 19:49   ` Billy Tetrud
2021-07-26  0:05     ` David A. Harding
     [not found]       ` <SN7PR18MB3981DC1CD23B90367045995FD2E89@SN7PR18MB3981.namprd18.prod.outlook.com>
2021-07-26 20:18         ` Billy Tetrud
2021-07-26 21:08     ` James MacWhyte
2021-07-27  0:41       ` Billy Tetrud
2021-07-27 11:18         ` Zac Greenwood
2021-07-27 17:21           ` Billy Tetrud
2021-07-28  4:57             ` Zac Greenwood
2021-07-28 17:57               ` Billy Tetrud
2021-07-28 22:30                 ` Jeremy
2021-07-30 18:42                   ` Billy Tetrud
2021-11-01  1:19                     ` Billy Tetrud
2021-07-31 20:01                 ` [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value Zac Greenwood
2021-08-02  4:40                   ` Billy Tetrud
2021-08-10  2:17                   ` ZmnSCPxj
2021-08-13 11:02                     ` Zac Greenwood
2021-08-14  1:50                       ` ZmnSCPxj
2021-08-16 11:17                         ` Zac Greenwood
2021-08-16 11:48                           ` ZmnSCPxj
2021-08-30 14:43                             ` Zac Greenwood
2021-08-31  9:00                               ` ZmnSCPxj
2021-08-31 14:09                                 ` Zac Greenwood
2021-08-31 14:22                                   ` ZmnSCPxj
2021-09-01 15:15                                     ` Zac Greenwood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210725053803.fnmd6etv3f7x3u3p@ganymede \
    --to=dave@dtrt.org \
    --cc=billy.tetrud@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox