summaryrefslogtreecommitdiff
path: root/33/e5e26cf5f40f09889c0d507573eaaa7e91236a
blob: 03b35430eb0d548aa4cd674ebfdaec1ca5e509bc (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
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
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
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 D130813AE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 29 Jan 2018 04:49:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f193.google.com (mail-pf0-f193.google.com
	[209.85.192.193])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3B2F3149
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 29 Jan 2018 04:49:11 +0000 (UTC)
Received: by mail-pf0-f193.google.com with SMTP id e76so3926048pfk.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 28 Jan 2018 20:49:11 -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=b8P6PDGy/3iLIvHZ1wf6sCARCk8848ciAhJvptdZAXA=;
	b=mhIey8k4p//ZS6jLcYl5i1o+f+gJvKTSBONk4u3UKy2WRtVjFs86Rj5dwWsTLmoNo/
	NoXEV9VmLPknCq+3OFVpu6oqsrhf9ZVDcvQPZt3mzarE5m/VC/WL5NiIGwOjsE9bx/yQ
	q2hEl1EpZmsX5tBfJysIV9GC4uQ9Ofp1i9+zdnVFxZ0ZoJZsVwcpbGDHeS+Cy8SO6Ao5
	jmUao8230bnKoYgpGE6pwB9JgM2aZ3TtYPBUNbqmZI+ar0bMNAo8qbM2Wqr+0k9NGLfS
	21FyyWUEtXM8NxSe48Lf5BsV5O/NjXpNhFeiKS81kjF+Hoh/NxGQmEySuwrXvFwRO822
	D3Vg==
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=b8P6PDGy/3iLIvHZ1wf6sCARCk8848ciAhJvptdZAXA=;
	b=CIupgKsnj2uoGh1Z3mQ8i8V9AN2ZR0sUko/G+eszVX0oVhAFfb8uGi+jA4gy/ah9Lg
	CN1NV8wWKPt0Vt18C7Md75w8GHBk19m2v+oRnf96ik+FI+RNsoaWTXtq2sewLxDzzgxl
	PcXy+OVpYJVf4yAvT6ZjNSgdpWSGb24XTZYgcMah4gebeHrN18bsKMILyMUYXixNOu+k
	Qsj73cf9JDbhOIioBra7PpnkeNgGQEa+BCJVhoArjvXHJJC10RHOV2oIasczc50dW9If
	MzakkR/BH9hUDdXEy8Of2bE2tcb25dQD5odNCdDsOqUb0o65ZhaGGjYxAXfajj76aRIo
	eTBw==
X-Gm-Message-State: AKwxytdnTINkqKwrQcnnNl8sDO/rEuRCT6CCZdddFhIJI6WNYZRdkkf3
	aaIQZSKWWLOqPeyx3x5uTaj7zw==
X-Google-Smtp-Source: AH8x227bTsY2pB3LZYPFxvxpqZawhrJ7nXjxH2RN7RN6tS6+BO6RdT7TUyjU6A88ZM46xrRfKGvWRw==
X-Received: by 10.98.219.129 with SMTP id f123mr26039185pfg.51.1517201350630; 
	Sun, 28 Jan 2018 20:49:10 -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
	f72sm31970950pff.145.2018.01.28.20.49.09
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sun, 28 Jan 2018 20:49:09 -0800 (PST)
To: George Balch <gbalch714@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Lucas Clemente Vella <lvella@gmail.com>
References: <CAPzrG5bFTbRERHQsmyFeZwiuakgSW5UCC8EtYfAm4j9EDtcLeg@mail.gmail.com>
	<CAGCathyVqQcBCKORQebicWq+OQfKZVLXb0g_9QHBu2e-jqYBgg@mail.gmail.com>
	<CAC94VgAoZFwu4TC8CdNP9cbxUiFgQP4bOsXykJyb4+8y-eSY1Q@mail.gmail.com>
From: Eric Voskuil <eric@voskuil.org>
Message-ID: <261a9388-64fe-a664-85f0-4b0e8ca9ec1e@voskuil.org>
Date: Sun, 28 Jan 2018 20:49:10 -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: <CAC94VgAoZFwu4TC8CdNP9cbxUiFgQP4bOsXykJyb4+8y-eSY1Q@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="A9ZK34lsqffhzPy9uCdJBiveDnpXueW72"
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 20:32: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 20:04:01 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--A9ZK34lsqffhzPy9uCdJBiveDnpXueW72
Content-Type: multipart/mixed; boundary="UGKqaplFJrvsu3x3SNFrRvpGvCB0T1rOt";
 protected-headers="v1"
From: Eric Voskuil <eric@voskuil.org>
To: George Balch <gbalch714@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Lucas Clemente Vella <lvella@gmail.com>
Message-ID: <261a9388-64fe-a664-85f0-4b0e8ca9ec1e@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>
 <CAC94VgAoZFwu4TC8CdNP9cbxUiFgQP4bOsXykJyb4+8y-eSY1Q@mail.gmail.com>
In-Reply-To: <CAC94VgAoZFwu4TC8CdNP9cbxUiFgQP4bOsXykJyb4+8y-eSY1Q@mail.gmail.com>

--UGKqaplFJrvsu3x3SNFrRvpGvCB0T1rOt
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Your statements contradict each other.

This is not a question of whether it is a "huge" cost, but whether there
is an problem of incentive compatibility, which there is not. Miners
incur the opportunity cost of the space that they mine that does not
include the most optimal fees, which is equal in value to those forgone
fees.

If miners exclude available higher-fee transactions, or mine empty
space, or mine their own "recovery" transactions, they are merely
purchasing block space at market rates, just like everyone else.

The only difference is that they are getting nothing in return, while
everyone else is presumably getting a useful monetary transfer. In other
words, they are losing value to do this. Therefore the incentive is to
not do so. But again, the option to do so is perfectly incentive compatib=
le.

I'm not sure who cooked up this myth about miners gaining advantage over
those who buy block space by mining empty space, rejecting higher-fee
transactions, and/or mining "recovery" transactions, but the idea is
complete nonsense.

e

On 01/28/2018 05:44 PM, George Balch via bitcoin-dev wrote:
> If miners leave transactions out of a block they do pay a cost by not
> being rewarded those fees.=C2=A0 If they include their own spam transac=
tions
> to get back the fee they gain nothing.=C2=A0 Since blocks can have fees=

> resulting in hundreds of thousands of dollars, it would seem unlikely
> that miners incur a huge cost for not including transactions.
>=20
> On Sun, Jan 28, 2018 at 8:54 AM, Lucas Clemente Vella via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>=20
>     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 reaso=
n?
>=20
>     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=

>         fees at no cost because they get the fees back to themselves.
>         They can do this for different purposes, like trying to increas=
e
>         the recommended fee. Here I propose a backwards-compatible
>         solution to this problem.
>=20
>         The solution would be to reward the fees of the current block t=
o
>         the miner of the next block (or X blocks after the current one)=
=2E
>         That way, if a miner floods its own block with very high fee
>         transactions, those fees are no longer given back to itself, bu=
t
>         to the miner of future blocks which could potentially be anyone=
=2E
>         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 this reward.
>=20
>         The way to implement this in a backwards-compatible fashion
>         would be 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 new 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=99=
t 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
>     _______________________________________________
>     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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20


--UGKqaplFJrvsu3x3SNFrRvpGvCB0T1rOt--

--A9ZK34lsqffhzPy9uCdJBiveDnpXueW72
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)

iQEcBAEBAgAGBQJabqfGAAoJEDzYwH8LXOFOITsH/3vfwGsn0+9O7121tnbUSkk/
QbMKXSbvmzEqJBtHDx2w6ZbM3U3i78x0jNioRsRCBnAQkOxoZhlt1ZGwwjoaP9/8
bkaz6r1/04rC1StvvzE0dt+xLHfPHdeCDviN6CQ1/g3Xg9CgdIJ2t21KS/puDdG4
+JdaLwxOFeN1tTERNwgujbtzN/U+xNChbu1Y8eMdb2bYiFXVYuETqm5UT+r25IIx
xJiKq928odeBBSLNCxBG9E00WBE8srzWsuwLBkjbXU4o/iMbMK8uIpcksB2UWzSH
nnqHlGeX7rGTjysAD71VM5NWn2Upf7Hq0BpUFsVlxW3G7T3KkV1pdJcElmYha2k=
=kQ3c
-----END PGP SIGNATURE-----

--A9ZK34lsqffhzPy9uCdJBiveDnpXueW72--