MIME-Version: 1.0
In-Reply-To: <CADJgMzuWNNvMf6f9N0h0swAUATyAm4Y9Qu+ya33cEA1WB++sRg@mail.gmail.com>
References: <CADm_WcZyK6LUcuKqSEuR-q0hTZOC3EdJsqY1HrS_ow0knDY=7A@mail.gmail.com>
	<e54e93e519d776262f9c0f4ae23f54fb@xbt.hk>
	<CADJgMzuWNNvMf6f9N0h0swAUATyAm4Y9Qu+ya33cEA1WB++sRg@mail.gmail.com>
Date: Thu, 3 Sep 2015 10:34:02 -0400
Message-ID: <CADm_WcbVRQMFHU0pS7hi99=Ey3Pu3t6pViaPG-KpHF40w69N6A@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Btc Drak <btcdrak@gmail.com>
Content-Type: multipart/alternative; boundary=089e0141aa1ab3516f051ed8ac78
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 100 specification
Precedence: list

--089e0141aa1ab3516f051ed8ac78
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

A discussion of rolling out BIP 100 will not be avoided :)

It is a hard fork; it would be silly to elide discussion of these key
issues.

I don't get the community's recent interest in avoiding certain topics.



On Thu, Sep 3, 2015 at 7:20 AM, Btc Drak <btcdrak@gmail.com> wrote:

> 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
> rules,
> > 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
> fork.
> > 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
> economic
> > 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
> block
> > size is increased only when most miners agree, which sounds ok to me.
> >
> > However, using 20-percentile as threshold to DECREASE the block size
> could
> > be very dangerous. Consider that the block size has been stable at 8MB
> for 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
> way
> > 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 increas=
e
> and
> > decrease must be symmetrical: increase the block size when the
> x-percentile
> > is bigger than the current size, decrease the block size when the
> > (100-x)-percentile is smaller than the current size. The overall effect
> is:
> > 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 o=
ne
> > 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
> percentile.
> > 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
> pattern:
> > "/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 (fina=
l
> 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
> >
>

--089e0141aa1ab3516f051ed8ac78
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">A discussion of rolling out BIP 100 will not be avoided :)=
<div><br></div><div>It is a hard fork; it would be silly to elide discussio=
n of these key issues.</div><div><br></div><div>I don&#39;t get the communi=
ty&#39;s recent interest in avoiding certain topics.</div><div><br></div><d=
iv><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
">On Thu, Sep 3, 2015 at 7:20 AM, Btc Drak <span dir=3D"ltr">&lt;<a href=3D=
"mailto:btcdrak@gmail.com" target=3D"_blank">btcdrak@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">We should avoid discussing actu=
al hard fork/softfork deployment<br>
methodologies when discussing blocksize proposals because deployment<br>
is a separate issue. As a recent case in point, look at how BIP65<br>
(CHECKLOCKTIMEVERIFY) specifically avoided the issue of how to deploy.<br>
That lead to a focused discussion of the functionality and relatively<br>
quick inclusion.<br>
<br>
Deployment really is a separate issue than the mechanics of how BIP100<br>
will function after activation.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.linuxfoundation.org</a>&gt; wrote:<br>
&gt; Some comments:<br>
&gt;<br>
&gt; The 75% rule is meaningless here. Since this is a pure relaxation of r=
ules,<br>
&gt; there is no such thing as &quot;invalid version 4 blocks&quot;<br>
&gt;<br>
&gt; The implication threshold is unclear. Is it 95% or 80%?<br>
&gt;<br>
&gt; Softfork requires a very high threshold (95%) to &quot;attack&quot; th=
e original fork.<br>
&gt; This makes sure that unupgraded client will only see the new fork.<br>
&gt; In the case of hardfork, however, the new fork is unable to attack the=
<br>
&gt; original fork, and unupgraded client will never see the new fork. The<=
br>
&gt; initiation of a hardfork should be based on its acceptance by the econ=
omic<br>
&gt; majority, not miner support. 95% is an overkill and may probably never=
<br>
&gt; accomplished. I strongly prefer a 80% threshold rather than 95%.<br>
&gt;<br>
&gt; As I&#39;ve pointed out, using 20-percentile rather than median create=
s an<br>
&gt; incentive to 51% attack the uncooperative minority.<br>
&gt; <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/201=
5-August/010690.html" rel=3D"noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/pipermail/bitcoin-dev/2015-August/010690.html</a><br>
&gt;<br>
&gt; Having said that, I don&#39;t have a strong feeling about the use of<b=
r>
&gt; 20-percentile as threshold to increase the block size. That means the =
block<br>
&gt; size is increased only when most miners agree, which sounds ok to me.<=
br>
&gt;<br>
&gt; However, using 20-percentile as threshold to DECREASE the block size c=
ould<br>
&gt; be very dangerous. Consider that the block size has been stable at 8MB=
 for a<br>
