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
|
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 BBCEE88B
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Aug 2015 22:52:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com
[209.85.213.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4615223F
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Aug 2015 22:52:24 +0000 (UTC)
Received: by igbpg9 with SMTP id pg9so79791682igb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Aug 2015 15:52:23 -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=yHrMcFo91lxpAB5u0SQVycN7rQnXLIRpUnrnflbiusU=;
b=VIFY2Z1GrGPU4dlIJm4+jcfUj2MDU9wi2XmvfYgYmPaDQTV+Z7Tsjbq8ymosN1/I0L
FWXHf+Mi1l4LlvdcR2K2HsMFKXgiaj9NSiH7XYNi5uXHveaZfrS1tJ+1r24S5Plx3s8G
afHJzg/YJeSXdLgx/fnnh5uPerMexcjxM1cas0TFKnJhih6oDBGxroDlgFRbiay/pLdf
t4fNID3Eajx03rBEEQZD/mRDvxddOfcaivtWR775rWpApHoIbgmS83PKFrrYY1KS46DG
qCLCfa/o3Bu2K44e61H1B0pycrnyf3xQdpugmfFqymBewJyEoAqwz9X9gFG65e4yeL1S
SdoA==
MIME-Version: 1.0
X-Received: by 10.50.134.226 with SMTP id pn2mr14997791igb.21.1439247143656;
Mon, 10 Aug 2015 15:52:23 -0700 (PDT)
Received: by 10.36.77.201 with HTTP; Mon, 10 Aug 2015 15:52:23 -0700 (PDT)
Received: by 10.36.77.201 with HTTP; Mon, 10 Aug 2015 15:52:23 -0700 (PDT)
In-Reply-To: <1472719.PaoH0O6gJe@coldstorage>
References: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com>
<CABsx9T2aZHe5382_fC7bEG2OFPadS3p0jjaAD8FW7p36XS7tcA@mail.gmail.com>
<CABm2gDqokER8=1PRW6u76BK4BgpDQZgbPw5_2HZztG1j6Mxg8A@mail.gmail.com>
<1472719.PaoH0O6gJe@coldstorage>
Date: Tue, 11 Aug 2015 00:52:23 +0200
Message-ID: <CAPg+sBhY1Suu961aCn8QB1qw0ps7zj4hhUzOup2MJH+dTrPkkw@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Thomas Zander <thomas@thomaszander.se>
Content-Type: multipart/alternative; boundary=047d7b2e148dbde492051cfcd6f4
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: Mon, 10 Aug 2015 22:52:24 -0000
--047d7b2e148dbde492051cfcd6f4
Content-Type: text/plain; charset=UTF-8
On Aug 11, 2015 12:18 AM, "Thomas Zander via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Have you ever been to a concert that was far away from public transport?
They
> typically set up bus shuttles, or taxis to get people back into town
> afterwards.
> The result there is always you end up waiting forever and it actually may
be
> easier to just walk instead of wait.
> The amount you pay is irrelevant if everyone is paying it. There still is
more
> demand than there is capacity.
That's an incorrect analogy. You choose the rate you pay, and get higher
priority when you pay more. Taxi drivers can't pick out higher-paying
customers in advance.
A better comparison is Uber, which charges more in places with high demand,
and you can accept or refuse in advance. And yes, it remains reliable if
you're among those with the highest willingness to pay.
> So, no, its not unreliable for cheap free transactions.
> Its unreliable for all types of transactions.
If 2500 transactions fit in the block chain per day (assuming constant
size) and there are less than 2500 per hour that pay at least 0.001 BTC in
fee, then any transaction which pays more than 0.001 BTC will have a very
high chance of getting in a small multiple of one hour, since miners
prioritize by feerate.
If there are in addition to that 5000 transactions per hour which pay less,
then yes, they need to compete for the remaiming space and their
confirmation will be unreliable.
The whole point is that whether confirmation at a particular price point is
reliable depends on how much demand there is at that price point. And
increasing the block size out of fear of what might happen is failing to
recognize that it can always happen that there is a sudden change in demand
that outcompetes the rest.
The point is not that evolution towards a specific higher feerate needs to
happen, but an evolution to an ecosystem that accepts that there is never a
guarantee for reliability, unless you're willing to pay more than everyone
else - whatever that number is.
--
Pieter
--047d7b2e148dbde492051cfcd6f4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On Aug 11, 2015 12:18 AM, "Thomas Zander via bitcoin-dev" <<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.lin=
uxfoundation.org</a>> wrote:</p>
<p dir=3D"ltr">> Have you ever been to a concert that was far away from =
public transport? They<br>
> typically set up bus shuttles, or taxis to get people back into town<b=
r>
> afterwards.<br>
> The result there is always you end up waiting forever and it actually =
may be<br>
> easier to just walk instead of wait.<br>
> The amount you pay is irrelevant if everyone is paying it. There still=
is more<br>
> demand than there is capacity.</p>
<p dir=3D"ltr">That's an incorrect analogy. You choose the rate you pay=
, and get higher priority when you pay more. Taxi drivers can't pick ou=
t higher-paying customers in advance.</p>
<p dir=3D"ltr">A better comparison is Uber, which charges more in places wi=
th high demand, and you can accept or refuse in advance. And yes, it remain=
s reliable if you're among those with the highest willingness to pay.</=
p>
<p dir=3D"ltr">> So, no, its not unreliable for cheap free transactions.=
<br>
> Its unreliable for all types of transactions.</p>
<p dir=3D"ltr">If 2500 transactions fit in the block chain per day (assumin=
g constant size) and there are less than 2500 per hour that pay at least 0.=
001 BTC in fee, then any transaction which pays more than 0.001 BTC will ha=
ve a very high chance of getting in a small multiple of one hour, since min=
ers prioritize by feerate.</p>
<p dir=3D"ltr">If there are in addition to that 5000 transactions per hour =
which pay less, then yes, they need to compete for the remaiming space and =
their confirmation will be unreliable.</p>
<p dir=3D"ltr">The whole point is that whether confirmation at a particular=
price point is reliable depends on how much demand there is at that price =
point. And increasing the block size out of fear of what might happen is fa=
iling to recognize that it can always happen that there is a sudden change =
in demand that outcompetes the rest.</p>
<p dir=3D"ltr">The point is not that evolution towards a specific higher fe=
erate needs to happen, but an evolution to an ecosystem that accepts that t=
here is never a guarantee for reliability, unless you're willing to pay=
more than everyone else - whatever that number is.</p>
<p dir=3D"ltr">-- <br>
Pieter<br>
</p>
--047d7b2e148dbde492051cfcd6f4--
|
