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
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 97573F8A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 29 Jan 2018 00:46:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f50.google.com (mail-pg0-f50.google.com [74.125.83.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 130A5108
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 29 Jan 2018 00:46:52 +0000 (UTC)
Received: by mail-pg0-f50.google.com with SMTP id r19so3124397pgn.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jan 2018 16:46:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20150623.gappssmtp.com; s=20150623;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to; bh=2BaMecMLHwH59nYBu8zMxZoNDIxmf26mDZ3FhoMqN/Y=;
b=RxjNxA+SaAref6dlXpgIXuE2Ry/d0U8xAb8je2N1cG7sdwwGsn6S7achpMq5SjbOWP
VJpEWFsNsNHD9ndEi4GzKj8DuxBJIkITCXHGOC4BkGj5dD09sxs/Yv8UDuifgo0nsaLn
F7IG2MhHXv25Ou2/x6Sk74WnW+ii05+LhKGTNIVAS6S7im5qlO1R+vWtbRFt5cCfr7g0
PY58LdQzoKNHvt6sbf5Tv9BeGUb3zoUwBYNQ00vnjP642l8Ig+K90o9qCCYgqZkLFaah
aLbqE/zYBpUtK5xAKGK2EycKymRoCCOBAIst4sNtFeXfiKD8eUQHmCCC55ysL9TUy6GM
01VQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:references:from:message-id:date
:user-agent:mime-version:in-reply-to;
bh=2BaMecMLHwH59nYBu8zMxZoNDIxmf26mDZ3FhoMqN/Y=;
b=fMNE9lBnTcD3CwH+0dP74FCKTsWT65rkgeiBbgl44DcCGVgf12kygEmtjgdUJAGHdH
p48PpM9XGv4LCC1PnOecrYHE21ESqa55wp6+41cluC9fFZnvx/i2Czrt50xu95Ude0h2
Y2ZFcPnnz1jBogjfkUlKV9nKZRDos/NpJl5znNpiYa/sY96hzP8QdgIGIypta80knnjK
LYjGCPtLaEgVOjVH3qIBSZLq/7ru+Ck5OscATE1pXv+3j+ggHTnzj5lG0nl3UvnsEYGt
t4Dtix9cn3e4PwnTPD5coaNVTds9r/q76dVVaKH/RIjGw6WgPpkzoWFhj5i78nKIezcq
NQXQ==
X-Gm-Message-State: AKwxytdWnStCpK3EERl8sieokYai517f4hCHx4pEnkweWgIT8ijrT9j3
7aIqBMIxDW2+fchQq1JPzqJYpiE5
X-Google-Smtp-Source: AH8x227Aw2mUWm/Ozo6RvLM924D9dcW97cWPwUW8sK5tEHbJQ5oJgLBvlCJwZl+2PB1nQ4bD6xR/+w==
X-Received: by 10.101.75.193 with SMTP id p1mr3491599pgr.63.1517186811517;
Sun, 28 Jan 2018 16:46:51 -0800 (PST)
Received: from ?IPv6:2601:600:a080:16bb:f947:5006:f7cc:113e?
([2601:600:a080:16bb:f947:5006:f7cc:113e])
by smtp.gmail.com with ESMTPSA id
b68sm24820827pfg.159.2018.01.28.16.46.50
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sun, 28 Jan 2018 16:46:50 -0800 (PST)
To: Lucas Clemente Vella <lvella@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Nathan Parker <icesby24@gmail.com>
References: <CAPzrG5bFTbRERHQsmyFeZwiuakgSW5UCC8EtYfAm4j9EDtcLeg@mail.gmail.com>
<CAGCathyVqQcBCKORQebicWq+OQfKZVLXb0g_9QHBu2e-jqYBgg@mail.gmail.com>
From: Eric Voskuil <eric@voskuil.org>
Message-ID: <807a2661-b83e-1fc7-3db0-35ee120745bd@voskuil.org>
Date: Sun, 28 Jan 2018 16:46:51 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <CAGCathyVqQcBCKORQebicWq+OQfKZVLXb0g_9QHBu2e-jqYBgg@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="nlOhHaQaIAx3ERUjxEHs5df9ukLH5unD1"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 29 Jan 2018 00:54:50 +0000
Subject: Re: [bitcoin-dev] Proposal: rewarding fees to next block miner
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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, 29 Jan 2018 00:46:52 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--nlOhHaQaIAx3ERUjxEHs5df9ukLH5unD1
Content-Type: multipart/mixed; boundary="5Ssgj5mPhwKCbjwzPVSu2fbXZxNiEfGGY";
protected-headers="v1"
From: Eric Voskuil <eric@voskuil.org>
To: Lucas Clemente Vella <lvella@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Nathan Parker <icesby24@gmail.com>
Message-ID: <807a2661-b83e-1fc7-3db0-35ee120745bd@voskuil.org>
Subject: Re: [bitcoin-dev] Proposal: rewarding fees to next block miner
References: <CAPzrG5bFTbRERHQsmyFeZwiuakgSW5UCC8EtYfAm4j9EDtcLeg@mail.gmail.com>
<CAGCathyVqQcBCKORQebicWq+OQfKZVLXb0g_9QHBu2e-jqYBgg@mail.gmail.com>
In-Reply-To: <CAGCathyVqQcBCKORQebicWq+OQfKZVLXb0g_9QHBu2e-jqYBgg@mail.gmail.com>
--5Ssgj5mPhwKCbjwzPVSu2fbXZxNiEfGGY
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Miners accept less than the optimal (i.e. highest net fee) set of
transactions all the time. The reason is that it takes too much time to
compute the optimal set. All other things being equal, the miner who is
more efficient at computing a set is more profitable.
Intentionally not accepting the most optimal set possible is a cost, not
a source of increased returns. Miners can raise the historical fee level
by paying this real cost, just as can any other person (by submitting a
competitive-fee transaction). They cannot "recover" this cost. They have
no place of advantage in terms of competing for block space.
Finally, historical prices do not determine future prices. Current
competition for block space determines future prices.
e
On 01/28/2018 08:54 AM, Lucas Clemente Vella via bitcoin-dev wrote:
> If the miner wants to force fees up, why would he fill up a block with
> placeholder high fee transactions, instead of simply cutting off
> transactions paying less fee than he is willing to take? Is there any
> evidence someone is doing such a thing for whatever reason?
>
> 2018-01-27 6:45 GMT-02:00 Nathan Parker via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>>:
>=20
> Miners can fill their blocks with transactions paying very high fee=
s
> at no cost because they get the fees back to themselves. They can d=
o
> this for different purposes, like trying to increase the recommende=
d
> fee. Here I propose a backwards-compatible solution to this problem=
=2E
>=20
> The solution would be to reward the fees of the current block to th=
e
> miner of the next block (or X blocks after the current one). That
> way, if a miner floods its own block with very high fee
> transactions, those fees are no longer given back to itself, but to=
> the miner of future blocks which could potentially be anyone.
> Flooding blocks with fake txs is now discouraged. However, filling
> blocks with real transactions paying real fees is still encouraged
> because you could be the one to mine the block that would claim thi=
s
> reward.
>=20
> The way to implement this in a backwards-compatible fashion would b=
e
> to enforce miners to set an anyone-can-spend output in the coinbase=
> transaction of the block (by adding this as a rule for verifying ne=
w
> blocks). The miner of 100 blocks after the current one can add a
> secondary transaction spending this block's anyone-can-spend
> coinbase transaction (due to the coinbase needing 100 blocks to
> mature) and thus claiming the funds. This way, the block reward of =
a
> block X is always transferred to the miner of block X+100.
>=20
> Implementing this would require a soft-fork. Since that secondary
> transaction needs no signature whatsoever, the overhead caused by
> that extra transaction is negligible.
>=20
> Possible Downside: When the fork is activated, the miners won=E2=80=
=99t get
> any reward for mining blocks for a period of 100 blocks. They could=
> choose to power off the mining equipment for maintenance or to save=
> power over that period, so the hashrate could drop temporarily.
> However, if the hashrate drops too much, blocks would take much
> longer to mine, and miners wouldn=E2=80=99t want that either since =
they want
> to go through those 100 reward-less blocks as soon as possible so
> they can start getting rewards from mining again.
>=20
>=20
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>=20
>=20
>=20
>=20
> --=20
> Lucas Clemente Vella
> lvella@gmail.com <mailto:lvella@gmail.com>
>=20
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
--5Ssgj5mPhwKCbjwzPVSu2fbXZxNiEfGGY--
--nlOhHaQaIAx3ERUjxEHs5df9ukLH5unD1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBAgAGBQJabm77AAoJEDzYwH8LXOFOd3UH/RvS7XbH58gMGzz2qN4SUicN
YaiNqcVOVo6a3jjhKFqhvMawEzh5jNwY0nDglm1JsZicGyByr349NYjuiD7IslOn
VWv/ExpF9THheMfWO1hOFXK5sKPpCFsYggjtZm/JPWEdYWUY0d6L6AHRcAoGm0WM
+yHH17HC6Jg3Y5laD4aYHrHrZdIJsU9ty1uDqW69MaY+7Bq5ydUb3BbZrBMMDuwI
exqBZlRjPR2QcaAFPiLaZiaXRTw2t1PoIxdD0fuHNIfyNuErKL4iarUKEdkkVWxc
L0iv6vmBv4lZXtoDQ0udAZmmm94GyLQYlONtZmTRTyItyAa58nKZLBbUNBUZvpI=
=2xab
-----END PGP SIGNATURE-----
--nlOhHaQaIAx3ERUjxEHs5df9ukLH5unD1--
|
