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
137
138
139
140
141
142
143
144
145
146
|
Return-Path: <dave@dtrt.org>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 2C256C000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 25 Jul 2021 05:39:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 13204403E4
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 25 Jul 2021 05:39:34 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 3.509
X-Spam-Level: ***
X-Spam-Status: No, score=3.509 tagged_above=-999 required=5
tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_SBL_CSS=3.335,
RCVD_IN_XBL=0.375, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=no autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=dtrt.org
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 3MbHRHJgdneU
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 25 Jul 2021 05:39: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 smtp4.osuosl.org (Postfix) with ESMTPS id 07934403E3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 25 Jul 2021 05:39:32 +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:To:From:Date:Sender:Reply-To:Cc: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=43yd9XCpSHv9yeFEiA0QyBZbIVs7CQEXvAVsBRTwHFg=; b=W7nIaQ+YHUHgWu22GTE0QVKSdp
8VNxbb972vXKc+YLeoDqlvRTERItbm3/HIOHzKkQsHLD5cWMT69hHGgFSVIVR51Yld29IDVmWIDex
fp1SwMc+Ys5bTNRREuy9+ljPwDT9sJ6FWsA45SBUZuSmavFfYyA0uCKDDD4Dzv95uOj4=;
Received: from harding by newmail.dtrt.org with local (Exim 4.92)
(envelope-from <dave@dtrt.org>)
id 1m7WrL-0003JX-2P; Sat, 24 Jul 2021 19:39:31 -1000
Date: Sat, 24 Jul 2021 19:38:03 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Billy Tetrud <billy.tetrud@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20210725053803.fnmd6etv3f7x3u3p@ganymede>
References: <CAGpPWDZ0aos5qHw2=popCpjuH7OXC0geEj8i3dwDTfP0j=or4w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="mk4ogpppwgik6ngy"
Content-Disposition: inline
In-Reply-To: <CAGpPWDZ0aos5qHw2=popCpjuH7OXC0geEj8i3dwDTfP0j=or4w@mail.gmail.com>
User-Agent: NeoMutt/20180716
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: Sun, 25 Jul 2021 05:39:34 -0000
--mk4ogpppwgik6ngy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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
--mk4ogpppwgik6ngy
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAmD8+LsACgkQ2dtBqWwi
adPpIBAAscWZFxXnh6Q/ourAnp9j9cNM6A/v7sQOO7rlr+t/+/HtpgD9lBxuAn1z
GChb/bo0ATVgaer8JlVUlJEDUoePQz9PFtfU3sGRUc3efHEu5JDATgsl/ZwrFVTz
Awrref8shk4BSSqXOFrd3MsJ9tqnZ9iuT26TxQlCniNxFJSIEOc1749H/XVgOgd7
Uw4iKpzGvXGD1VKOThhYz8tNQi9Hj9k6P9HtwOyDNah7N3PCSoUuYC5vT1sQ1uze
XscOlNU03xdKgUS6woFd4MXUwDAhk0VpsDOg6henj6+8ufyPeSQXJYT3TVBWYVGl
s7wjAsgpL8ZluBZSxx3gbnrRVxp09OWP/hf6/6cSs3QCIaAt37nLCpWBcodo+r/o
hAgvixUP0DNBspZblxoNK3ayLSWJFCAig8OI5YflX0nZRdiF09lS9cnsphN1bPwu
E5hJ4JjCIIUf/tVNX8pHzpu+/4se9aLdNr4HrMaOjc9Hc9fm34XFt3hUKzpvLiXV
Jp7s058onDlgTKHHIfY0bP3WUWNZNKR6PqKtGjMlVaiQAaxctGno12K8e5gbHKUl
yIRFnNUdmgJGhnp39UWWVGJEoLV4nc7gRVTws+I24RnGFdlQP5gTpdYjcZUNkk+N
ZL3Le4jGNS+mNILLqim/NbFMZHH1ezg5N1vXG7k1XA5CNkJeJrA=
=uh2t
-----END PGP SIGNATURE-----
--mk4ogpppwgik6ngy--
|
