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>
Cc: 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 14:05:53 -1000	[thread overview]
Message-ID: <20210726000553.tetqypkqj34lcztt@ganymede> (raw)
In-Reply-To: <CAGpPWDZ8EWd7kGV5pFZadQM1kqETrTK2zybsGF1hW9fx2oZb7w@mail.gmail.com>

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

On Sun, Jul 25, 2021 at 12:49:38PM -0700, Billy Tetrud wrote:
> find the median fee-rate for each block and store that, then calculate
> the average of those stored per-block median numbers. 

One datapoint per block seems fine to me and it works much nicer with
pruned nodes.

> 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. 

I don't believe the problem scope can be reduced this way.  Although we
we often look at miners as separate from users, it's important to
remember that every miner is also a user of Bitcoin and ever user of
Bitcoin may also someday be a miner.  Users may also employ miners
directly via out-of-band payments.

In your usecase of vaults, we can imagine Bob is attempting to store
100,000 BTC.  He designs his vault to allow spending on fees up to 10x
the 3,000 block median fee.  Mallory steals Bob's encumbered spending
key.  Mallory could immediately go to a miner and offer them a 50/50
split on the 10x fees over the median (~10,000 sat?), or Mallory could
take a bit more time and work with a cartel of miners to raise the
median over a period of three weeks (3k blocks) to 10,000
BTC/transaction, allowing them to take all of Bob's coins in fees.

> 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.

The alternative is to never allow OP_CD to spend any of the UTXOs it
encumbers to fees, requiring all fees be paid via another mechanism.
Since satisfactory designs are going to provide those other mechanisms
anyway, it seems to me that there's no need for OP_CD to manage fees.
That said, I don't have a real strong opinion here.

-Dave

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

  reply	other threads:[~2021-07-26  0:07 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-21  5:56 Billy Tetrud
2021-07-25  5:38 ` David A. Harding
2021-07-25 19:49   ` Billy Tetrud
2021-07-26  0:05     ` David A. Harding [this message]
     [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=20210726000553.tetqypkqj34lcztt@ganymede \
    --to=dave@dtrt$(echo .)org \
    --cc=billy.tetrud@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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