From: Venzen Khaosan <venzen@mail•bihthai.net>
To: Michael Naber <mickeybob@gmail•com>
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
Date: Tue, 30 Jun 2015 23:15:31 +0700 [thread overview]
Message-ID: <5592C0A3.8050008@mail.bihthai.net> (raw)
In-Reply-To: <CALgxB7uvtKCNM-nH+aqqPa4KNf5O6Gx4GmgZY7Oq8=A24wCrfA@mail.gmail.com>
-----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-----
next prev parent reply other threads:[~2015-06-30 16:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-30 15:34 Michael Naber
2015-06-30 16:03 ` Richard Moore
2015-06-30 16:15 ` Venzen Khaosan [this message]
2015-06-30 16:25 ` Peter Todd
2015-06-30 16:35 ` Michael Naber
2015-06-30 19:59 ` Bryan Cheng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5592C0A3.8050008@mail.bihthai.net \
--to=venzen@mail$(echo .)bihthai.net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=mickeybob@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox