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
|
Return-Path: <icesby24@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id EEB29907
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jan 2018 08:45:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f176.google.com (mail-qt0-f176.google.com
[209.85.216.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 70C1AE7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jan 2018 08:45:12 +0000 (UTC)
Received: by mail-qt0-f176.google.com with SMTP id g14so7084952qti.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jan 2018 00:45:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=5PTBLzgLRd7xswiQ97gclEPTxJBfxW0eL3MAj9scpks=;
b=JdSw3rUGU97wz+jUoB+ct+V4sNKUB5FNAp+RA7U+yXVaWCo6UzeS8Xgn5K4jSQ+9Cy
b6tVh189ZHqn1x+LXoEn86Zn7mVvyOtSxEDfonhlWbD6cti6U5/BgMFcdLP6FuByoR6j
kKxFPZ7Sq1pyQF3mj6P4PFGfqM0Eb7HsH6qPST65JfB1lRAzBqWmaiDp/6HPkpsJMdtn
9SaShWyRXAspyWM+BSnC/RMWVqImZzyQLgtjxC9WclPsGVyyN1dytHt9z0awklaekucZ
v2k2xo/+x6RiSYMtiqJ27TRDg7NhWyqSDFa86eSF06uSj+hpb+Ct30wDlezzNKdfJ8PZ
ZCBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=5PTBLzgLRd7xswiQ97gclEPTxJBfxW0eL3MAj9scpks=;
b=lbv22/wRhRT6C1QAhrlXUkVXpWv2sI94aVZ/SoyYeDzBC2m3BsCE0w4td0LiyQgzGn
6H0HbfadMuQJZOf44IbazHKMX1oXQAnDk+2sXWAjxVWstJoGZGURZzSEnTuk0BmdMJxh
CbtCjwCLCI7dwekrpun1GhsPg7GMjjLGQaHpejTHQHuGPH/t5tjaKToasp5GX29gKi+a
dDnfKMySadhBnU6b9nIA9I9/oqsCbIU8QkhTYnB/L8A2AXCmClmSiYO+7I7jPEKEnuQs
cbczun2OjTmWSE7uMRUx1NADZwfHrIa8LiptQCkazYU3zTQNTg+xfYWQpAxPX9OBwpUp
9ENA==
X-Gm-Message-State: AKwxytdkOqOvdMgpTHILyoXmPIRlq+pAJ8uCEyLtVMxtviXU7Umlx2Ri
vgdrCTLqIf/yoGbpXdN/nOU9w6zGAFsO4dB80ZgYNg==
X-Google-Smtp-Source: AH8x225v3/MDiQ3zkdahBMFF5wrwSBlEeb+Dbe1JE7Jrlzs0EMKOBz08EGVU/T/nzX+86nL81KsYWeqh3GglmR32b+s=
X-Received: by 10.237.48.106 with SMTP id 97mr27836028qte.48.1517042711364;
Sat, 27 Jan 2018 00:45:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.237.36.185 with HTTP; Sat, 27 Jan 2018 00:45:10 -0800 (PST)
From: Nathan Parker <icesby24@gmail.com>
Date: Sat, 27 Jan 2018 09:45:10 +0100
Message-ID: <CAPzrG5bFTbRERHQsmyFeZwiuakgSW5UCC8EtYfAm4j9EDtcLeg@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="94eb2c0cabe8eb89de0563be07af"
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
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: Sat, 27 Jan 2018 18:54:04 +0000
Subject: [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: Sat, 27 Jan 2018 08:45:13 -0000
--94eb2c0cabe8eb89de0563be07af
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 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, 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
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 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.
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 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.
--94eb2c0cabe8eb89de0563be07af
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<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>
--94eb2c0cabe8eb89de0563be07af--
|
