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
|
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 27AEC4D3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Aug 2015 05:34:15 +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 310E812F
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Aug 2015 05:34:13 +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 EGE25423; Tue, 11 Aug 2015 06:34:12 +0100 (BST)
From: Thomas Zander <thomas@thomaszander.se>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Date: Tue, 11 Aug 2015 07:34:11 +0200
Message-ID: <2547793.e4fEoOQyIR@coldstorage>
User-Agent: KMail/4.14.1 (Linux/3.16.0-4-amd64; KDE/4.14.2; x86_64; ; )
In-Reply-To: <CAPg+sBhY1Suu961aCn8QB1qw0ps7zj4hhUzOup2MJH+dTrPkkw@mail.gmail.com>
References: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com>
<1472719.PaoH0O6gJe@coldstorage>
<CAPg+sBhY1Suu961aCn8QB1qw0ps7zj4hhUzOup2MJH+dTrPkkw@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.0A0B0203.55C98954.0069, 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.0A0B0203.55C98954.0069, 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: Tue, 11 Aug 2015 05:34:15 -0000
On Tuesday 11. August 2015 00.52.23 Pieter Wuille wrote:
> 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.
I'm going to go with this one, since we are seeking common ground and all of
this makes sense to me. And I bet to Gavin would agree to this too.
The question I want to ask is this;
How do you expect to get from the current to the situation outlined above?
There are several market forces at work;
* people currently expect near-free payments.
* people currently expect zero-confirmations.
* Bitcoin is seeing a huge amount of uptake, popularity, etc.
* With Greece still in flux, there is a potential enormous spike of usage set
to come when (not if) the Euro falls.
I conclude that we need;
* to create and make working solutions like LN, sidechains etc etc etc.
This should allow people to get their fast confirmation time. Who cares its of
a different nature, the point is that the coffeeshop owner lets you leave with
your coffee. We can sell that.
* To buy ourselves time, LN is not done, Bitpay and friends work on-chain.
That won't change for a year at least.
We need to move the max-block size to a substantial bigger size to allow
Bitcoin to grow.
Unfortunately for us all, Bitcoin is over-sold. We don't have a sales
department but the worth-of-mouth leaves us in a bad situation. And we need to
react to make sure the product isn't killed by bad publicity. What Gox didn't
manage can certainly happen when people find out that Bitcoin can't currently
do any of the things everyone is talking about.
So, while LN is written, rolled out and tested, we need to respond with bigger
blocks. 8Mb - 8Gb sounds good to me.
Can everyone win?
--
Thomas Zander
|
