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
|
Return-Path: <lvella@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id AC183FA1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jan 2018 16:54:58 +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 CE2AF32F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jan 2018 16:54:57 +0000 (UTC)
Received: by mail-wm0-f43.google.com with SMTP id g1so9777713wmg.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jan 2018 08:54:57 -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=US/kLuJ7FsfZuIJSLTM65omxE6KwUdaTrpPvGNd0Ag0=;
b=By2zKIK8X9BTt4BZ7VZsuLPUdxjLJiGaOftEDi7hTnyxDh37ambzho8kIq0L4hos99
NPRqDEyeGddJKtZMOhCJJ0kqZ9cYZTJ30dernh8U1QcCUUxEScfVGS5t8VpLUIN6fqJ3
fAyUtpuzRw9R2mQOw7/GZozR5JPvchGWviP2ZhdzAskEucP5xyx8+xPwDV3VXqrHP9wE
k+JdARqj14JF/h+VqtXZONzWD5inC77wvFtzaxGjspH8aBh57WwgBUuBu6yx7Z9xJ90u
RppaZHH7E2rL4H4xb4qfbJ8ODTV4JuaNIy4JsQ9KHQr3P1NkSub5qEivYF9xfMFVma8Y
y0jw==
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=US/kLuJ7FsfZuIJSLTM65omxE6KwUdaTrpPvGNd0Ag0=;
b=uRdDQg/KYkFnDMyoXtpmRZcddEOXTMU3co4Ekrz7gAc3WBSxbn0TTTvhCKZC6G6rMt
71kOIlr2RgoYz5CnxjR4sOVZUkgd5lmHgU3Kx06JWbc86eF46b1pkNRyo8coxxtBD0M+
7MchgaazuNeO0097yKoxq/H12HPms35dhCevsiEv2CarOBF0ksK2Q8H/WHUbDvIUt4tT
4OgYcfgqQpYqqiw36kwd03pmCNrVYpsyDZ5svx2OgECj/v3kNqAuAhjf+o0O1tRG/Ud4
rs7Tr0C3MdS/A0nCQqpJKk1ePxwZ3ueiIS7i+wnJ70V4Zbi3i4KnmirLZqH/9aDSXKRn
GLCA==
X-Gm-Message-State: AKwxyteuSH1kPuqFoC+qYWoXa1TtJrVbMa3Ep6QyHZd7jrosdVKG2UJk
+CI5HJzR1otupLqMNmV9de3v0zDhwO7IF3p2344=
X-Google-Smtp-Source: AH8x2242wwQoJcVynAPyQFRiLKMuhn7NIHPkKBncvgb9yQ+CtzIZ7jREONXW1pGRem9qpUASYKKOnQA+elTewZNZZEc=
X-Received: by 10.28.54.157 with SMTP id y29mr17043908wmh.36.1517158496396;
Sun, 28 Jan 2018 08:54:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.210.198 with HTTP; Sun, 28 Jan 2018 08:54:36 -0800 (PST)
In-Reply-To: <CAPzrG5bFTbRERHQsmyFeZwiuakgSW5UCC8EtYfAm4j9EDtcLeg@mail.gmail.com>
References: <CAPzrG5bFTbRERHQsmyFeZwiuakgSW5UCC8EtYfAm4j9EDtcLeg@mail.gmail.com>
From: Lucas Clemente Vella <lvella@gmail.com>
Date: Sun, 28 Jan 2018 14:54:36 -0200
Message-ID: <CAGCathyVqQcBCKORQebicWq+OQfKZVLXb0g_9QHBu2e-jqYBgg@mail.gmail.com>
To: Nathan Parker <icesby24@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a114364243eec330563d8fd94"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
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: Sun, 28 Jan 2018 17:01:08 +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: Sun, 28 Jan 2018 16:54:58 -0000
--001a114364243eec330563d8fd94
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 n=
o
> cost because they get the fees back to themselves. They can do this for
> 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 mine=
r
> of the next block (or X blocks after the current one). That way, if a min=
er
> 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 coul=
d
> 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 clai=
m
> 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 secondar=
y
> 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 t=
he
> 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 g=
et 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 bloc=
ks
> 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
>
>
--=20
Lucas Clemente Vella
lvella@gmail.com
--001a114364243eec330563d8fd94
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">If the miner wants to force fees up, why would he fill up =
a block with placeholder high fee transactions, instead of simply cutting o=
ff transactions paying less fee than he is willing to take? Is there any ev=
idence someone is doing such a thing for whatever reason?<br></div><div cla=
ss=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:bitc=
oin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linu=
xfoundation.org</a>></span>:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-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">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><br clear=3D"all"><br>-- <br><div class=3D"gmail=
_signature" data-smartmail=3D"gmail_signature">Lucas Clemente Vella<br><a h=
ref=3D"mailto:lvella@gmail.com" target=3D"_blank">lvella@gmail.com</a></div=
>
</div>
--001a114364243eec330563d8fd94--
|
