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
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 93E969B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Aug 2015 15:16:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f180.google.com (mail-io0-f180.google.com
[209.85.223.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D485614D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Aug 2015 15:16:34 +0000 (UTC)
Received: by iodd187 with SMTP id d187so114627323iod.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 07 Aug 2015 08:16:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=vCpRgbqpEFXkE6L+Wl4jnP6NyDPfJoIIOSG/dWOhmyo=;
b=tyAj6rXABKG8mvXfdv+G2KuIfELQ4keaEzvdi9OSOHmRXdZSz/VXnCR7HYEj9vokNU
ELTEDjN9XgyT4L7XLuwXAPm78dtaQ/5lIHgKmHvXCwxvoAU1pA2O/qH99eS3coXJh0KE
/SXrhJVdQLK0RzXXvSJcGRX069AE5KH6QrjWwAWZLgox2eb0WoGRKHqz0js/eh2TAq0c
kPxzzwgNH6Z1z7ouHsBoLdsFNPgNI1bznDXrwvh9dbyIrB70VISpQkHBpHJmXh5Bg+F9
ZtCeLAy9DWfdjUAmS+O/xJxpiLiqR3Ub5tBoY+5dmveyXvdAJwKjYPcB6U9ZafjM4QT0
ObWw==
MIME-Version: 1.0
X-Received: by 10.107.37.142 with SMTP id l136mr8525066iol.126.1438960594186;
Fri, 07 Aug 2015 08:16:34 -0700 (PDT)
Received: by 10.36.77.201 with HTTP; Fri, 7 Aug 2015 08:16:34 -0700 (PDT)
In-Reply-To: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com>
References: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com>
Date: Fri, 7 Aug 2015 17:16:34 +0200
Message-ID: <CAPg+sBgOt=qhQVZv5P-4mcD75=L4PKgOfRqhyB6FZdSYQajrwQ@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=001a1140269a0ff900051cba1f40
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,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 15:16:35 -0000
--001a1140269a0ff900051cba1f40
Content-Type: text/plain; charset=UTF-8
On Fri, Aug 7, 2015 at 4:57 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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.
>
> In the limit, that logic becomes "wait an infinite amount of time, pay
> zero fee."
>
That's only the case when the actual rate of transactions with a non-zero
fee is below what fits in blocks. If the total production rate is higher,
even without configured floor by miners, a free transaction won't ever be
mined, as there will always be some backlog of non-free transaction. Not
saying that this is a likely outcome - it would inevitably mean that people
are creating transactions without any guarantee that they'll be mined,
which may not be what anyone is interested in. But perhaps there is some
"use" for ultra-low-priority unreliable transactions (... despite DoS
attacks).
>
> So... I have no idea what the 'market minimum fee' will be, because I have
> no idea how long people will be willing to wait, how many times they'll be
> willing to retransmit a low-fee transaction that gets evicted from
> memory-limited memory pools, or how much memory miners will be willing to
> dedicate to storing transactions that won't confirm for a long time because
> they're waiting for a flurry of blocks to be found.
>
Fair enough, I don't think anyone knows.
I guess my question (and perhaps that's what Jorge is after): do you feel
that blocks should be increased in response to (or for fear of) such a
scenario. And if so, if that is a reason for increase now, won't it be a
reason for an increase later as well? It is my impression that your answer
is yes, that this is why you want to increase the block size quickly and
significantly, but correct me if I'm wrong.
--
Pieter
--001a1140269a0ff900051cba1f40
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
On Fri, Aug 7, 2015 at 4:57 PM, Gavin Andresen via bitcoin-dev <span dir=3D=
"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Every once in a while the n=
etwork 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'r=
e willing to wait until that six-blocks-in-ten-minutes once-a-week event, s=
ubmit your transaction with a low fee.<div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><div><br></div><div>All the higher-fee transactions waitin=
g to be confirmed will get confirmed in the first five blocks and, if miner=
s don't have any floor on the fee they'll accept (they will, but le=
ts pretend they won't) then your very-low-fee transaction will get conf=
irmed.</div><div><br></div><div>In the limit, that logic becomes "wait=
an infinite amount of time, pay zero fee."</div></div></div></div></b=
lockquote><div><br></div><div>That's only the case when the actual rate=
of transactions with a non-zero fee is below what fits in blocks. If the t=
otal production rate is higher, even without configured floor by miners, a =
free transaction won't ever be mined, as there will always be some back=
log of non-free transaction. Not saying that this is a likely outcome - it =
would inevitably mean that people are creating transactions without any gua=
rantee that they'll be mined, which may not be what anyone is intereste=
d in. But perhaps there is some "use" for ultra-low-priority unre=
liable transactions (... despite DoS attacks).<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><div><br></div><div>So... I have no idea what the 'market min=
imum fee' will be, because I have no idea how long people will be willi=
ng to wait, how many times they'll be willing to retransmit a low-fee t=
ransaction that gets evicted from memory-limited memory pools, or how much =
memory miners will be willing to dedicate to storing transactions that won&=
#39;t confirm for a long time because they're waiting for a flurry of b=
locks to be found.<br></div></div></div></div></blockquote><div><br></div><=
div>Fair enough, I don't think anyone knows.<br><br></div><div>I guess =
my question (and perhaps that's what Jorge is after): do you feel that =
blocks should be increased in response to (or for fear of) such a scenario.=
And if so, if that is a reason for increase now, won't it be a reason =
for an increase later as well? It is my impression that your answer is yes,=
that this is why you want to increase the block size quickly and significa=
ntly, but correct me if I'm wrong. <br><br>-- <br></div><div>Pieter<br>=
<br></div></div></div></div>
--001a1140269a0ff900051cba1f40--
|
