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
|
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 2AEEDBC4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jun 2015 16:15:38 +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 779241A3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jun 2015 16:15:37 +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 E715D204A5;
Tue, 30 Jun 2015 18:16:19 +0200 (CEST)
Message-ID: <5592C0A3.8050008@mail.bihthai.net>
Date: Tue, 30 Jun 2015 23:15:31 +0700
From: Venzen Khaosan <venzen@mail.bihthai.net>
Organization: Bihthai Bai Mai
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Michael Naber <mickeybob@gmail.com>
References: <CALgxB7uvtKCNM-nH+aqqPa4KNf5O6Gx4GmgZY7Oq8=A24wCrfA@mail.gmail.com>
In-Reply-To: <CALgxB7uvtKCNM-nH+aqqPa4KNf5O6Gx4GmgZY7Oq8=A24wCrfA@mail.gmail.com>
OpenPGP: id=1CF07D66;
url=pool.sks-keyservers.net
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
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
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Block size increase oppositionists: please
clearly define what you need done to increase block size to a static 8MB,
and help do it
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: venzen@mail.bihthai.net
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, 30 Jun 2015 16:15:38 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael, I snipped some of your comparison example to comment. I agree
with your sentiment to lobby for testing the change and your offer to
provide resources, yet it presents some (surmountable) challenges:
On 06/30/2015 10:34 PM, Michael Naber wrote:
> As you know I'm trying to lobby for a block size increase to a
> static 8MB.
>
> I'm happy to try to get the testing done that people want done for
> this, but I think the real crux of this issue is that we need to
> get consensus that we intend to continually push the block size
> upward as bounded only by technology.
Peter Todd, on 23/06/15, proposed a combined back-test and ongoing
forward test as follows:
"... the creation (via reorg) of a realistic full-load blockchain on
testnet to fully test the real-world behavior of the entire
infrastructure ecosystem, including questions like the scalability of
block explorers, SPV wallets, feasibility of initial syncronization,
scalability of the UTXO set, etc. While this is of course inconvenient
- - 2 years of 8MB blocks is 840GB worth of data..."
So, with a working dataset of that size, jumping to 8MB is excluding a
lot of participants and contributors to the testing - someone like
myself for example.
> Do what's best for Bitcoin and define what needs to get done to
> agree to a simple block size increase to a static 8MB.
And this then leads back to the core issue: if an 8MB blocksize
excludes many on this list from testnet, then the proposed 8MB blocks
will exclude a lot of mainnet participants (miners) and degrade the
quality of diversity and decentralization.
How about testing at double the capacity: 2MB?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVksCfAAoJEGwAhlQc8H1m3E8H/jbfdoYPN3dvJuWWpaEEU+P4
SbdPHLd08ya7dmZEqmJcGBH29aHCD1roqs5PDA6pwNFb7CTD/6aoRGeQnkU16wMj
FQ5UQkmT96niQhtHE17vdpeMHI+LK8ox1n0R3de+3QRn1HbXEN+Q68jPl16KLd8+
SArZfVUauVGUtoJDVLxXv1q2mx2huTUTX/QNeYcTZ5IjB5huMypjwN7VpL9bM8gT
xoN8pd3tjBGAt1zoRFUWk5ZgCR5iDbRdujq032gIyc5CxtP3w+N/cfDKcEwmUd1j
MTX680NODq3K1ACIz+odEd1O6VFTQjHPZdF2SEtI5eHZRNH3RcccwZUJ7S04Fic=
=CHiQ
-----END PGP SIGNATURE-----
|
