From: "Jorge Timón" <jtimon@jtimon•cc>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Consensus fork activation thresholds: Block.nTime vs median time vs block.nHeight
Date: Tue, 4 Aug 2015 22:02:53 +0200 [thread overview]
Message-ID: <CABm2gDonaiD_VxGoRHjXC8Ut3jxRG-cHVfdL9Y4voZz5m=z7SA@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T0c10SDHCBy5=iPKVvsNPmKr2ejUxLp0rJPZmPRPQpfig@mail.gmail.com>
On Thu, Jul 30, 2015 at 8:16 PM, Gavin Andresen <gavinandresen@gmail•com> wrote:
> I still think using the version and timestamp fields in the block header are
> simplest and best.
To be clear, all options can use the version.
> 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.
All advantages shared with the height option.
> 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'm talking about the non-reorg case. Without reorg, you know what the
next height or current median time is, but you don't know what the
next block time is.
> 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).
How does bitcoin-tx know about the next block time?
It doesn't. You would need to use the current time as a proxy for the
median time or the block.nTime which you don't know either.
Or just keep the sanity check as it is. Note that this case is
blocksize-specific: other hardforks (like my previous example, or the
code proposal in BIP99) don't share that concern.
One thing I've noticed there seems to be disagreement on is whether
miners' upgrade confirmation (aka voting) is necessary for
uncontroversial hardforks or not.
In BIP99 the advice for uncontroversial hardforks is setting a
threshold (based on height, but we can change it) and then wait for
95% of the hashrate to upgrade to enforce the chain.
But maybe the "voting" can happen first and then the threshold is
added to the "miners' confirmation height/time".
I think that may influence which of the three discussed options
(height, block time and median time) is better, so maybe we should
discuss that first.
next prev parent reply other threads:[~2015-08-04 20:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-29 20:27 Jorge Timón
2015-07-30 18:16 ` Gavin Andresen
2015-08-04 20:02 ` Jorge Timón [this message]
2015-08-04 21:29 ` Peter Todd
2015-08-05 19:29 ` Jorge Timón
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABm2gDonaiD_VxGoRHjXC8Ut3jxRG-cHVfdL9Y4voZz5m=z7SA@mail.gmail.com' \
--to=jtimon@jtimon$(echo .)cc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gavinandresen@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox