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
|
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 71C70EFD
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jan 2018 19:06:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f48.google.com (mail-vk0-f48.google.com
[209.85.213.48])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D6F31E7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jan 2018 19:06:43 +0000 (UTC)
Received: by mail-vk0-f48.google.com with SMTP id j204so2232531vke.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jan 2018 11:06:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to:content-transfer-encoding;
bh=3R+f1EvhoCEV03adjGoUGiAHDHFoAyQh1OwpOAzx6Ss=;
b=hZGht4qkYKkRLgcwX57ATm+FAtMQLzdFiWGO/ZypCMS6SgQc2E1Wz6znqHx1peAvSL
MHtQx1z18X0euQ/3juxIa7DklR0SiyDm9jZEFW1euemgp2aeT5drWDJzSNglxr5mPpeL
Q3zsFBTkw3HK+GYeXD4XgFaPPSD0SS/T2UzGy/s3PLm1FdfSGnDFxg38B4VcgF2v8ZuR
d4I6Pk5dTVufBCZbVRrdq7Wx7R0rVfqxNzMpMbbIuiMC1cdSqCUkvi6qaEDe/mgt+mFC
aakuj9hiS18sHioW00OB5ktF2CEPJovlNu8is/rVrw6BwklsyTdtj1kHbuE3Wh8Oqowq
vEyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to:content-transfer-encoding;
bh=3R+f1EvhoCEV03adjGoUGiAHDHFoAyQh1OwpOAzx6Ss=;
b=THJa+0uoBvuEaEXtuuTrQ+6EKtty5nJM1HJboJBQXdeu3TsPV82jg7xF0w4+Bs8q+0
PXaDnMxPA3wYC0aZWpZGZQRjtU7pu+vAowNRgsRaKhMohTKVrdU4rTmuruPL6hR7GMg2
9SvqgiwUf4u380N01+UNH91KDXE028gf/OiG5OAUhNxKOBPu7jgeE04lnBlMFr/Gkmc5
UgSVtEgpZMLsE9x5LGzkL4R1C3NIIxobA1Hh/lBNdod6FPiQTXoywNvfTfa0r+ZPK9Kz
E2an2tZ1SB2NlaOqc7PLf0tzWpul/fMqh/zWlXOVSZjtL8EdsdCOS61LSkiawNqKya9+
eWuQ==
X-Gm-Message-State: AKwxytc3OHK9GrGY9cI0r7K2kXinsPxS+BMYzWrilVT7fEVp5QWYNh+g
oM55+5vwv173E2ft+jpSj4bBtpiGB/DtdXnDZhs=
X-Google-Smtp-Source: AH8x227lPsmDnUsw39LFqtHdML61E4j8wPCQBIeUE4eNjIKbu5c1XkH1CI6EbwGnOeNaBqPHxafK9RW44GgdR81q7qw=
X-Received: by 10.31.195.196 with SMTP id t187mr13138595vkf.182.1517080002953;
Sat, 27 Jan 2018 11:06:42 -0800 (PST)
MIME-Version: 1.0
Sender: gmaxwell@gmail.com
Received: by 10.103.78.155 with HTTP; Sat, 27 Jan 2018 11:06:41 -0800 (PST)
In-Reply-To: <CAPzrG5bFTbRERHQsmyFeZwiuakgSW5UCC8EtYfAm4j9EDtcLeg@mail.gmail.com>
References: <CAPzrG5bFTbRERHQsmyFeZwiuakgSW5UCC8EtYfAm4j9EDtcLeg@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Sat, 27 Jan 2018 19:06:41 +0000
X-Google-Sender-Auth: Ht2aOHBFr7Yn_hVHuXb2oHZDw7Y
Message-ID: <CAAS2fgSzx_beEQqPOdoRJRVMSk0JNT6LGk0fHTktVSCU7sH1cA@mail.gmail.com>
To: Nathan Parker <icesby24@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, FREEMAIL_FROM,
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
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: Sat, 27 Jan 2018 19:06:44 -0000
Not incentive compatible. Miners would prefer to include transactions
paying fees via alternative mechanisms (anyone can spend outputs,
direct pay to miner outputs, or completely out of band), if they even
paid attention to internal fees at all they would give a lot more
weight to direct payment fees. Users would accordingly pay much lower
fees if they used these alternatives instead of directly, so the
equlibrium state is almost everyone bypassing. Bypass fee mechenisms
have been supported by miners since 2011 too, so it isn't just
conjecture.
On Sat, Jan 27, 2018 at 8:45 AM, Nathan Parker via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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 transact=
ion
> of the block (by adding this as a rule for verifying new blocks). The min=
er
> of 100 blocks after the current one can add a secondary transaction spend=
ing
> 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+1=
00.
>
> Implementing this would require a soft-fork. Since that secondary
> transaction needs no signature whatsoever, the overhead caused by that ex=
tra
> 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
>
|
