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
|
Return-Path: <anthony.j.towns@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A6D828C8
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Aug 2015 18:22:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com
[209.85.212.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4A9C830
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Aug 2015 18:22:52 +0000 (UTC)
Received: by wicgj17 with SMTP id gj17so71183308wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 07 Aug 2015 11:22:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:cc:content-type;
bh=x5SCZj2UQyxLIFPwDSiIwDTGOeFe8G7l2ooEsAu5Vbk=;
b=MpW+DgfqcYOrmHBO55AWyHglRolxJuMVPFlxwVrpDbSUVZsqrdcnbJYAmWVYckzpM4
NiOn5Za2NKH75wga/lWiDCRicWxehMr0TnOZzYkNEtrmJ0jNV7KAJX308I0BHVGtaYaB
YbH9D96fGgcKXf/sYMcWeVpKAMaqXgBrVEEbDMQnrXg14HJMIKneadEYYp79h/nzg5/8
IWZCnLNz9bIFZHFNrQRvaCpdtldIQR7O3j+l1pB1RTh+A1LFv4pzIW9fP9zNSnPDUNsB
xU1H5ouPWBvNxzIjoh2IiIGLtFiUoOJlYXLJu/PZcSKdvFCvp4l2vgO1YbwPFWNzA+hW
5YsQ==
MIME-Version: 1.0
X-Received: by 10.194.87.69 with SMTP id v5mr16981079wjz.140.1438971770670;
Fri, 07 Aug 2015 11:22:50 -0700 (PDT)
Sender: anthony.j.towns@gmail.com
Received: by 10.28.176.69 with HTTP; Fri, 7 Aug 2015 11:22:50 -0700 (PDT)
In-Reply-To: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com>
References: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com>
Date: Sat, 8 Aug 2015 04:22:50 +1000
X-Google-Sender-Auth: NPI6skb4lVcToM0jSoRiQUTv-jk
Message-ID: <CAJS_LCVQBXqTs0KvDG_A3ranBC8yM8dphcm5wUWges2Xx=6FjQ@mail.gmail.com>
From: Anthony Towns <aj@erisian.com.au>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=089e0102dfe23b9630051cbcb990
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham
version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fees and the block-finding process
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Fri, 07 Aug 2015 18:22:53 -0000
--089e0102dfe23b9630051cbcb990
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 8 August 2015 at 00:57, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I answered:
>
>> > 1. If you are willing to wait an infinite amount of time, I think the
>> > minimum fee will always be zero or very close to zero, so I think it's=
a
>> > silly question.
>
> That's not what I'm thinking. It is just an observation based on the fact
> that blocks are found at random intervals.
>
Every once in a while the network will get lucky and we'll find six blocks
> in ten minutes. If you are deciding what transaction fee to put on your
> transaction, and you're willing to wait until that
> six-blocks-in-ten-minutes once-a-week event, submit your transaction with=
a
> low fee.
>
All the higher-fee transactions waiting to be confirmed will get confirmed
> in the first five blocks and, if miners don't have any floor on the fee
> they'll accept (they will, but lets pretend they won't) then your
> very-low-fee transaction will get confirmed.
>
=E2=80=8BThat depends a bit on how ra=E2=80=8Btional miners are, doesn't it=
? Once the block
subsidy is retired, hashpower is only paid for by fees -- and if there's no
fee paying transactions in the queue, then there's no reward for applying
hashpower, so mining a block won't even pay for your costs. In that case,
better to switch to hatching something else (an altcoin with less fees than
bitcoin has on average but more than nothing, eg), or put your hashing
hardward into a low power mode so you at least cut costs.
That will only be needed for a short while though -- presumably enough
transactions will come in in the next five or ten minutes for a block to be
worth mining again, so maybe implementing that decision process is more
costly than the money you'd save.
=E2=80=8B(C=E2=80=8B
onversely, when the queue is over-full because there's been no blocks found
for a while, that should mean you can fill a block with higher-than-average
fee transactions, so I'd expect some miners to switch hashpower from
altcoins and sidechains to catch the temporary chance of higher revenue
blocks.
=E2=80=8BBoth tendencies would help reduce the variance in block time, comp=
ared to
a steady hashrate, which would probably be a good thing for the network as
a whole)=E2=80=8B
I think the same incentives apply with mining being paid for by assurance
contracts rather than directly by transaction fees -- if you get a bunch of
blocks done quickly, the existing assurance contracts are dealt with just
as well as if it had taken longer; so you want to wait until new ones come
in rather than spend your hashpower for no return.
=E2=80=8BAll of this only applies once fees make up a significant portion o=
f the
payment for mining a block, though.=E2=80=8B
Cheers,
aj
--=20
Anthony Towns <aj@erisian.com.au>
--089e0102dfe23b9630051cbcb990
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e"><span style=3D"font-family:arial,sans-serif">On 8 August 2015 at 00:57, =
Gavin Andresen via bitcoin-dev </span><span dir=3D"ltr" style=3D"font-famil=
y:arial,sans-serif"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span=
><span style=3D"font-family:arial,sans-serif"> wrote:</span><br></div><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><div>I answered:=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
>=C2=A01. If you are willing to wait an infinite amount of time, I think=
the<br>
> minimum fee will always be zero or very close to zero, so I think it&#=
39;s a<br>
> silly question.</span></blockquote><div>That's not what I'm th=
inking. It is just an observation based on the fact that blocks are found a=
t random intervals.=C2=A0</div></div></div></div></blockquote><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D=
"gmail_quote"><div></div><div>Every once in a while the network will get lu=
cky and we'll find six blocks in ten minutes. If you are deciding what =
transaction fee to put on your transaction, and you're willing to wait =
until that six-blocks-in-ten-minutes once-a-week event, submit your transac=
tion with a low fee.=C2=A0</div></div></div></div></blockquote><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><div>All the higher-fee transactions waiting to be confirm=
ed will get confirmed in the first five blocks and, if miners don't hav=
e any floor on the fee they'll accept (they will, but lets pretend they=
won't) then your very-low-fee transaction will get confirmed.</div></d=
iv></div></div></blockquote><div><br></div><div><div class=3D"gmail_default=
" style=3D"font-family:monospace">=E2=80=8BThat depends a bit on how ra=E2=
=80=8Btional miners are, doesn't it? Once the block subsidy is retired,=
hashpower is only paid for by fees -- and if there's no fee paying tra=
nsactions in the queue, then there's no reward for applying hashpower, =
so mining a block won't even pay for your costs. In that case, better t=
o switch to hatching something else (an altcoin with less fees than bitcoin=
has on average but more than nothing, eg), or put your hashing hardward in=
to a low power mode so you at least cut costs.</div><div class=3D"gmail_def=
ault" style=3D"font-family:monospace"><br></div><div class=3D"gmail_default=
" style=3D"font-family:monospace">That will only be needed for a short whil=
e though -- presumably enough transactions will come in in the next five or=
ten minutes for a block to be worth mining again, so maybe implementing th=
at decision process is more costly than the money you'd save.</div><div=
class=3D"gmail_default" style=3D"font-family:monospace"><br></div><div cla=
ss=3D"gmail_default" style=3D"font-family:monospace"><div class=3D"gmail_de=
fault" style=3D"display:inline">=E2=80=8B(C=E2=80=8B</div>onversely, when t=
he queue is over-full because there's been no blocks found for a while,=
that should mean you can fill a block with higher-than-average fee transac=
tions, so I'd expect some miners to switch hashpower from altcoins and =
sidechains to catch the temporary chance of higher revenue blocks.=C2=A0<di=
v class=3D"gmail_default" style=3D"display:inline">=E2=80=8BBoth tendencies=
would help reduce the variance in block time, compared to a steady hashrat=
e, which would probably be a good thing for the network as a whole)=E2=80=
=8B</div><br></div></div><div><div class=3D"gmail_default" style=3D"font-fa=
mily:monospace"><br></div><div class=3D"gmail_default" style=3D"font-family=
:monospace">I think the same incentives apply with mining being paid for by=
assurance contracts rather than directly by transaction fees -- if you get=
a bunch of blocks done quickly, the existing assurance contracts are dealt=
with just as well as if it had taken longer; so you want to wait until new=
ones come in rather than spend your hashpower for no return.</div><br></di=
v><div><div class=3D"gmail_default" style=3D"font-family:monospace">=E2=80=
=8BAll of this only applies once fees make up a significant portion of the =
payment for mining a block, though.=E2=80=8B</div></div><div><br></div><div=
><div class=3D"gmail_default" style=3D"font-family:monospace">Cheers,</div>=
</div><div class=3D"gmail_default" style=3D"font-family:monospace">aj</div>=
</div><div><br></div>-- <br><div class=3D"gmail_signature">Anthony Towns &l=
t;<a href=3D"mailto:aj@erisian.com.au" target=3D"_blank">aj@erisian.com.au<=
/a>></div>
</div></div>
--089e0102dfe23b9630051cbcb990--
|
