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
|
Return-Path: <venzen@mail.bihthai.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7E8DD8D9
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Aug 2015 13:34:11 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bihthai.net (unknown [5.255.87.165])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 22AE61A1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Aug 2015 13:34:09 +0000 (UTC)
Received: from [10.8.0.6] (unknown [10.8.0.6])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested) (Authenticated sender: venzen)
by mail.bihthai.net (Postfix) with ESMTPSA id 95F4520DFD
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Aug 2015 15:35:56 +0200 (CEST)
Message-ID: <55C0BF4B.3090100@mail.bihthai.net>
Date: Tue, 04 Aug 2015 20:34:03 +0700
From: Venzen Khaosan <venzen@mail.bihthai.net>
Reply-To: venzen@mail.bihthai.net
Organization: Bihthai Bai Mai
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
References: <CAPg+sBj-wA1DMrwkQRWnzQoB5NR-q=2-5=WDAAUYfSpXRZSTqw@mail.gmail.com> <CABsx9T1NqBX9Tr8vRCtCeri76e0wrtkvRhEPyG9Advv_3Uqxng@mail.gmail.com> <CAPg+sBjwVxYTOn3+bwahHGSGpBh5BCh5b4OOFkw_2x97YZSFPQ@mail.gmail.com> <CA+w+GKS_wDDgf=HjPgD5QZ_wdTRg7i_oYUgBRmh9HpufETAP=w@mail.gmail.com> <CABm2gDqvpWdHdjo1OBzbw-6ivu5DEGcfvK8duc3-KAjsSeWapA@mail.gmail.com> <CA+w+GKRPPcgCO0pBP2PjKGU49tWuBoF1vRJzY+4fWn71HOVDPw@mail.gmail.com> <CABm2gDqV1NdHJZBmUWX3AxVYy6ErU7AB-wsWgGzbiTL1twdq6g@mail.gmail.com> <CA+w+GKTLBWj6b4ppwrmnXb_gybYFcrX7haLBSdCnMaijy2An4w@mail.gmail.com> <CABm2gDpWPhYNh=g-ZXCsfe-aPq=N6NKSWKP9kr-KtPVrWAxB7Q@mail.gmail.com> <CAAO2FKHsczkwwqO87cJFtxBp9JE=vf=GcxLx37GpRUkPq8VGHQ@mail.gmail.com> <CABm2gDpp5+hkHmd6op6PPW658siKoEMRDfTWiEHHM7vJSLDhyA@mail.gmail.com>
<CAAO2FKHJMbt2kpJy+sLTNWAgBwdxZNoEbcUsVF7rbXgbjTx4yQ@mail.gmail.com>
In-Reply-To: <CAAO2FKHJMbt2kpJy+sLTNWAgBwdxZNoEbcUsVF7rbXgbjTx4yQ@mail.gmail.com>
OpenPGP: id=1CF07D66;
url=pool.sks-keyservers.net
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,RDNS_NONE
autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Block size following technological growth
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, 04 Aug 2015 13:34:11 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/04/2015 07:19 PM, Hector Chu via bitcoin-dev wrote:
> On 4 August 2015 at 12:59, Jorge Timón <jtimon@jtimon.cc
> <mailto:jtimon@jtimon.cc>> wrote:
> So if you say 8, I must ask, why not 9? Why 9 MB is not safe for
> mining centralization but 8 MB is?
>
>
> 8MB has simply been the focal point for this debate. 9MB is also
> safe if 8MB is, but I suppose the opponents will be even less
> happy with 9 than with 8, and we don't want to unnecessarily
> increase the conflict.
>
Jorge will answer for himself, but you know that saying "9MB is also
safe if 8MB is" blows your position.
Do you, or me, or XT know that 8MB is "safe"? You say 9MB must then
also be "safe" - there has been no fact for me to grasp and from which
to tell a Bitcoin trading whale group: "here's the bottom line: this
is what it means and these are the implications." They hold
significant amounts of bitcoin and want to see a plan, and a strategy
based on facts. I can assure you, they're not going to XT, it lacks
both a strategy and the seasoned developers present here.
> It seems like the rationale it's always "the bigger the better" and
> the only limitation is what a few people concerned with mining
> centralization (while they still have time to discuss this) are
> willing to accept. If that's the case, then there won't be
> effectively any limit in the long term and Bitcoin will probably
> fail in its decentralization goals.
>
>
> A one-time increase to 8MB is safer than a dynamically growing
> limit over time for exactly this reason. Admittedly whenever the
> next debate to increase the block size over 8MB happens it will be
> even more painful and non-obvious, but that is the safety check to
> prevent unbounded block size increase.
You're articulate and you raise valid issues, but your judgment of
"safer" is not based on anything you or this list can refer to as a
comparator.
It seems you want 8MB for some ideological reason but if you examine
your motive and compare it to the facts, you'll find that many people
in this list are ultimately correct in saying that:
Whatever blocksize is set to, demand will soon fill it.
This is the nature of resource supply inflation - some business plan
will spot the opportunity and exploit it, colonize it and then we deal
with that, with some big-girls'-blouses exclaiming: "if we don't give
them what they want they're all going to leave to XT or ZT!"
Even though XT and ZT perfectly fulfill the needs of certain ambitious
businesses, the creators would rather see it happen on Core's
blockchain. Else why do they still come posit arguments here?
Fortunately, unlike the principle that applies in finance capital,
Bitcoin capacity supply doesn't have be increased on demand (not
without rigorous testing and evaluation) plus there is no maxim here
that "the customer is always right". The maxim is "be your own bank" -
during some periods it might be a slow bank but it _will_ remain
decentralized and it _will_ remain your own - not compromised to some
big business or mining cartel.
We want to compromise to science and reason, not profit motive or
democratic lobbying, right?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVwL80AAoJEGwAhlQc8H1mTVsH/3mdA4XrrRaBx7m/SckufNUu
OWJF/TPuEb0e3/A+OKNvYJgGtkZ9+8pQe2hQK2F1NxFG8QbbIPFXb4PYIiEnU8by
LMMNuDFfZXq0MEyTXXHgNj+XBSR74QKceXD4KM3jVeuieXE2KXGOyeiUD7Tjx0Gv
fyNAM4rhxmipGFu9kmnI6Bm25I4FBzif+ARQSWNmdZQn2bPkFrK0/Q4s/CyXngbb
S/DiPJ7XZrBJ2ogQycVmA4QesOyz30FpQ+QMt5nFUWma3LpLoYEBPtJd8rsG773i
acqSrOXxgfcGtNfbBU0xeTO/FOO4tXtbDVHBTKCBLZ5MgmBOYcm6OTLAwpeHlYY=
=WhnR
-----END PGP SIGNATURE-----
|