&gt; few years. Everyone are happy with that. An attacker would just need t=
o<br>
&gt; acquire 21% of mining power to break the status quo and send us all th=
e way<br>
&gt; to 1MB. The only way to stop such attempt is to 51% attack the attacke=
r.<br>
&gt; That&#39;d be really ugly.<br>
&gt;<br>
&gt; For technical and ethical reasons, I believe the thresholds for increa=
se and<br>
&gt; decrease must be symmetrical: increase the block size when the x-perce=
ntile<br>
&gt; is bigger than the current size, decrease the block size when the<br>
&gt; (100-x)-percentile is smaller than the current size. The overall effec=
t is:<br>
&gt; the block size remains unchanged unless 80% of miners agree to.<br>
&gt;<br>
&gt; Please consider the use of &quot;hardfork bit&quot; to signify the har=
dfork:<br>
&gt;<br>
&gt; <a href=3D"https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bi=
p_draft_hardfork_bit_jl2012_at_xbthk_jul_23_2015/" rel=3D"noreferrer" targe=
t=3D"_blank">https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_d=
raft_hardfork_bit_jl2012_at_xbthk_jul_23_2015/</a><br>
&gt;<br>
&gt; <a href=3D"https://github.com/jl2012/bips/blob/master/hardforkbit.medi=
awiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/jl2012/bips/=
blob/master/hardforkbit.mediawiki</a><br>
&gt;<br>
&gt; Or, alternatively, please combine the hardfork with a softfork. I&#39;=
m<br>
&gt; rewriting the specification as follow (changes underlined):<br>
&gt;<br>
&gt; Replace static 1M block size hard limit with a floating limit (&quot;h=
ardLimit&quot;).<br>
&gt;<br>
&gt; hardLimit floats within the range 1-32M, inclusive.<br>
&gt;<br>
&gt; Initial value of hardLimit is 1M, preserving current system.<br>
&gt;<br>
&gt; Changing hardLimit is accomplished by encoding a proposed value within=
 a<br>
&gt; block&#39;s coinbase scriptSig.<br>
&gt;<br>
&gt; Votes refer to a byte value, encoded within the pattern &quot;/BV\d+/&=
quot; Example:<br>
&gt; /BV8000000/ votes for 8,000,000 byte hardLimit. If there is more than =
one<br>
&gt; match with with pattern, the first match is counted.<br>
&gt; Absent/invalid votes and votes below minimum cap (1M) are counted as 1=
M<br>
&gt; votes. Votes above the maximum cap (32M) are counted as 32M votes.<br>
&gt; A new hardLimit is calculated at each difficult adjustment period (201=
6<br>
&gt; blocks), and applies to the next 2016 blocks.<br>
&gt; Calculate hardLimit by examining the coinbase scriptSig votes of the<b=
r>
&gt; previous 12,000 blocks, and taking the 20th percentile and 80th percen=
tile.<br>
&gt; New hardLimit is the median of the followings:<br>
&gt;<br>
&gt; min(current hardLimit * 1.2, 20-percentile)<br>
&gt; max(current hardLimit / 1.2, 80-percentile)<br>
&gt; current hardLimit<br>
&gt;<br>
&gt; version 4 block: the coinbase of a version 4 block must match this pat=
tern:<br>
&gt; &quot;/BV\d+/&quot;<br>
&gt; 70% rule: If 8,400 of the last 12,000 blocks are version 4 or greater,=
<br>
&gt; reject invalid version 4 blocks. (testnet4: 501 of last 1000)<br>
&gt; 80% rule (&quot;Point of no return&quot;): If 9,600 of the last 12,000=
 blocks are<br>
&gt; version 4 or greater, reject all version &lt;=3D 3 blocks. (testnet4: =
750 of last<br>
&gt; 1000)<br>
&gt; Block version number is calculated after masking out high 16 bits (fin=
al bit<br>
&gt; count TBD by versionBits outcome).<br>
&gt;<br>
&gt; Jeff Garzik via bitcoin-dev =E6=96=BC 2015-09-02 23:33 =E5=AF=AB=E5=88=
=B0:<br>
&gt;&gt; BIP 100 initial public draft:<br>
&gt;&gt; <a href=3D"https://github.com/jgarzik/bip100/blob/master/bip-0100.=
mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/jgarzik/=
bip100/blob/master/bip-0100.mediawiki</a> [1]<br>
&gt;&gt;<br>
&gt;&gt; Emphasis on &quot;initial&quot;=C2=A0 This is a starting point for=
 the usual open<br>
&gt;&gt; source feedback/iteration cycle, not an endpoint that Must Be This=
<br>
&gt;&gt; Way.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Links:<br>
&gt;&gt; ------<br>
&gt;&gt; [1] <a href=3D"https://github.com/jgarzik/bip100/blob/master/bip-0=
100.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/jgar=
zik/bip100/blob/master/bip-0100.mediawiki</a><br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a><br>
&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a><br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
&gt;<br>
</div></div></blockquote></div><br></div>

--089e0141aa1ab3516f051ed8ac78--