I think it would be bet= ter to have the deadlines set as block counts.=C2=A0 That eliminates the ne= ed to use the median time mechanism.

The deadline c= ould be matched to a "start-line".=C2=A0 The definition would the= n be something like

BIP 105

Start block: 325000
End block: 350000

Activation: 750 of 1000
Implication: 950 = of 1000
Bit: 9

This would allow creation of a simple table = of known BIPs.=C2=A0 It also keeps multiple users of the bit as strictly se= parate.

The alternative to the start time is that it is set eq= ual to the deadline or implication time of the previous user of the bit.

Was the intention to change the 95% rule.=C2= =A0 You need 750 of the last 1000 to activate and then must wait at least 1= 000 for implication?

On Wed, May 27, 2015 at 4:5= 1 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:

It would also help to see the actual c= ode changes required, which I'm sure will be much shorter than the expl= anation itself.

On May 27, 2015 5:47 AM, "Luke Dashjr"= <luke@dashjr.org> wrote:

On Wed= nesday, May 27, 2015 1:48:05 AM Pieter Wuille wrote:
> Feel free to comment. As the gist does not support notifying participa= nts
> of new comments, I would suggest using the mailing list instead.

I suggest adding a section describing how this interacts with and changes G= BT.

Currently, the client tells the server what the highest block version it supports is, and the server indicates a block version to use in its templat= e,
as well as optional instructions for the client to forcefully use this vers= ion
despite its own maximum version number. Making the version a bitfield
contradicts the increment-only assumption of this design, and since GBT
clients are not aware of overall network consensus state, reused bits can easily become confused. I suggest, therefore, that GBT clients should indic= ate
(instead of a maximum supported version number) a list of softforks by
identifier keyword, and the GBT server respond with a template indicating:<= br> - An object of softfork keywords to bit values, that the server will accept= .
- The version number, as presently conveyed, indicating the preferred softf= ork
flags.

Does this sound reasonable, and/or am I missing anything else?

Luke

---------------------------------------------------------------------------= ---
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

-----------------------------------------------------------= -------------------

