From: "Jorge Timón" <jtimon@jtimon•cc>
To: Ross Nicoll <jrn@jrn•me.uk>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
Date: Thu, 23 Jul 2015 13:24:52 +0200 [thread overview]
Message-ID: <CABm2gDoBEWHBSguAEu6_rCs0UvvcRVWPV1g1qpDXrch=byYhFg@mail.gmail.com> (raw)
In-Reply-To: <55AEC21A.3090302@jrn.me.uk>
Peter Todd, as discussed on IRC, I'm not opposed to median time, which
has many of the properties nheight has, I'm just opposed to just using
nTime which is what all "hardfork proposals" I've seen so far
(including this one) do.
On Wed, Jul 22, 2015 at 12:05 AM, Ross Nicoll <jrn@jrn•me.uk> wrote:
> On 21/07/2015 10:26, Jorge Timón wrote:
>>
>> I still disagree. Using height instead of time may make the
>> implementation more complex by requiring some additional preparations
>> but using height is in fact a simpler design. Why relay on clocks that
>> we know will differ in different computers and places when we have a
>> universal tick with every block?
>
> Not so much that the implementation is difficult, as it requires context to
> validate a block size, rather than being able to validate it without
> requiring the preceeding blocks. Yes, time on different machines may vary,
> but block time is safe to use for this, because it's a straight-forward test
> of "if block time is acceptable and block time is after <date> then maximum
> block size allowed is n MB otherwise m MB".
No, the height is in the current block after bip34, no context required.
In any case, you already have the nHeight in most functions that would
require it (for example, main::ConnectBlock).
The median time actually needs a context (the last 10 headers), but
it's not hard to calculate and pass around either.
But simply using nTime is not a good idea. Leaving aside time zones,
einstein and all that it introduces edge cases and weird incentives
for no good reason.
If the goal is to make it "human-schedule-friendly", median time
should be good enough.
If we're going to make miners 95% confirm after the date/height, I
still prefer the height, but as said median time seems a reasonable
compromise.
Can we move the "height/medianTime/nTime" and "is it good to confirm
that the change is uncontroversial to miners by requiring 95% to
activate the consensus change, like we do with uncontroversial
softforks?" discussions to the thread with my bip draft (
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html
) on precisely this subject?
I have requested a bip number.
Let's please have an uncontroversial hardfork to set a precedent.
Hopefully that way we may decouple some parts of the blocksize
discussion.
next prev parent reply other threads:[~2015-07-23 11:24 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-17 15:55 Jeff Garzik
2015-07-17 16:11 ` Andrew
2015-07-17 16:12 ` Tier Nolan
2015-07-17 16:14 ` Tier Nolan
2015-07-17 17:57 ` Ross Nicoll
2015-07-17 19:06 ` Chris Wardell
2015-07-17 19:13 ` Ross Nicoll
2015-07-19 22:51 ` Ross Nicoll
2015-07-21 9:26 ` Jorge Timón
2015-07-21 13:04 ` Peter Todd
2015-07-21 13:58 ` Peter Todd
2015-07-22 15:51 ` Tom Harding
2015-07-22 17:02 ` Sriram Karra
2015-07-22 17:40 ` Sriram Karra
2015-07-22 17:43 ` Jeff Garzik
2015-07-22 22:30 ` Peter Todd
2015-07-23 5:39 ` jl2012
2015-07-22 17:00 ` jl2012
2015-07-21 22:05 ` Ross Nicoll
2015-07-23 11:24 ` Jorge Timón [this message]
2015-07-17 20:29 ` Luke Dashjr
2015-07-17 21:13 ` Angel Leon
2015-07-17 22:25 ` Tier Nolan
2015-07-18 9:22 ` Jorge Timón
2015-07-18 9:24 ` Jorge Timón
2015-07-24 8:52 ` Thomas Zander
2015-07-24 9:43 ` Slurms MacKenzie
2015-07-18 4:32 ` Venzen Khaosan
2015-07-17 22:40 Raystonn
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='CABm2gDoBEWHBSguAEu6_rCs0UvvcRVWPV1g1qpDXrch=byYhFg@mail.gmail.com' \
--to=jtimon@jtimon$(echo .)cc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jrn@jrn$(echo .)me.uk \
/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