From mboxrd@z Thu Jan 1 00:00:00 1970 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: Date: Mon, 1 Jun 2015 22:50:28 +0800 Content-Transfer-Encoding: 7bit Message-Id: References: <201505270346.17014.luke@dashjr.org> <20150527101516.GB25814@savin.petertodd.org> To: Tier Nolan 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 Subject: Re: [Bitcoin-development] Version bits proposal X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 =D0=B4=B5=C0=A3=BA >=20 >=20 >=20 >> On Wed, May 27, 2015 at 11:15 AM, Peter Todd 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 wro= te: >> On May 27, 2015 11:35 AM, "Tier Nolan" 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
oh my God ...

=E5=8F=91=E8=87=AA=E6=88=91=E7=9A=84 iPhone=

=E5=9C=A8 2015=E5=B9=B45=E6=9C=8827=E6=97=A5=EF=BC=8C19:26=EF= =BC=8CTier Nolan <tier.nolan@gmai= l.com> =E5=86=99=E9=81=93=EF=BC=9A



On Wed, May 27, 2015 at 11:15 AM, Peter Todd = <pete@petertodd.o= rg> wrote:
The median time mechanism is basically a way for hashing power to sho= w
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.


Fair enough.  It means slightly mo= re processing, but the median time could be cached in the header index, so n= o big deal.

Block counts are inconvenient for planning, as there's no guarantee
they'll actually happen in any particular time frame, forward and back.
<= /blockquote>

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.

Perhaps the number of blocks used in the me= dian could be increased to reduce "noise".

The m= edian time could be median of the last 144 blocks plus 12 hours.
 
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
mechanism is used.

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= .

Each bit is assigned to a particular BIP for a particula= r range of times (or blocks).

If block numbers w= ere used for the deadline, you just need to check the block index for the de= adline block.

enum {
    BIP_= INACTIVE =3D 0,
    BIP_ACTIVE,
&= nbsp;   BIP_LOCKED
    BIP_INVALID_BLOCK,
}

int GetBIPState(block, bip)
{
    if (= block.height =3D=3D bip.deadline)  // Bit must be set to match locked/u= nlocked at deadline
    {
 &= nbsp;      int bipState =3D check_supermajority(...= );
        if (bipState =3D= =3D BIP_LOCKED && (block.nVersion & bip.bit)
 = ;           return BIP_LOC= KED;

        if (bipSta= te !=3D BIP_LOCKED && (block.nVersion & (~bip.bit)))
            return= BIP_INACTIVE;

        r= eturn BIP_INVALID_BLOCK;
    }

 &nb= sp;  if (block.height > deadline) // Look at the deadline block to d= etermine if the BIP is locked
        r= eturn (block_index[deadline].nVersion & bip_bit) !=3D 0 ? BIP_LOCKED : B= IP_INACTIVE;

    if (block.height < star= tline + I) // BIP cannot activate/lock until startline + implicit window siz= e
        return INACTIVE;<= br>

    return check_supermajority(....) // Che= ck supermajority of bit
}

The block at height deadline w= ould indicate if the BIP was locked in.

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>
The gives roughly

start time =3D now
=
deadline time =3D now + six months
deadline height =3D= now + eight months

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.

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.

On Wed= , May 27, 2015 at 11:15 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> w= rote:
<= p dir=3D"ltr"> On May 27, 2015 11:35 AM, "Tier Nolan" <tier.nolan@gmail.com> wrote:

> 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?

You need 75% to start applying it, 95% to start reject= ing blocks that don't apply it.


I think the phrasing is ambiguous.  I was j= ust asking for clarification.

"Whenever I out of any W subsequent<= /b> blocks (regardless of the block itself) have bit B set,"

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.
--------------------= ----------------------------------------------------------
<= /span>
__________= _____________________________________
Bitcoin-development ma= iling list
Bitcoin-development@lists.sourceforge.net
h= ttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
= --Apple-Mail-2892A5B5-5A05-4068-95D8-012A6D7DC0CA--