Message-ID: <55A9D6F0.5090303@mail.bihthai.net>
Date: Sat, 18 Jul 2015 11:32:48 +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@lists.linuxfoundation.org, 
 Jeff Garzik <jgarzik@gmail.com>
References: <CADm_WcZKoMAhYvXbFMbE+5K9HOD75YkQu8_qTW4S6YN6ZMrfjA@mail.gmail.com>
In-Reply-To: <CADm_WcZKoMAhYvXbFMbE+5K9HOD75YkQu8_qTW4S6YN6ZMrfjA@mail.gmail.com>
OpenPGP: id=1CF07D66;
	url=pool.sks-keyservers.net
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
Precedence: list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As an alternative to the preferred BIP100 this proposal is good
because it establishes a plan of action for dealing with the recent
ramp-up (100% increase) in number of transactions and transaction
size. Arguably, a transitory spam attack, yes, but with a speculative
rally brewing (and implied increases in network usage) this BIP may
prove to be just-in-time.

Solutions favoring dynamic vs. scheduled increases in blocksize (and
by how much) are interesting and the proponents should explore and map
out their proposal with data sets, trend projections and future
scenarios. It will require labor and time, but convince the list about
the scientific merit of your proposal.

In the meantime, the current "sufficient" state of network capacity
may soon experience "insufficient" moments. Developer confluence
around a workable plan and testing should, reasonably, begin now.

Jeff's proposal addresses an approaching capacity crunch whilst
honoring decentralization and providing time for testing and
alternative future innovations. It's the best solution the user base
and developers currently have for all the reasons Jeff gives:
conservative blocksize increase, added capacity, low impact and
minimal implication for the network and its users.

Then, many of the more far-reaching proposals being offered can be
tested, formalized, and fleshed out with scenario data.


On 07/17/2015 10:55 PM, Jeff Garzik via bitcoin-dev wrote:
> Opening a mailing list thread on this BIP:
> 
> BIP PR: https://github.com/bitcoin/bips/pull/173 Code PR:
> https://github.com/bitcoin/bitcoin/pull/6451
> 
> The general intent of this BIP is as a minimum viable alternative
> plan to my preferred proposal (BIP 100).
> 
> If agreement is not reached on a more comprehensive solution, then
> this solution is at least available and a known quantity.  A good
> backup plan.
> 
> Benefits:  conservative increase.  proves network can upgrade.
> permits some added growth, while the community & market gathers
> data on how an increased block size impacts privacy, security,
> centralization, transaction throughput and other metrics.  2MB
> seems to be a Least Common Denominator on an increase.
> 
> Costs:  requires a hard fork.  requires another hard fork down the
> road.
> 
> 
> 
> 
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVqdbsAAoJEGwAhlQc8H1m3LIIAJeBKYp0HYWYONlBxFNeQfa8
4EpYmMxwTSsDZ62CxdinxEGY3eQTqQo0GGAjpfSict4hq9ivSy74eHRb7AZihdYm
znEVGMnedyMtSDvfyaUdIj/kkUX4k9mrcLyAAJB//E2e2BYQgs3esTAYx2ScCBiR
t/UQ9gIolezasUIEmEovaQG4vOXtwMEtlzXrYy7EiAGhtoBvb1w3CJ3xa8iuF4e7
aXsleE98e44wjs0T/xLbuV4d8lBpnb0i0laOH4rpl77plpTc1HlDzjjqibourPb7
SPZhfwnk5f++3PlNc/dtwEJLFw8p578S5aDWZhUX7h+DfRXSqF6WCxYvv6XdUGQ=
=eoPX
-----END PGP SIGNATURE-----