MIME-Version: 1.0
In-Reply-To: <87eghwiu4k.fsf@rustcorp.com.au>
References: <87mvwqb132.fsf@rustcorp.com.au>
	<CAE-z3OWLteNyBWuYSkYLZNteOGjDch_fViOV2kpWCaZkXsbu4w@mail.gmail.com>
	<87r3lyjewl.fsf@rustcorp.com.au>
	<CABm2gDqh=Dv2Ygctg+jEt61N_nJDRBMqdZypSPtmfM2QrY4AYQ@mail.gmail.com>
	<CAE-z3OXATJ6HGKqU=vxc8k-yCMAMwXiWQJxvO3D_O256_ZODtw@mail.gmail.com>
	<CABm2gDppFsTbh3JtdJkAkV_GzKFYAOLiEmtQPCgS9O6b7eWFuw@mail.gmail.com>
	<87eghwiu4k.fsf@rustcorp.com.au>
Date: Sat, 19 Sep 2015 07:04:45 +0200
Message-ID: <CABm2gDrLGHHn96JVpUX3kHcW0qx2fieAaYydb5EC_SGh=2hEFQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Rusty Russell <rusty@rustcorp.com.au>
Content-Type: multipart/alternative; boundary=001a11c263d844237f052012964b
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and
	delay.
Precedence: list

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

I disagree with the importance of this concern and old soft/hardforks will
replace this activation mechanism with height, so that's an argument in
favor of using the height from the start. This is "being discussed" in a
thread branched from bip99's discussion.
Anyway, is this proposing to use the block time or the median block time?
For some hardforks/softforks the block time complicates the implementation
(ie in acceptToMemoryPool) as discussed in the mentioned thread.
On Sep 19, 2015 1:24 AM, "Rusty Russell" <rusty@rustcorp.com.au> wrote:

> Jorge Tim=C3=B3n via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> writes:
> > I agree on using height vs time. Rusty, what do you mean by being easie=
r
> > for bip writers? How is writing "block x" any harder than writing "date
> y".
>
> Three years from drafting is reasonable.  How many blocks is that?  Hmm,
> better make it 6 years of blocks just in case we have a hash race.
>
> Deployment speed is measured in months, not blocks.  It's hard enough to
> guess without adding another variable.
>
> Cheers,
> Rusty.
>

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

<p dir=3D"ltr">I disagree with the importance of this concern and old soft/=
hardforks will replace this activation mechanism with height, so that&#39;s=
 an argument in favor of using the height from the start. This is &quot;bei=
ng discussed&quot; in a thread branched from bip99&#39;s discussion.<br>
Anyway, is this proposing to use the block time or the median block time?<b=
r>
For some hardforks/softforks the block time complicates the implementation =
(ie in acceptToMemoryPool) as discussed in the mentioned thread.</p>
<div class=3D"gmail_quote">On Sep 19, 2015 1:24 AM, &quot;Rusty Russell&quo=
t; &lt;<a href=3D"mailto:rusty@rustcorp.com.au">rusty@rustcorp.com.au</a>&g=
t; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Jorge Ti=
m=C3=B3n via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; writes:<br>
&gt; I agree on using height vs time. Rusty, what do you mean by being easi=
er<br>
&gt; for bip writers? How is writing &quot;block x&quot; any harder than wr=
iting &quot;date y&quot;.<br>
<br>
Three years from drafting is reasonable.=C2=A0 How many blocks is that?=C2=
=A0 Hmm,<br>
better make it 6 years of blocks just in case we have a hash race.<br>
<br>
Deployment speed is measured in months, not blocks.=C2=A0 It&#39;s hard eno=
ugh to<br>
guess without adding another variable.<br>
<br>
Cheers,<br>
Rusty.<br>
</blockquote></div>

--001a11c263d844237f052012964b--