path: root/d1/a25ad0b5b04d637cc4821862d8f277e7630f58

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 <tier.nolan@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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: <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>
Date: Wed, 27 May 2015 12:26:33 +0100
Message-ID: <CAE-z3OVskd1JAE5g-WW2eDiPcxysYhbv-NsOYu7yKZvzu88VSg@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: <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: 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 <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.
>
>
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 <jtimon@jtimon.cc> wrote=
:

> On May 27, 2015 11:35 AM, "Tier Nolan" <tier.nolan@gmail.com> 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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, May 27, 2015 at 11:15 AM, Peter Todd <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>&=
gt;</span> wrote:<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"><spa=
n class=3D"">
</span>The median time mechanism is basically a way for hashing power to sh=
ow<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.=C2=A0 It means slightly m=
ore processing, but the median time could be cached in the header index, so=
 no big deal.<br><br></div><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=
">
Block counts are inconvenient for planning, as there&#39;s no guarantee<br>
they&#39;ll actually happen in any particular time frame, forward and back.=
<br></blockquote><div><br></div><div>I don&#39;t think the deadline needs t=
o be set that accurately.=C2=A0 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.<br><br></div><div>Perhaps the number of blocks =
used in the median could be increased to reduce &quot;noise&quot;.<br></div=
><div><br></div><div>The median time could be median of the last 144 blocks=
 plus 12 hours.<br></div><div>=C2=A0<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><span class=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 =
easier to write the code.=C2=A0 It reduced the state that needs to be store=
d per BIP.=C2=A0 You don&#39;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 =
particular range of times (or blocks).<br></div><div><br></div><div>If bloc=
k numbers were used for the deadline, you just need to check the block inde=
x for the deadline block.<br><br></div><div>enum {<br></div><div>=C2=A0=C2=
=A0=C2=A0 BIP_INACTIVE =3D 0,<br></div><div>=C2=A0=C2=A0=C2=A0 BIP_ACTIVE,<=
br></div><div>=C2=A0=C2=A0=C2=A0 BIP_LOCKED<br>=C2=A0=C2=A0=C2=A0 BIP_INVAL=
ID_BLOCK,<br>}<br></div><div><br>int GetBIPState(block, bip) <br>{<br>=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<br></div><div>=C2=A0=C2=A0=C2=A0 {=
<br></div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int bipState =3D =
check_supermajority(...);<br></div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 if (bipState =3D=3D BIP_LOCKED &amp;&amp; (block.nVersion &amp; b=
ip.bit)<br></div><div>=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;<br><br></div><div>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 if (bipState !=3D BIP_LOCKED &amp;&amp; (block.nVersi=
on &amp; (~bip.bit)))<br></div><div>=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;<br><br></div><div>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return BIP_INVALID_BLOCK;<br>=C2=A0=C2=
=A0=C2=A0 }<br></div><br><div>=C2=A0=C2=A0=C2=A0 if (block.height &gt; dead=
line) // Look at the deadline block to determine if the BIP is locked<br>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return (block_index[deadline].nV=
ersion &amp; bip_bit) !=3D 0 ? BIP_LOCKED : BIP_INACTIVE;<br><br></div><div=
>=C2=A0=C2=A0=C2=A0 if (block.height &lt; startline + I) // BIP cannot acti=
vate/lock until startline + implicit window size<br></div><div>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return INACTIVE;<br></div><div><br>=C2=A0=C2=
=A0=C2=A0 return check_supermajority(....) // Check supermajority of bit<br=
>}<br><br></div><div>The block at height deadline would indicate if the BIP=
 was locked in.<br><br></div><div>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 <br><br></div><div>T=
he gives roughly<br><br></div><div>start time =3D now<br></div><div>deadlin=
e time =3D now + six months<br></div><div>deadline height =3D now + eight m=
onths<br><br></div><div>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.<br></div><div><br></div><div>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.=
<br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, May 2=
7, 2015 at 11:15 AM, Jorge Tim=C3=B3n <span dir=3D"ltr">&lt;<a href=3D"mail=
to:jtimon@jtimon.cc" target=3D"_blank">jtimon@jtimon.cc</a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D""><p=
 dir=3D"ltr">
On May 27, 2015 11:35 AM, &quot;Tier Nolan&quot; &lt;<a href=3D"mailto:tier=
.nolan@gmail.com" target=3D"_blank">tier.nolan@gmail.com</a>&gt; wrote:</p>
<p dir=3D"ltr">&gt; 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?</p>
</span><p dir=3D"ltr">You need 75% to start applying it, 95% to start rejec=
ting blocks that don&#39;t apply it.<br>
</p>
</blockquote></div><br></div>I think the phrasing is ambiguous.=C2=A0 I was=
 just asking for clarification.<br><br>&quot;Whenever I out of any W <b>sub=
sequent</b> blocks (regardless of the block itself) have bit B set,&quot;<b=
r><br></div><div>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.<br></div></div></div></div>

--001a1133e3f6ecd15705170e8380--