summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGavin Andresen <gavinandresen@gmail.com>2015-07-30 14:16:22 -0400
committerbitcoindev <bitcoindev@gnusha.org>2015-07-30 18:16:24 +0000
commit183226b7bd69647b53ae3f57701bdcf4a451835d (patch)
tree3a73803f576b89bd19f9568f448a7901e618c373
parente3bc765330fa00c465bf27623e47fc4c740b3932 (diff)
downloadpi-bitcoindev-183226b7bd69647b53ae3f57701bdcf4a451835d.tar.gz
pi-bitcoindev-183226b7bd69647b53ae3f57701bdcf4a451835d.zip
Re: [bitcoin-dev] Consensus fork activation thresholds: Block.nTime vs median time vs block.nHeight
-rw-r--r--09/730122d657a4542fea1362c0fae9ace3097c64123
1 files changed, 123 insertions, 0 deletions
diff --git a/09/730122d657a4542fea1362c0fae9ace3097c64 b/09/730122d657a4542fea1362c0fae9ace3097c64
new file mode 100644
index 000000000..1143d20b9
--- /dev/null
+++ b/09/730122d657a4542fea1362c0fae9ace3097c64
@@ -0,0 +1,123 @@
+Return-Path: <gavinandresen@gmail.com>
+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
+ [172.17.192.35])
+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 6012140D
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Thu, 30 Jul 2015 18:16:24 +0000 (UTC)
+X-Greylist: whitelisted by SQLgrey-1.7.6
+Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com
+ [209.85.217.173])
+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A793C112
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Thu, 30 Jul 2015 18:16:23 +0000 (UTC)
+Received: by lbqc9 with SMTP id c9so7001523lbq.1
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Thu, 30 Jul 2015 11:16:22 -0700 (PDT)
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
+ h=mime-version:in-reply-to:references:date:message-id:subject:from:to
+ :cc:content-type;
+ bh=J+wyuS+jEDa3ue6BGa0BLVlNbgUkmflZ2xsEe/epPR4=;
+ b=qDNVE1pnV7AFmCRihr4i4k80H3MIM/1un8P6Sf0WDkSURmS1oyDn2K+vVtfPtVDR7j
+ BRujzcMCJTQcP2xDdJjJkMCR+zTpJ8sOgUrEMlBJdf6fC/uGVblp4KZgUstc2AtAsuxi
+ NR9jeL341gKu+CUhIgOilhA5HHpK9Gj6uKVqhuRyY9U0UBSjCn9HnBEIZJBYsdzHRLBi
+ yaeDC7LqwH+IvxKfwhWIiYFJmOJFME6Vc4v8zfqyy7ZxGf9sFMCnbrogtKsNl6Z/qeqL
+ yEPS7vmptiL7ej97BhXKmaA2IuJ8p+rvbiEWmHu+2vdhaNREUCc7e9Rcp1yieTTnkVsi
+ W+dw==
+MIME-Version: 1.0
+X-Received: by 10.112.239.43 with SMTP id vp11mr42667153lbc.75.1438280182133;
+ Thu, 30 Jul 2015 11:16:22 -0700 (PDT)
+Received: by 10.25.18.228 with HTTP; Thu, 30 Jul 2015 11:16:22 -0700 (PDT)
+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
+X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
+ DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
+ autolearn=ham version=3.3.1
+X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
+ smtp1.linux-foundation.org
+Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
+Subject: Re: [bitcoin-dev] Consensus fork activation thresholds: Block.nTime
+ vs median time vs block.nHeight
+X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
+X-Mailman-Version: 2.1.12
+Precedence: list
+List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
+List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
+List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
+List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
+List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
+List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
+X-List-Received-Date: Thu, 30 Jul 2015 18:16:24 -0000
+
+--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--
+