diff options
author | Gavin Andresen <gavinandresen@gmail.com> | 2015-07-30 14:16:22 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-07-30 18:16:24 +0000 |
commit | 183226b7bd69647b53ae3f57701bdcf4a451835d (patch) | |
tree | 3a73803f576b89bd19f9568f448a7901e618c373 | |
parent | e3bc765330fa00c465bf27623e47fc4c740b3932 (diff) | |
download | pi-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/730122d657a4542fea1362c0fae9ace3097c64 | 123 |
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've accepted into the memory pool (if you'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't strongly care if median time or block timestam= +p 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, 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-- + |