1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A22C5416
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jul 2015 11:24:55 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com
[209.85.212.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7E63417B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jul 2015 11:24:54 +0000 (UTC)
Received: by wibxm9 with SMTP id xm9so144230583wib.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jul 2015 04:24:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type
:content-transfer-encoding;
bh=EYq1dXBGu6YDGff2c+c/CjkCP+cmpD7xRdwyTBBrl6Y=;
b=MY+CA1sZh4P9pCd64hLF0OY9cWjP9hFjw0mvF1UhoCjsVts2Zlbgf9tjUowoycsUOV
4KRw7sFoSTQ88OFHajx9Qfq1bnC84CPjmkBJjgKSX2prr3O64ASo/59tu4BYn693c/ph
QnuGEoRcQRXZl2G8bNhEZxz2dzYIs8+nGUwfK5YF+lZE2+Fjx0DqgsMKo/RV3SNEuhNY
gUNE18XENUfpu9eIWNHtu8t+ASN6gdASJyWcI/2C6Z4mUxjAShQk61JM9ncUn/+x3Ak2
MM7zDKx7edIppdOxKhWxW374A4SNwcItIDBWkWP6Xyu7z9tBGUdUKXYmccP3AjV8FcI4
IZYQ==
X-Gm-Message-State: ALoCoQlas84myeZm/lnhtg9Hvjl0mkNXPVt0jKNwaadGARFFbEGyBFk6ION55JGOP0O9FEUAHVhv
MIME-Version: 1.0
X-Received: by 10.180.109.6 with SMTP id ho6mr52213703wib.58.1437650692936;
Thu, 23 Jul 2015 04:24:52 -0700 (PDT)
Received: by 10.194.95.168 with HTTP; Thu, 23 Jul 2015 04:24:52 -0700 (PDT)
In-Reply-To: <55AEC21A.3090302@jrn.me.uk>
References: <CADm_WcZKoMAhYvXbFMbE+5K9HOD75YkQu8_qTW4S6YN6ZMrfjA@mail.gmail.com>
<55A9421B.6040605@jrn.me.uk> <55AC29DB.4060800@jrn.me.uk>
<CABm2gDr6qXzvcpX_To39kCEsnQNTQS4M5Y40Yk_Lw481rjvSag@mail.gmail.com>
<55AEC21A.3090302@jrn.me.uk>
Date: Thu, 23 Jul 2015 13:24:52 +0200
Message-ID: <CABm2gDoBEWHBSguAEu6_rCs0UvvcRVWPV1g1qpDXrch=byYhFg@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Ross Nicoll <jrn@jrn.me.uk>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
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, 23 Jul 2015 11:24:55 -0000
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=C3=B3n 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 t=
est
> of "if block time is acceptable and block time is after <date> then maxim=
um
> 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.htm=
l
) 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.
|
