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
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8F220259
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Aug 2015 22:01:09 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com
[209.85.218.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 544AFEB
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Aug 2015 22:01:05 +0000 (UTC)
Received: by oiew67 with SMTP id w67so33033473oie.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Aug 2015 15:01:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type
:content-transfer-encoding;
bh=Nw4gnvV2H3xGq9K4su4ibgvibUNVle3R6YaAl/15fWQ=;
b=aI1brWPG4oJ9rBGVJnhGZhxNLTpX01HViMbv/TnYWmxbXGYNx3u7/NCEdM+drhWeU4
uMvJ8HrkuABx/lKoghzhK+0KFI+FJY67gNu0/UlcWmBNll6WIbKLGEFj19mQPayeB5/N
GMXiNebiGbBib4xp9cikNuemAWlplKwxYovVRhoK6eb5EgDNrLMggnljSKUHpVSeiDZ6
RxQnfzWdvv/b+uYScMTiTsT1QdVBGEu2vAxGaeO9LcARyKR1Zfu7c2UlD4qBL9l0z3y2
a+vxPvLlTY9YUWXEqpAZChQx4nuzGnM429NvQIQ9A6VvxeSb/i9cXitiIwM+m298CpHj
IOhw==
X-Gm-Message-State: ALoCoQnvSX3cMguNZr1f/jcKgDA6vIhaHHaYuXREbGQgsohbjC79tYWCxueIkQbybvbZS/3pqvzQ
MIME-Version: 1.0
X-Received: by 10.202.58.133 with SMTP id h127mr39642273oia.35.1439589664614;
Fri, 14 Aug 2015 15:01:04 -0700 (PDT)
Received: by 10.202.71.85 with HTTP; Fri, 14 Aug 2015 15:01:04 -0700 (PDT)
In-Reply-To: <2133828.JttggH90JM@pluto>
References: <CABm2gDqn4bDTqmp=9h_qBjgjV0=LhY97bTHdRevAREYVyR07EQ@mail.gmail.com>
<2133828.JttggH90JM@pluto>
Date: Sat, 15 Aug 2015 00:01:04 +0200
Message-ID: <CABm2gDp99F+Q-jq1fW+5qRUfsgrZqG-miUjfboWOOoAgaUr=mQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Thomas Zander <thomas@thomaszander.se>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A summary list of all concerns related to rising
the block size
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, 14 Aug 2015 22:01:09 -0000
On Wed, Aug 12, 2015 at 6:41 PM, Thomas Zander via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Wednesday 12. August 2015 12.28.39 Jorge Tim=C3=B3n wrote:
>> But let's just list the concerns first.
>
> Concerns?
Yes, concerns or risks. Feel free to bike-shed the word.
> I have never heard of "develop-by-concerns"? Is that similar to
> fire fighting management?
> To that I have this reply;
> http://www.aleanjourney.com/2009/07/stop-fighting-fires.html
I'm not the manager of Bitcoin Core nor the Bitcoin consensus rules.
I'm just trying to separate "dogs from cats" (if you allow me the
analogy) in another random attempt to move the discussion into more
productive territories.
I wouldn't be doing this if I didn't felt we have advance identifying
and understanding each other's concerns better.
If you think this thread is useless you don't need to participate.
> Your question makes sure that the proper answers don't fit.
> And that may be why you are getting frustrated because I've given a lot o=
f
> reasons why a blocksize increase is needed soon, and none of them show up
> in your list...
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010120=
.html
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010129=
.html
>
> And various others; I'm not going to bother pasting URLs, you probably ha=
ve
> them already.
>
> Point is, Bitcoin is a growing network, with a growing amount of transact=
ions
> and we KNOW we will get into problems when the block consistently get ful=
l.
> How do we know? Because of the old guys in this list having the experienc=
e
> that this always happens, because anyone in the IT business can tell you =
the
> same.
>
> We have started LN to cope with this growth, but this won't be enough sin=
ce it
> just won't handle all usecases and thus the on-chain growth will continue=
. For
> instance remittances and cross-border purchases.
> We need both LN as well as bigger blocks.
This thread is for "guardian dogs". To discuss to mouses catches we're
missing, I've created the other almost-identically-titled thread:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010188.h=
tml
The title of this one doesn't contain a "not" like the other one. You
missed (imagined?) that little detail.
In other words, if you want to contribute to this thread, think about
"things that could go wrong if we rise the consensus block size
maximum".
Judging from your strong conviction about the need of an urgent size
rise, probably you have thought hard about this before concluding that
there's not risk for your favorite proposed size (2MB, 8MB, 8GB,
20GB?).
Note that even if you are certain that those risks aren't a concern at
this scale, identifying and somehow estimating or measuring (if that's
even possible) the risks will be useful for future increases.
|
