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
259
260
261
262
263
264
265
|
Return-Path: <gbalch714@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id EBD67EC9
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 29 Jan 2018 01:44:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0182C108
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 29 Jan 2018 01:44:09 +0000 (UTC)
Received: by mail-wm0-f43.google.com with SMTP id f71so11129853wmf.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jan 2018 17:44:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=iKuQEbRJh+Ali+7bCNjvJpCwQjit/K2p6ftgnxBWWJU=;
b=SSce7MVE2KiXvDVvg6ifMemRto31p4SrS81ClUtOrodGzFuydL7tBZqSHkRCF8vriF
ZQOcRNbqEPMNCv+0UyXbYgJrHlmC10F1qZGgzduzwNg86XTyaYFbvZDH3yr2F7GydBXg
1iaDZkaxR48rPV6mI9swKH2v58heInAum0/sAT3I1Z+VULYApnlRlD469PvHP/AacvX6
PJ7SNKhfI0rSVDPJw36zId6dyNaew+8sxtvPTRLaPL+Nlfw7CJMM8x0Q3AQlfIN0qX9l
i1CKi36ixNpQQ59FnjyagobWU9R+icjsYOnxymjId1aluDynINHQ1G5vVxQ9FBnBSYPJ
AF9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=iKuQEbRJh+Ali+7bCNjvJpCwQjit/K2p6ftgnxBWWJU=;
b=YAJl2V6JrqlJ9OMJW2gKCofbLy+JTeN2eq6MP/M0IOeLyHih7IelN5OfukJfOYq5yC
OSeDqo1qD9HUg6IMaDLnWyOnGlvVIkuVyzaFhdqn358R8pe7jpu5XjeyCT3t77yAROnd
f90RUqkInuEXvBC5rMFhoXlgCgmqiXkiLlFa2uNxM+Afl/iteReAPnIplH353C0nv00Q
xYx5qj1KK4EQ3/B++lrJ7GErXJQTxIugswrWhvhf+wcOzU2ghRpzMMX3DK/Ib9ASL0g1
J4GwGwP4SPLBPqgig3r29ofsXeUX42dgwOWmHb0KEMzYk6qUSeu2GAnOsD93ci7nKIba
+BEA==
X-Gm-Message-State: AKwxytfmbMrWV0ct6ZP2so9WJm+JA2EwYBgTaxz1d9pu6+SyJxwbusuq
kaIQmB3SaMIA9F3cA8yt6AXohgtLYdy811G2LhI=
X-Google-Smtp-Source: AH8x226DZWPeIWA+9G5QQ7lU/6O2RSmSsiBYomWud6cn0lDbxT9z3JeulOHh+7QabQe/+/CWXrB+OEwB9QFmYAW1noQ=
X-Received: by 10.80.215.222 with SMTP id m30mr44686307edj.296.1517190248546;
Sun, 28 Jan 2018 17:44:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.80.157.13 with HTTP; Sun, 28 Jan 2018 17:44:08 -0800 (PST)
In-Reply-To: <CAGCathyVqQcBCKORQebicWq+OQfKZVLXb0g_9QHBu2e-jqYBgg@mail.gmail.com>
References: <CAPzrG5bFTbRERHQsmyFeZwiuakgSW5UCC8EtYfAm4j9EDtcLeg@mail.gmail.com>
<CAGCathyVqQcBCKORQebicWq+OQfKZVLXb0g_9QHBu2e-jqYBgg@mail.gmail.com>
From: George Balch <gbalch714@gmail.com>
Date: Sun, 28 Jan 2018 17:44:08 -0800
Message-ID: <CAC94VgAoZFwu4TC8CdNP9cbxUiFgQP4bOsXykJyb4+8y-eSY1Q@mail.gmail.com>
To: Lucas Clemente Vella <lvella@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="94eb2c1aed76d246fc0563e06162"
X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
FREEMAIL_REPLY, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=no 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 02:17:46 +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 01:44:11 -0000
--94eb2c1aed76d246fc0563e06162
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
If miners leave transactions out of a block they do pay a cost by not being
rewarded those fees. If they include their own spam transactions to get
back the fee they gain nothing. 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.
On Sun, Jan 28, 2018 at 8:54 AM, Lucas Clemente Vella via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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>:
>
>> 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 f=
or
>> different purposes, like trying to increase the recommended fee. Here I
>> propose a backwards-compatible solution to this problem.
>>
>> The solution would be to reward the fees of the current block to the
>> miner of the next block (or X blocks after the current one). That way, i=
f a
>> miner floods its own block with very high fee transactions, those fees a=
re
>> 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 this reward.
>>
>> 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 seconda=
ry
>> 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.
>>
>> Implementing this would require a soft-fork. Since that secondary
>> transaction needs no signature whatsoever, the overhead caused by that
>> extra transaction is negligible.
>>
>> 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 t=
o
>> power off the mining equipment for maintenance or to save power over tha=
t
>> 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 blo=
cks
>> as soon as possible so they can start getting rewards from mining again.
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
> --
> Lucas Clemente Vella
> lvella@gmail.com
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--94eb2c1aed76d246fc0563e06162
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">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=
transactions 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 unl=
ikely that miners incur a huge cost for not including transactions.<br></di=
v><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, Jan 28,=
2018 at 8:54 AM, Lucas Clemente Vella via bitcoin-dev <span dir=3D"ltr">&l=
t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank=
">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr">If the miner wants to force fees up, =
why would he fill up a block with placeholder high fee transactions, instea=
d 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 reas=
on?<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2018=
-01-27 6:45 GMT-02:00 Nathan Parker via bitcoin-dev <span dir=3D"ltr"><<=
a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b=
itcoin-dev@lists.<wbr>linuxfoundation.org</a>></span>:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr">
<p class=3D"MsoNormal" style=3D"margin:0in 0in 8pt;line-height:107%;font-si=
ze:11pt;font-family:"Calibri",sans-serif">Miners
can fill their blocks with transactions paying very high fees at no=20
cost because they get the fees back to themselves. They can do this for=20
different
purposes, like trying to increase the recommended fee. Here I propose a
backwards-compatible solution to this problem.<span></span></p>
<p class=3D"MsoNormal" style=3D"margin:0in 0in 8pt;line-height:107%;font-si=
ze:11pt;font-family:"Calibri",sans-serif">The solution would be t=
o reward the fees of the current
block to the miner of the next block (or X blocks after the current one). T=
hat
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 dis=
couraged.
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.<span></span></p>
<p class=3D"MsoNormal" style=3D"margin:0in 0in 8pt;line-height:107%;font-si=
ze:11pt;font-family:"Calibri",sans-serif">The way to implement th=
is in a backwards-compatible fashion
would be to enforce miners to set an anyone-can-spend output in the coinbas=
e
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 bl=
ock
reward of a block X is always transferred to the miner of block X+100.<span=
></span></p>
<p class=3D"MsoNormal" style=3D"margin:0in 0in 8pt;line-height:107%;font-si=
ze:11pt;font-family:"Calibri",sans-serif">Implementing this would=
require a soft-fork. Since that
secondary transaction needs no signature whatsoever, the overhead caused by
that extra transaction is negligible.</p><p class=3D"MsoNormal" style=3D"ma=
rgin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri&=
quot;,sans-serif"><span></span></p>
<p class=3D"MsoNormal" style=3D"margin:0in 0in 8pt;line-height:107%;font-si=
ze:11pt;font-family:"Calibri",sans-serif">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 of=
f
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, b=
locks would
take much longer to mine, and miners wouldn=E2=80=99t want that either sinc=
e they want
to go through those 100 reward-less blocks as soon as possible so they can =
start
getting rewards from mining again.</p>
<br></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
<br></blockquote></div><span class=3D"HOEnZb"><font color=3D"#888888"><br><=
br clear=3D"all"><br>-- <br><div class=3D"m_-205159485612516142gmail_signat=
ure" data-smartmail=3D"gmail_signature">Lucas Clemente Vella<br><a href=3D"=
mailto:lvella@gmail.com" target=3D"_blank">lvella@gmail.com</a></div>
</font></span></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>
--94eb2c1aed76d246fc0563e06162--
|
