[bitcoin-dev] Draft BIP : fixed-schedule block size increase
clem.ds at gmail.com
Mon Aug 17 13:18:38 UTC 2015
The "only bigblock" patch you want is actually available here :
Le lun. 17 août 2015 à 15:16, Tier Nolan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> a écrit :
> One of the comments made by the mining pools is that they won't run XT
> because it is "experimental".
> Has there been any consideration to making available a version of XT with
> only the blocksize changes?
> The least "experimental" version would be one that makes the absolute
> minimum changes to core.
> The MAX_BLOCK_SIZE parameter could be overwritten whenever the longest tip
> changes. This saves creating a new function.
> Without the consensus measuring code, the patch would be even easier.
> Satoshi's proposal was just a block height comparison (a year in advance).
> The state storing code is also another complication. If the standard
> "counting" upgrade system was used, then no state would need to be stored
> in the database.
> On Wed, Jul 1, 2015 at 11:49 PM, odinn <odinn.cyberguerrilla at riseup.net>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> (My replies below)
>> On 06/26/2015 06:47 AM, Tier Nolan wrote:
>> > On Thu, Jun 25, 2015 at 3:07 PM, Adam Back <adam at cypherspace.org
>> > <mailto:adam at cypherspace.org>> wrote:
>> > The hard-cap serves the purpose of a safety limit in case our
>> > understanding about the economics, incentives or game-theory is
>> > wrong worst case.
>> > True.
>> > BIP 100 and 101 could be combined. Would that increase consensus?
>> Possibly ~ In my past message(s), I've suggested that Jeff's BIP 100
>> is a better alternative to Gavin's proposal(s), but that I didn't
>> think that this should be taken to mean that I am saying one thing is
>> "superior" to Gavin's work, rather, I emphasized that Gavin work with
>> Jeff and Adam.
>> At least, at this stage the things are in a BIP process.
>> If the BIP 100 and BIP 101 would be combined, what would that look
>> like on paper?
>> > - Miner vote threshold reached - Wait notice period or until
>> > earliest start time - Block size default target set to 1 MB - Soft
>> > limit set to 1MB - Hard limit set to 8MB + double every 2 years -
>> > Miner vote to decide soft limit (lowest size ignoring bottom 20%
>> > but 1MB minimum)
>> > Block size updates could be aligned with the difficulty setting
>> > and based on the last 2016 blocks.
>> > Miners could leave the 1MB limit in place initially. The vote is
>> > to get the option to increase the block size.
>> > Legacy clients would remain in the network until >80% of miners
>> > vote to raise the limit and a miner produces a >1MB block.
>> > If the growth rate over-estimates hardware improvements, the devs
>> > could add a limit into the core client. If they give notice and
>> > enough users update, then miners would have to accept it.
>> > The block size becomes min(miner's vote, core devs). Even if 4
>> > years notice is given, blocks would only be 4X optimal.
>> > _______________________________________________ bitcoin-dev mailing
>> > list bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> - --
>> http://abis.io ~
>> "a protocol concept to enable decentralization
>> and expansion of a giving economy, and a new social good"
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>> -----END PGP SIGNATURE-----
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitcoin-dev