MIME-Version: 1.0
In-Reply-To: <e54e93e519d776262f9c0f4ae23f54fb@xbt.hk>
References: <CADm_WcZyK6LUcuKqSEuR-q0hTZOC3EdJsqY1HrS_ow0knDY=7A@mail.gmail.com>
	<e54e93e519d776262f9c0f4ae23f54fb@xbt.hk>
From: Btc Drak <btcdrak@gmail.com>
Date: Thu, 3 Sep 2015 12:20:08 +0100
Message-ID: <CADJgMzuWNNvMf6f9N0h0swAUATyAm4Y9Qu+ya33cEA1WB++sRg@mail.gmail.com>
To: jl2012@xbt.hk
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 100 specification
Precedence: list

We should avoid discussing actual hard fork/softfork deployment
methodologies when discussing blocksize proposals because deployment
is a separate issue. As a recent case in point, look at how BIP65
(CHECKLOCKTIMEVERIFY) specifically avoided the issue of how to deploy.
That lead to a focused discussion of the functionality and relatively
quick inclusion.

Deployment really is a separate issue than the mechanics of how BIP100
will function after activation.

On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Some comments:
>
> The 75% rule is meaningless here. Since this is a pure relaxation of rule=
s,
> there is no such thing as "invalid version 4 blocks"
>
> The implication threshold is unclear. Is it 95% or 80%?
>
> Softfork requires a very high threshold (95%) to "attack" the original fo=
rk.
> This makes sure that unupgraded client will only see the new fork.
> In the case of hardfork, however, the new fork is unable to attack the
> original fork, and unupgraded client will never see the new fork. The
> initiation of a hardfork should be based on its acceptance by the economi=
c
> majority, not miner support. 95% is an overkill and may probably never
> accomplished. I strongly prefer a 80% threshold rather than 95%.
>
> As I've pointed out, using 20-percentile rather than median creates an
> incentive to 51% attack the uncooperative minority.
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/01069=
0.html
>
> Having said that, I don't have a strong feeling about the use of
> 20-percentile as threshold to increase the block size. That means the blo=
ck
> size is increased only when most miners agree, which sounds ok to me.
>
> However, using 20-percentile as threshold to DECREASE the block size coul=
d
> be very dangerous. Consider that the block size has been stable at 8MB fo=
r a
> few years. Everyone are happy with that. An attacker would just need to
> acquire 21% of mining power to break the status quo and send us all the w=
ay
> to 1MB. The only way to stop such attempt is to 51% attack the attacker.
> That'd be really ugly.
>
> For technical and ethical reasons, I believe the thresholds for increase =
and
> decrease must be symmetrical: increase the block size when the x-percenti=
le
> is bigger than the current size, decrease the block size when the
> (100-x)-percentile is smaller than the current size. The overall effect i=
s:
> the block size remains unchanged unless 80% of miners agree to.
>
> Please consider the use of "hardfork bit" to signify the hardfork:
>
> https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfo=
rk_bit_jl2012_at_xbthk_jul_23_2015/
>
> https://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki
>
> Or, alternatively, please combine the hardfork with a softfork. I'm
> rewriting the specification as follow (changes underlined):
>
> Replace static 1M block size hard limit with a floating limit ("hardLimit=
").
>
> hardLimit floats within the range 1-32M, inclusive.
>
> Initial value of hardLimit is 1M, preserving current system.
>
> Changing hardLimit is accomplished by encoding a proposed value within a
> block's coinbase scriptSig.
>
> Votes refer to a byte value, encoded within the pattern "/BV\d+/" Example=
:
> /BV8000000/ votes for 8,000,000 byte hardLimit. If there is more than one
> match with with pattern, the first match is counted.
> Absent/invalid votes and votes below minimum cap (1M) are counted as 1M
> votes. Votes above the maximum cap (32M) are counted as 32M votes.
> A new hardLimit is calculated at each difficult adjustment period (2016
> blocks), and applies to the next 2016 blocks.
> Calculate hardLimit by examining the coinbase scriptSig votes of the
> previous 12,000 blocks, and taking the 20th percentile and 80th percentil=
e.
> New hardLimit is the median of the followings:
>
> min(current hardLimit * 1.2, 20-percentile)
> max(current hardLimit / 1.2, 80-percentile)
> current hardLimit
>
> version 4 block: the coinbase of a version 4 block must match this patter=
n:
> "/BV\d+/"
> 70% rule: If 8,400 of the last 12,000 blocks are version 4 or greater,
> reject invalid version 4 blocks. (testnet4: 501 of last 1000)
> 80% rule ("Point of no return"): If 9,600 of the last 12,000 blocks are
> version 4 or greater, reject all version <=3D 3 blocks. (testnet4: 750 of=
 last
> 1000)
> Block version number is calculated after masking out high 16 bits (final =
bit
> count TBD by versionBits outcome).
>
> Jeff Garzik via bitcoin-dev =E6=96=BC 2015-09-02 23:33 =E5=AF=AB=E5=88=B0=
:
>> BIP 100 initial public draft:
>> https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki [1]
>>
>> Emphasis on "initial"  This is a starting point for the usual open
>> source feedback/iteration cycle, not an endpoint that Must Be This
>> Way.
>>
>>
>>
>> Links:
>> ------
>> [1] https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>