_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--001a1144bc4226ea1c05170cf5e5-- 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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YxYN5-0000DG-2A for bitcoin-development@lists.sourceforge.net; Wed, 27 May 2015 10:15:35 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.81 as permitted sender) client-ip=62.13.149.81; envelope-from=pete@petertodd.org; helo=outmail149081.authsmtp.net; Received: from outmail149081.authsmtp.net ([62.13.149.81]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1YxYN3-0002R8-4W for bitcoin-development@lists.sourceforge.net; Wed, 27 May 2015 10:15:35 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t4RAFOuc005616; Wed, 27 May 2015 11:15:24 +0100 (BST) Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com [75.119.251.161]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t4RAFGJX047330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 27 May 2015 11:15:19 +0100 (BST) Date: Wed, 27 May 2015 06:15:16 -0400 From: Peter Todd To: Tier Nolan Message-ID: <20150527101516.GB25814@savin.petertodd.org> References: <201505270346.17014.luke@dashjr.org>

MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JYK4vJDZwFMowpUq" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 474e907f-0459-11e5-b396-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAUUFVQNAgsB AmMbWlVeUVh7WGo7 bA9PbARUfEhLXhtr VklWR1pVCwQmRRhj d2hpKHFycwJFe34+ bENhWT5fW0AvfEZ6 FFNUEWgPeGZhPWUC AkNRcR5UcAFPdx8U a1UrBXRDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA41EyQn RhcEVT8uAVZNXz80 Nxs9I1p0 X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 75.119.251.161/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) 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 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1YxYN3-0002R8-4W 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: Wed, 27 May 2015 10:15:35 -0000 --JYK4vJDZwFMowpUq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 27, 2015 at 10:35:03AM +0100, Tier Nolan wrote: > I think it would be better to have the deadlines set as block counts. Th= at > eliminates the need to use the median time mechanism. 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. Block counts are inconvenient for planning, as there's no guarantee they'll actually happen in any particular time frame, forward and back. There's no particular incentive problems here - the median time clearly shows support by a majority of hashing power - so I don't see any reason to make planning more difficult. > The deadline could be matched to a "start-line". The definition would th= en > be something like >=20 > BIP 105 > Start block: 325000 > End block: 350000 > Activation: 750 of 1000 > Implication: 950 of 1000 > Bit: 9 >=20 > This would allow creation of a simple table of known BIPs. It also keeps > multiple users of the bit as strictly separate. 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. If you do assume there may be large reorganizations you can't have a "simple table" --=20 'peter'[:-1]@petertodd.org 000000000000000001643f7706f3dcbc3a386e4c1bfba852ff628d8024f875b6 --JYK4vJDZwFMowpUq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJVZZkwXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwMTY0M2Y3NzA2ZjNkY2JjM2EzODZlNGMxYmZiYTg1MmZm NjI4ZDgwMjRmODc1YjYvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsL0Af+NMKw3M9MOuUEQPgZUDkgNGsz rSZUx3zif08M4GGRe9YKmNYiEZontblO1G9aM5GJnkxt1sz23ikAgTbNVgFa8j39 Qmc3PN+sLwLhaor4pGrSLU/nwEQb4K96kEuVOhjF9cBYJB02067DmFVCr3bTB+Kk v46j37tVe3uTer7KEBr0m+RGqVjMxAmRa6OKRRkBL2VDsrwo4D49DFrssdtduWpK dxGAlcZP52Ls0CTyPpbnCnrzojgEyfNfU68ld3xwoCu2wmCzw1YbnYQuTTfXm3ZR AozbigXNIdR3au36y7QdVxWPa9IWSbEYmimCtjlkaGHs3alDSFnRbZIfOb/cpA== =T3wN -----END PGP SIGNATURE----- --JYK4vJDZwFMowpUq-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YxYNO-00083w-1M for bitcoin-development@lists.sourceforge.net; Wed, 27 May 2015 10:15:54 +0000 Received: from mail-wi0-f181.google.com ([209.85.212.181]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YxYNN-0006dP-0T for bitcoin-development@lists.sourceforge.net; Wed, 27 May 2015 10:15:54 +0000 Received: by wifw1 with SMTP id w1so16038234wif.0 for ; Wed, 27 May 2015 03:15:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wEz1WU2YeudQAdOUV5SYzHKiKYhhug2ctFYGR9rp3O0=; b=bdWj0yAin7zH1yw1pdOc0Noke4u4VwMR4ya/kj1qe06rmPO40a0+VtAV5x3w72CiyP U9DKuvcy5t+zX3NbNHEFTPnrFHOVnK9HLNpOboZJR0IGhtHk25tn89m4tmgtLydBV83X MBdnOczS0NcF15lLW9L0VHKVgyzyUWT4O680XV2tamdPwpp8x9hUh4Bv2skjtAtHAIIp ZODKli/QR7TmGRXGILY2dvupQSeS3qlfiMe4C4bciZiUQKyO7HrMYbwDW66VoF/HB6Gv ov9Do4gAQBcnVOHbhVaRlpJxuJsyoPJeRGkwvzCqB61ahCO+1i5eeGLHc5WOmSJqjxss y9hA== X-Gm-Message-State: ALoCoQlfJdUiDsWMQeGwrqLa5rtDqHTJVerkgl9p7MjpIDW7oCBvVL6haV49KmBwedmW1o610RNd MIME-Version: 1.0 X-Received: by 10.180.12.228 with SMTP id b4mr48209441wic.92.1432721746908; Wed, 27 May 2015 03:15:46 -0700 (PDT) Received: by 10.194.127.97 with HTTP; Wed, 27 May 2015 03:15:46 -0700 (PDT) Received: by 10.194.127.97 with HTTP; Wed, 27 May 2015 03:15:46 -0700 (PDT) In-Reply-To: References: <201505270346.17014.luke@dashjr.org>

Date: Wed, 27 May 2015 12:15:46 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Tier Nolan Content-Type: multipart/alternative; boundary=001a11c2a3a8c96d3e05170d86da X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1YxYNN-0006dP-0T Cc: Bitcoin Development 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: Wed, 27 May 2015 10:15:54 -0000 --001a11c2a3a8c96d3e05170d86da Content-Type: text/plain; charset=UTF-8 On May 27, 2015 11:35 AM, "Tier Nolan" wrote: > Was the intention to change the 95% rule. You need 750 of the last 1000 to activate and then must wait at least 1000 for implication? You need 75% to start applying it, 95% to start rejecting blocks that don't apply it. --001a11c2a3a8c96d3e05170d86da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On May 27, 2015 11:35 AM, "Tier Nolan" <tier.nolan@gmail.com> wrote:

> Was the intention to change the 95% rule.=C2=A0 You nee= d 750 of the last 1000 to activate and then must wait at least 1000 for imp= lication?

You need 75% to start applying it, 95% to start rejecting bl= ocks that don't apply it.

--001a11c2a3a8c96d3e05170d86da-- 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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YxZTs-0002pz-Df for bitcoin-development@lists.sourceforge.net; Wed, 27 May 2015 11:26:40 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.220.169 as permitted sender) client-ip=209.85.220.169; envelope-from=tier.nolan@gmail.com; helo=mail-qk0-f169.google.com; Received: from mail-qk0-f169.google.com ([209.85.220.169]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YxZTr-0003q5-9j for bitcoin-development@lists.sourceforge.net; Wed, 27 May 2015 11:26:40 +0000 Received: by qkhg32 with SMTP id g32so3335381qkh.0 for ; Wed, 27 May 2015 04:26:33 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.229.16.69 with SMTP id n5mr41365277qca.25.1432725993868; Wed, 27 May 2015 04:26:33 -0700 (PDT) Received: by 10.140.85.241 with HTTP; Wed, 27 May 2015 04:26:33 -0700 (PDT) In-Reply-To: <20150527101516.GB25814@savin.petertodd.org> References: <201505270346.17014.luke@dashjr.org>

<20150527101516.GB25814@savin.petertodd.org> Date: Wed, 27 May 2015 12:26:33 +0100 Message-ID: From: Tier Nolan Cc: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a1133e3f6ecd15705170e8380 X-Spam-Score: 3.3 (+++) 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 (tier.nolan[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.2 MISSING_HEADERS Missing To: header 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 2.7 MALFORMED_FREEMAIL Bad headers on message from free email service X-Headers-End: 1YxZTr-0003q5-9j 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: Wed, 27 May 2015 11:26:40 -0000 --001a1133e3f6ecd15705170e8380 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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. > > Fair enough. It means slightly more processing, but the median time could be cached in the header index, so no 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. > I don't think the deadline needs to be set that accurately. A roughly 6 month deadline should be fine, but as you say 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 median could be increased to reduce "noise". The median time could be median of the last 144 blocks plus 12 hours. > 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. > I think it makes it easier to write the code. It reduced the state that needs to be stored per BIP. You don't need to check if the previous bips were all accepted. Each bit is assigned to a particular BIP for a particular range of times (or blocks). If block numbers were used for the deadline, you just need to check the block index for the deadline block. enum { BIP_INACTIVE =3D 0, BIP_ACTIVE, BIP_LOCKED BIP_INVALID_BLOCK, } int GetBIPState(block, bip) { if (block.height =3D=3D bip.deadline) // Bit must be set to match locked/unlocked at deadline { int bipState =3D check_supermajority(...); if (bipState =3D=3D BIP_LOCKED && (block.nVersion & bip.bit) return BIP_LOCKED; if (bipState !=3D BIP_LOCKED && (block.nVersion & (~bip.bit))) return BIP_INACTIVE; return BIP_INVALID_BLOCK; } if (block.height > deadline) // Look at the deadline block to determine if the BIP is locked return (block_index[deadline].nVersion & bip_bit) !=3D 0 ? BIP_LOCK= ED : BIP_INACTIVE; if (block.height < startline + I) // BIP cannot activate/lock until startline + implicit window size return INACTIVE; return check_supermajority(....) // Check supermajority of bit } The block at height deadline would indicate if the BIP was locked in. Block time could still be used as long as the block height was set after that. The deadline_time could be in six months. The startline height could be the current block height and the deadline_height could be startline + 35000. 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 height 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 warning system. For each block height, there is a set of known BIP bits that are allowed. Once the final deadline is passed, the expected mask is zeros. On Wed, May 27, 2015 at 11:15 AM, Jorge Tim=C3=B3n wrote= : > On May 27, 2015 11:35 AM, "Tier Nolan" wrote: > > > 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? > > You need 75% to start applying it, 95% to start rejecting blocks that > don't apply it. > I think the phrasing is ambiguous. I was just asking for clarification. "Whenever I out of any W *subsequent* 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 activation. This makes the rule checking harder. Easier to use the current system, where blocks that were part of the 750 rule also count towards the 95% rule. --001a1133e3f6ecd15705170e8380 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, May 27, 2015 at 11:15 AM, Peter Todd <pete@petertodd.org&= gt; wrote:

The median time mechanism is basically a way for hashing power to sh= ow
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.=C2=A0 It means slightly m= ore processing, but the median time could be cached in the header index, so= no big deal.

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.

I think it makes it = easier to write the code.=C2=A0 It reduced the state that needs to be store= d per BIP.=C2=A0 You don't need to check if the previous bips were all = accepted.

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

If bloc= k numbers were used for the deadline, you just need to check the block inde= x for the deadline block.

enum {

=C2=A0=C2= =A0=C2=A0 BIP_INACTIVE =3D 0,

=C2=A0=C2=A0=C2=A0 BIP_ACTIVE,<= br>

=C2=A0=C2=A0=C2=A0 BIP_LOCKED
=C2=A0=C2=A0=C2=A0 BIP_INVAL= ID_BLOCK,
}

int GetBIPState(block, bip)
{
=C2= =A0=C2=A0=C2=A0 if (block.height =3D=3D bip.deadline)=C2=A0 // Bit must be = set to match locked/unlocked at deadline

=C2=A0=C2=A0=C2=A0 {=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int bipState =3D = check_supermajority(...);

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 if (bipState =3D=3D BIP_LOCKED && (block.nVersion & b= ip.bit)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 return BIP_LOCKED;

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 if (bipState !=3D BIP_LOCKED && (block.nVersi= on & (~bip.bit)))

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 return BIP_INACTIVE;

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return BIP_INVALID_BLOCK;
=C2=A0=C2= =A0=C2=A0 }

=C2=A0=C2=A0=C2=A0 if (block.height > dead= line) // Look at the deadline block to determine if the BIP is locked
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return (block_index[deadline].nV= ersion & bip_bit) !=3D 0 ? BIP_LOCKED : BIP_INACTIVE;

=C2=A0=C2=A0=C2=A0 if (block.height < startline + I) // BIP cannot acti= vate/lock until startline + implicit window size

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return INACTIVE;

=C2=A0=C2= =A0=C2=A0 return check_supermajority(....) // Check supermajority of bit}

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

Block time could still be used as long as= the block height was set after that.=C2=A0 The deadline_time could be in s= ix months.=C2=A0 The startline height could be the current block height and= the deadline_height could be startline + 35000.=C2=A0

T= he gives roughly

start time =3D now

deadlin= e time =3D now + six months

deadline height =3D now + eight m= onths

The deadline height is the block height when the bi= t is returned to the pool but the deadline time is when the BIP has to be a= ccepted.

It also helps with the warning system= .=C2=A0 For each block height, there is a set of known BIP bits that are al= lowed.=C2=A0 Once the final deadline is passed, the expected mask is zeros.=

On Wed, May 2= 7, 2015 at 11:15 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrot= e:

On May 27, 2015 11:35 AM, "Tier Nolan" <tier.nolan@gmail.com> wrote:

> Was the intention to change the 95% rule.=C2=A0 You nee= d=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 rejec= ting blocks that don't apply it.

I think the phrasing is ambiguous.=C2=A0 I was= just asking for clarification.

"Whenever I out of any W sub= sequent 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 activation.=C2=A0 This makes the rule checking harder.=C2=A0 = Easier to use the current system, where blocks that were part of the 750 ru= le also count towards the 95% rule.