Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <165318903@qq.com>) id 1YzR3P-0002d3-Nf
for bitcoin-development@lists.sourceforge.net;
Mon, 01 Jun 2015 14:51:05 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of qq.com
designates 54.206.16.166 as permitted sender)
client-ip=54.206.16.166; envelope-from=165318903@qq.com;
helo=smtpbgau1.qq.com;
Received: from smtpbgau1.qq.com ([54.206.16.166])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1YzR3G-000267-5i
for bitcoin-development@lists.sourceforge.net;
Mon, 01 Jun 2015 14:51:03 +0000
X-QQ-mid: esmtp28t1433170228t645t19309
Received: from [10.28.176.243] (unknown [113.200.205.53])
by esmtp4.qq.com (ESMTP) with
id ; Mon, 01 Jun 2015 22:50:27 +0800 (CST)
X-QQ-SSF: 0000000000000060FG101F00000000Z
X-QQ-FEAT: c5qDthjzSWg+6X+f4OYij70ivP/CNG95jBDuzO7ERFAAWUTHjaYR63cSRbCcm
tCI4Kd69Qs9E2gu1VrFxUvWzJ9cpwBG4TwmGyUm2RO8IWN2BGrWkQvOscgWlMU8x2WWlWaW
watjOlyHJCrxwPKYAiPwdbvTm4yNwI1NnPintxCCdigyx9KGETSRux4VNiF/MP0gNNiGuvL
MjJRDvsMAZwjql1wihcDV8dLtsDOmOei/+abwQZmN3bf7O69eThBb
X-QQ-GoodBg: 0
Content-Type: multipart/alternative;
boundary=Apple-Mail-2892A5B5-5A05-4068-95D8-012A6D7DC0CA
Mime-Version: 1.0 (1.0)
From: Potter QQ <165318903@qq.com>
X-Mailer: iPhone Mail (12B436)
In-Reply-To: <CAE-z3OVskd1JAE5g-WW2eDiPcxysYhbv-NsOYu7yKZvzu88VSg@mail.gmail.com>
Date: Mon, 1 Jun 2015 22:50:28 +0800
Content-Transfer-Encoding: 7bit
Message-Id: <F60298F2-D5C8-4D25-911E-4CBBE33183F3@qq.com>
References: <CAPg+sBg5TqQ=zjyZ7dp-d1oBGp31Krnix3zyt9suP4-AGbxW=Q@mail.gmail.com>
<201505270346.17014.luke@dashjr.org>
<CABm2gDoriDaQ1AjRDFxCT9zCNPQakJd9xRxfWkOJBf4v22hndQ@mail.gmail.com>
<CAE-z3OVAKyppLVEWR=qNX-_p5yVAj_0Y7Kw76o4qaywf2DKtVw@mail.gmail.com>
<20150527101516.GB25814@savin.petertodd.org>
<CAE-z3OVskd1JAE5g-WW2eDiPcxysYhbv-NsOYu7yKZvzu88VSg@mail.gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>
X-QQ-SENDSIZE: 520
X-QQ-Bgrelay: 1
X-Spam-Score: -0.1 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(165318903[at]qq.com)
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [54.206.16.166 listed in list.dnswl.org]
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (165318903[at]qq.com)
1.0 HTML_MESSAGE BODY: HTML included in message
0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
X-Headers-End: 1YzR3G-000267-5i
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Version bits proposal
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 01 Jun 2015 14:51:05 -0000
--Apple-Mail-2892A5B5-5A05-4068-95D8-012A6D7DC0CA
Content-Type: text/plain;
charset=gb2312
Content-Transfer-Encoding: quoted-printable
oh my God ...
=B7=A2=D7=D4=CE=D2=B5=C4 iPhone
> =D4=DA 2015=C4=EA5=D4=C227=C8=D5=A3=AC19:26=A3=ACTier Nolan <tier.nolan@gm=
ail.com> =D0=B4=B5=C0=A3=BA
>=20
>=20
>=20
>> On Wed, May 27, 2015 at 11:15 AM, Peter Todd <pete@petertodd.org> wrote:
>> The median time mechanism is basically a way for hashing power to show
>> what time they think it is. Equally, the nVersion soft-fork mechanism is
>> a way for hashing power to show what features they want to support.
>=20
> Fair enough. It means slightly more processing, but the median time could=
be cached in the header index, so no big deal.
>=20
>> Block counts are inconvenient for planning, as there's no guarantee
>> they'll actually happen in any particular time frame, forward and back.
>=20
> I don't think the deadline needs to be set that accurately. A roughly 6 m=
onth deadline should be fine, but as you say a majority of miners is needed t=
o abuse the median time and it is already a miner poll.
>=20
> Perhaps the number of blocks used in the median could be increased to redu=
ce "noise".
>=20
> The median time could be median of the last 144 blocks plus 12 hours.
> =20
>> If you assume no large reorganizations, your table of known BIPs can
>> just as easily be a list of block heights even if the median time
>> mechanism is used.
>=20
> I think it makes it easier to write the code. It reduced the state that n=
eeds to be stored per BIP. You don't need to check if the previous bips wer=
e all accepted.
>=20
> Each bit is assigned to a particular BIP for a particular range of times (=
or blocks).
>=20
> If block numbers were used for the deadline, you just need to check the bl=
ock index for the deadline block.
>=20
> enum {
> BIP_INACTIVE =3D 0,
> BIP_ACTIVE,
> BIP_LOCKED
> BIP_INVALID_BLOCK,
> }
>=20
> int GetBIPState(block, bip)=20
> {
> if (block.height =3D=3D bip.deadline) // Bit must be set to match loc=
ked/unlocked at deadline
> {
> int bipState =3D check_supermajority(...);
> if (bipState =3D=3D BIP_LOCKED && (block.nVersion & bip.bit)
> return BIP_LOCKED;
>=20
> if (bipState !=3D BIP_LOCKED && (block.nVersion & (~bip.bit)))
> return BIP_INACTIVE;
>=20
> return BIP_INVALID_BLOCK;
> }
>=20
> if (block.height > deadline) // Look at the deadline block to determin=
e if the BIP is locked
> return (block_index[deadline].nVersion & bip_bit) !=3D 0 ? BIP_LOC=
KED : BIP_INACTIVE;
>=20
> if (block.height < startline + I) // BIP cannot activate/lock until st=
artline + implicit window size
> return INACTIVE;
>=20
> return check_supermajority(....) // Check supermajority of bit
> }
>=20
> The block at height deadline would indicate if the BIP was locked in.
>=20
> Block time could still be used as long as the block height was set after t=
hat. The deadline_time could be in six months. The startline height could b=
e the current block height and the deadline_height could be startline + 3500=
0. =20
>=20
> The gives roughly
>=20
> start time =3D now
> deadline time =3D now + six months
> deadline height =3D now + eight months
>=20
> The deadline height is the block height when the bit is returned to the po=
ol but the deadline time is when the BIP has to be accepted.
>=20
> It also helps with the warning system. For each block height, there is a s=
et of known BIP bits that are allowed. Once the final deadline is passed, t=
he expected mask is zeros.
>=20
>> On Wed, May 27, 2015 at 11:15 AM, Jorge Tim=A8=AEn <jtimon@jtimon.cc> wro=
te:
>> On May 27, 2015 11:35 AM, "Tier Nolan" <tier.nolan@gmail.com> wrote:
>>=20
>> > Was the intention to change the 95% rule. You need 750 of the last 100=
0 to activate and then must wait at least 1000 for implication?
>>=20
>> You need 75% to start applying it, 95% to start rejecting blocks that don=
't apply it.
>=20
> I think the phrasing is ambiguous. I was just asking for clarification.
>=20
> "Whenever I out of any W subsequent blocks (regardless of the block itself=
) have bit B set,"
>=20
> That suggests that the I of W blocks for the 95% rule must happen after ac=
tivation. This makes the rule checking harder. Easier to use the current s=
ystem, where blocks that were part of the 750 rule also count towards the 95=
% rule.
> --------------------------------------------------------------------------=
----
>=20
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>=20
--Apple-Mail-2892A5B5-5A05-4068-95D8-012A6D7DC0CA
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div><span></span></div><div><meta http-equ=
iv=3D"content-type" content=3D"text/html; charset=3Dutf-8"><div><span></span=
></div><div><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"><div>oh my God ...<br><br>=E5=8F=91=E8=87=AA=E6=88=91=E7=9A=84 iPhone=
</div><div><br>=E5=9C=A8 2015=E5=B9=B45=E6=9C=8827=E6=97=A5=EF=BC=8C19:26=EF=
=BC=8CTier Nolan <<a href=3D"mailto:tier.nolan@gmail.com">tier.nolan@gmai=
l.com</a>> =E5=86=99=E9=81=93=EF=BC=9A<br><br></div><blockquote type=3D"c=
ite"><div><div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"=
gmail_quote">On Wed, May 27, 2015 at 11:15 AM, Peter Todd <span dir=3D"ltr">=
<<a href=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@petertodd.o=
rg</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
><span class=3D"">
</span>The median time mechanism is basically a way for hashing power to sho=
w<br>
what time they think it is. Equally, the nVersion soft-fork mechanism is<br>=
a way for hashing power to show what features they want to support.<br>
<br></blockquote><div><br></div><div>Fair enough. It means slightly mo=
re processing, but the median time could be cached in the header index, so n=
o big deal.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Block counts are inconvenient for planning, as there's no guarantee<br>
they'll actually happen in any particular time frame, forward and back.<br><=
/blockquote><div><br></div><div>I don't think the deadline needs to be set t=
hat accurately. A roughly 6 month deadline should be fine, but as you s=
ay a majority of miners is needed to abuse the median time and it is already=
a miner poll.<br><br></div><div>Perhaps the number of blocks used in the me=
dian could be increased to reduce "noise".<br></div><div><br></div><div>The m=
edian time could be median of the last 144 blocks plus 12 hours.<br></div><d=
iv> <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span cl=
ass=3D"">
</span>If you assume no large reorganizations, your table of known BIPs can<=
br>
just as easily be a list of block heights even if the median time<br>
mechanism is used.<br></blockquote><div><br></div><div>I think it makes it e=
asier to write the code. It reduced the state that needs to be stored p=
er BIP. You don't need to check if the previous bips were all accepted=
.<br><br></div><div>Each bit is assigned to a particular BIP for a particula=
r range of times (or blocks).<br></div><div><br></div><div>If block numbers w=
ere used for the deadline, you just need to check the block index for the de=
adline block.<br><br></div><div>enum {<br></div><div> BIP_=
INACTIVE =3D 0,<br></div><div> BIP_ACTIVE,<br></div><div>&=
nbsp; BIP_LOCKED<br> BIP_INVALID_BLOCK,<br>}<b=
r></div><div><br>int GetBIPState(block, bip) <br>{<br> if (=
block.height =3D=3D bip.deadline) // Bit must be set to match locked/u=
nlocked at deadline<br></div><div> {<br></div><div> &=
nbsp; int bipState =3D check_supermajority(...=
);<br></div><div> if (bipState =3D=
=3D BIP_LOCKED && (block.nVersion & bip.bit)<br></div><div> =
; return BIP_LOC=
KED;<br><br></div><div> if (bipSta=
te !=3D BIP_LOCKED && (block.nVersion & (~bip.bit)))<br></div><d=
iv> return=
BIP_INACTIVE;<br><br></div><div> r=
eturn BIP_INVALID_BLOCK;<br> }<br></div><br><div> &nb=
sp; if (block.height > deadline) // Look at the deadline block to d=
etermine if the BIP is locked<br> r=
eturn (block_index[deadline].nVersion & bip_bit) !=3D 0 ? BIP_LOCKED : B=
IP_INACTIVE;<br><br></div><div> if (block.height < star=
tline + I) // BIP cannot activate/lock until startline + implicit window siz=
e<br></div><div> return INACTIVE;<=
br></div><div><br> return check_supermajority(....) // Che=
ck supermajority of bit<br>}<br><br></div><div>The block at height deadline w=
ould indicate if the BIP was locked in.<br><br></div><div>Block time could s=
till be used as long as the block height was set after that. The deadl=
ine_time could be in six months. The startline height could be the cur=
rent block height and the deadline_height could be startline + 35000. <=
br><br></div><div>The gives roughly<br><br></div><div>start time =3D now<br>=
</div><div>deadline time =3D now + six months<br></div><div>deadline height =3D=
now + eight months<br><br></div><div>The deadline height is the block heigh=
t when the bit is returned to the pool but the deadline time is when the BIP=
has to be accepted.<br></div><div><br></div><div>It also helps with the war=
ning system. For each block height, there is a set of known BIP bits t=
hat are allowed. Once the final deadline is passed, the expected mask i=
s zeros.<br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed=
, May 27, 2015 at 11:15 AM, Jorge Tim=C3=B3n <span dir=3D"ltr"><<a href=3D=
"mailto:jtimon@jtimon.cc" target=3D"_blank">jtimon@jtimon.cc</a>></span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D""><=
p dir=3D"ltr">
On May 27, 2015 11:35 AM, "Tier Nolan" <<a href=3D"mailto:tier.nolan@gmai=
l.com" target=3D"_blank">tier.nolan@gmail.com</a>> wrote:</p>
<p dir=3D"ltr">> Was the intention to change the 95% rule. You need=
=20
750 of the last 1000 to activate and then must wait at least 1000 for=20
implication?</p>
</span><p dir=3D"ltr">You need 75% to start applying it, 95% to start reject=
ing blocks that don't apply it.<br>
</p>
</blockquote></div><br></div>I think the phrasing is ambiguous. I was j=
ust asking for clarification.<br><br>"Whenever I out of any W <b>subsequent<=
/b> blocks (regardless of the block itself) have bit B set,"<br><br></div><d=
iv>That suggests that the I of W blocks for the 95% rule must happen after a=
ctivation. This makes the rule checking harder. Easier to use th=
e current system, where blocks that were part of the 750 rule also count tow=
ards the 95% rule.<br></div></div></div></div>
</div></blockquote><blockquote type=3D"cite"><div><span>--------------------=
----------------------------------------------------------</span><br><span><=
/span><br></div></blockquote><blockquote type=3D"cite"><div><span>__________=
_____________________________________</span><br><span>Bitcoin-development ma=
iling list</span><br><span><a href=3D"mailto:Bitcoin-development@lists.sourc=
eforge.net">Bitcoin-development@lists.sourceforge.net</a></span><br><span><a=
href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development">h=
ttps://lists.sourceforge.net/lists/listinfo/bitcoin-development</a></span><b=
r><span></span><br></div></blockquote></div></div></body></html>=
--Apple-Mail-2892A5B5-5A05-4068-95D8-012A6D7DC0CA--