summaryrefslogtreecommitdiff
path: root/0c/ca7da4e71de4ac67452f8296461cd767f03ead
blob: 6029991140cc851cf44c4da7b157ae1b20d9559b (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
Return-Path: <dave@dtrt.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 624E1C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 26 Jul 2021 00:07:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 3CD0A6075A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 26 Jul 2021 00:07:36 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.325
X-Spam-Level: 
X-Spam-Status: No, score=-0.325 tagged_above=-999 required=5
 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_XBL=0.375,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=dtrt.org
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 8upHRWfCjQ6Y
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 26 Jul 2021 00:07:33 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from newmail.dtrt.org (newmail.dtrt.org
 [IPv6:2600:3c03::f03c:91ff:fe7b:78d1])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 64B2F60758
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 26 Jul 2021 00:07:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dtrt.org;
 s=20201208; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:
 Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
 List-Post:List-Owner:List-Archive;
 bh=3DMPkIZnqxzzK+d0lEzyRXKHQFgpptrCx/eXA8GT9+o=; b=xUWV7Lawje2zX0eb7Tn2t+6Mz0
 nHg/UHow8DcIe6xLDJJmSgt9hMwOBLfhuoUrZ9V1vdyGUJLRdU5g0gm0J1z7DRSb0wR0O0jF2fqOo
 ViJQnJVMOayGBNifHRjnTg5j3W6rk7Fl1Tox8wjDHgRe32YKI0gJcX3/pir8gKa3cS94=;
Received: from harding by newmail.dtrt.org with local (Exim 4.92)
 (envelope-from <dave@dtrt.org>)
 id 1m7o9b-0007Ky-5h; Sun, 25 Jul 2021 14:07:31 -1000
Date: Sun, 25 Jul 2021 14:05:53 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Billy Tetrud <billy.tetrud@gmail.com>
Message-ID: <20210726000553.tetqypkqj34lcztt@ganymede>
References: <CAGpPWDZ0aos5qHw2=popCpjuH7OXC0geEj8i3dwDTfP0j=or4w@mail.gmail.com>
 <20210725053803.fnmd6etv3f7x3u3p@ganymede>
 <CAGpPWDZ8EWd7kGV5pFZadQM1kqETrTK2zybsGF1hW9fx2oZb7w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="oyagbh26st2doxhg"
Content-Disposition: inline
In-Reply-To: <CAGpPWDZ8EWd7kGV5pFZadQM1kqETrTK2zybsGF1hW9fx2oZb7w@mail.gmail.com>
User-Agent: NeoMutt/20180716
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION
 (an alternative to OP_CTV)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Jul 2021 00:07:36 -0000


--oyagbh26st2doxhg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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

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

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

--oyagbh26st2doxhg
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAmD9/GEACgkQ2dtBqWwi
adMwGhAAugZMKkBNombyZ9r988g3PAwTthR6Lim5ahPJLWw4w1NnfHtVMKGcXYTE
hvR2YyNr0AkDyG/tV8z8mIDKprAJWyCYeXeLn3woQ8WNAKAOwatMPQWML9/PjhzI
qriktmY6npuGSFAtzFWUGSyDxx3NArz5FyeHDDC9tmdBivlcVcyoNb2PZ31/P0U0
eLMuIHt983fZG98osiAEGSPg8DwbDa+YQKSY9HCXOC7yd4xoV/IpVdX8kXdMohKg
8q0Qslwi4OeUYKSQ6e6orVEhWBnzJ0f9qq/CDdBOfCAuQ/z1MD2dYqlk7lg7eq0K
sMtG+L71yUJKni7hkaKgf74XdOUVG4Y9x0upHFTEIj3khHImbGRWlpyrRoh50uOH
w87zzEi3M+qu5jaE4anGtzPHiKt5Xl+WPjKVnxdZSw6d5I57y26IEDuSudHleqgr
O/X0FHz80++xQUknQNVbspMhDbZFz9+pXzAyAuYnGlEreVnXp0IuBxJG77AkcgPA
LKDuS6/bgLLMBb7awUDEJN6bOUsi1JyofaX1G4ogktAHYZ1AhCK0hyp/QtgSXPxd
do4Gy+bMK95lMWJpv5Kj3qbd2rnYltUby+X9c16Tn6HwRkLDFCZ/yO0mqLT4/fT4
4XziOAbS43M9CuHCQq5qGJ9sEvfirf8FPrTaCIle3BUQf3nY0Dg=
=3CiL
-----END PGP SIGNATURE-----

--oyagbh26st2doxhg--