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
|
Return-Path: <thomas@thomaszander.se>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 238FE4D3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Aug 2015 22:04:57 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from manxnetsf05.manx.net (outbound.manx.net [213.137.31.12])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 58E2313F
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Aug 2015 22:04:55 +0000 (UTC)
Received: from adsl92.39.203.140.manx.net (EHLO coldstorage.localnet)
([92.39.203.140])
by manxnetsf05.manx.net (MOS 4.4.5a-GA FastPath queued)
with ESMTP id EGD53258; Mon, 10 Aug 2015 23:04:54 +0100 (BST)
From: Thomas Zander <thomas@thomaszander.se>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Date: Tue, 11 Aug 2015 00:04:52 +0200
Message-ID: <5518448.rsGirHIjE7@coldstorage>
User-Agent: KMail/4.14.1 (Linux/3.16.0-4-amd64; KDE/4.14.2; x86_64; ; )
In-Reply-To: <CAPg+sBiwTQNTCBQN_idGGH4yu-mEX-r9QpDoWqR3=iKvMqg4hw@mail.gmail.com>
References: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com>
<CABsx9T2aZHe5382_fC7bEG2OFPadS3p0jjaAD8FW7p36XS7tcA@mail.gmail.com>
<CAPg+sBiwTQNTCBQN_idGGH4yu-mEX-r9QpDoWqR3=iKvMqg4hw@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Mirapoint-Received-SPF: 92.39.203.140 coldstorage.localnet
thomas@thomaszander.se 5 none
X-Junkmail-Status: score=10/50, host=manxnetsf05.manx.net
X-Junkmail-Signature-Raw: score=unknown,
refid=str=0001.0A0B0202.55C92006.0021, ss=1, re=0.000, recu=0.000,
reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,
so=2014-07-29 09:23:55, dmn=2013-03-21 17:37:32,
mode=multiengine
X-Junkmail-IWF: false
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
refid=str=0001.0A0B0202.55C92006.0021, ss=1, re=0.000, recu=0.000,
reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,
so=2014-07-29 09:23:55, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 1d0b4c36cb3b39a7afaf456daeb455b9
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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
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:04:57 -0000
On Monday 10. August 2015 16.34.55 Pieter Wuille via bitcoin-dev wrote:
> On Mon, Aug 10, 2015 at 4:12 PM, Gavin Andresen <gavinandresen@gmail.com>
>
> wrote:
> > Executive summary: when networks get over-saturated, they become
> > unreliable. Unreliable is bad.
> >
> > Unreliable and expensive is extra bad, and that's where we're headed
> > without an increase to the max block size.
>
> I think I see your point of view. You see demand for on-chain transactions
> as a single number that grows with adoption. Once the transaction creation
> rate grows close to the capacity, transactions will become unreliable, and
> you consider this a bad thing.
Everyone in any industry will consider that a bad thing.
There is no doubt that on-chain transactions will grow, absolutely no doubt.
You can direct many people to off-chain systems, but that will not stop growth
of on-chain transactions. Bitcoin economy is absolutely tiny and there is a
huge amount of growth possible. It can only grow.
> And if you see Bitcoin as a payment system where guaranteed time to
> confirmation is a feature, I fully agree.
Naturally, that is a usecase. But not really one that enters my mind. It
certainly is not a requirement to have guaranteed time.
The situation is much simpler than that.
We have maybe 0,007% of the world population using Bitcoin once a month. (half
a million people). And I'm being very optimistic with that number...
This should give you an idea of how much growth is possible.
There is no doubt at all that the 1Mb blocks will get full, continuously, if
we get to a higher rate of usage. Even with the vast majority of users using
Bitcoin off-chain.
As such its not about a guaranteed time-to confirmation. Its about a
confirmation before I die.
> If you want transactions to be cheap, it will also be cheap to make them
> unreliable.
Its not about transactions being cheap. The fee market is completely
irrelevant to the block size. If you think otherwise you are delusional.
The reason it is irrelevant is because when the system starts consistently
dropping transactions when user count goes up, and when that happens the
Bitcoin network looses value because people don't put value in something that
is unreliable.
This is simple economy 101.
Look at history; so many great companies made great products that had more
features, but didn't make it because their competition might have been slower
to market, but it was actually reliable.
--
Thomas Zander
|
