MIME-Version: 1.0
In-Reply-To: <CABm2gDoxr4yY6XPZOEG0CF_iPO+b1H3_yFoKnYa68Y4b=Tcwrw@mail.gmail.com>
References: <CABm2gDoxr4yY6XPZOEG0CF_iPO+b1H3_yFoKnYa68Y4b=Tcwrw@mail.gmail.com>
Date: Thu, 30 Jul 2015 14:16:22 -0400
Message-ID: <CABsx9T0c10SDHCBy5=iPKVvsNPmKr2ejUxLp0rJPZmPRPQpfig@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=001a113492b857faf0051c1bb32f
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Consensus fork activation thresholds: Block.nTime
 vs median time vs block.nHeight
Precedence: list

--001a113492b857faf0051c1bb32f
Content-Type: text/plain; charset=UTF-8

I still think using the version and timestamp fields in the block header
are simplest and best.

Advantages:
  Available to SPV nodes with no change to the network protocol
  Available after headers downloaded, before full block data is available
  Once well past a fork, allows all block validation except validation
against the UTXO to happen in parallel, out-of-order, independent of any
other block.

Disadvantages:
  Not monotonically increasing


I think discussion about transactions in the memory pool are just a
distraction: no matter what criteria is used (timestamp, height, median
time), a blockchain re-organization could mean the validity of transactions
you've accepted into the memory pool (if you're accepting transactions that
switch from valid to invalid at the consensus change -- Core tries hard not
to do that via IsStandard policy) must be re-evaluated.

I don't strongly care if median time or block timestamp is used, I think
either will work. I don't like height, there are too many cases where the
time is known but the block height isn't (see, for example, the
max-outputs-in-a-transaction sanity check computation at line 190 of
bitcoin-tx.cpp -- bitcoin-tx.cpp has no idea what the current block height
is).


-- 
--
Gavin Andresen

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

<div dir=3D"ltr">I still think using the version and timestamp fields in th=
e block header are simplest and best.<div><br></div><div>Advantages:</div><=
div>=C2=A0 Available to SPV nodes with no change to the network protocol</d=
iv><div>=C2=A0 Available after headers downloaded, before full block data i=
s available</div><div>=C2=A0 Once well past a fork, allows all block valida=
tion except validation against the UTXO to happen in parallel, out-of-order=
, independent of any other block.</div><div><br></div><div>Disadvantages:</=
div><div>=C2=A0 Not monotonically increasing</div><div><br></div><div><br><=
/div><div>I think discussion about transactions in the memory pool are just=
 a distraction: no matter what criteria is used (timestamp, height, median =
time), a blockchain re-organization could mean the validity of transactions=
 you&#39;ve accepted into the memory pool (if you&#39;re accepting transact=
ions that switch from valid to invalid at the consensus change -- Core trie=
s hard not to do that via IsStandard policy) must be re-evaluated.</div><di=
v><br></div><div>I don&#39;t strongly care if median time or block timestam=
p is used, I think either will work. I don&#39;t like height, there are too=
 many cases where the time is known but the block height isn&#39;t (see, fo=
r example, the max-outputs-in-a-transaction sanity check computation at lin=
e 190 of bitcoin-tx.cpp -- bitcoin-tx.cpp has no idea what the current bloc=
k height is).</div><div><br></div><div class=3D"gmail_extra"><div><br></div=
>-- <br><div class=3D"gmail_signature">--<br>Gavin Andresen<br></div><div c=
lass=3D"gmail_signature"><br></div>
</div></div>

--001a113492b857faf0051c1bb32f--