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
114
115
116
|
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 E0E1E9C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 Aug 2015 19:29:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com
[209.85.212.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1404EED
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 Aug 2015 19:29:43 +0000 (UTC)
Received: by wicgj17 with SMTP id gj17so205600724wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 05 Aug 2015 12:29:42 -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=wxw32i/hAav0N5X9Nl8bqBMDSQpV6vos5hXD/nRqloQ=;
b=h1W/dQagBPcJTP7X3oQm8IX5WINwbaLWY4pdrRTQYWHvmY3AaqYfsMms3vAK1SX6TE
XqojiHvxIMgChjAiO6pSIQFR6w2BsPOLDS91SX1K1jKUR7iFh84f+BFVtZjH0s/17I/6
WeMFzRZ8zDSrpSwNgOOG7qi1CxuJ4/xJ0b64dduNaTSDGzqTaMX1SviHM1uwNKCuuM5K
Il2TWGJLcx/tUAxIcg8QCpCTaaPexHjRgHrTIYbhNlnrzfNcGpUFFAruO6OhtzBr62F8
7l0EtO25aMmvejnq9+qaU2dPj8jg6BXnokKMuc7IVY7TySfEyuKp8Z5j0O1/jZWUmp5N
oMcg==
X-Gm-Message-State: ALoCoQkiR4gyrCV+z1qY3rSRXHcrdwNE+HNhIdSU5MhCGbqGmytFcA2ZVbfKLK+4d/l29+ZQdLA/
MIME-Version: 1.0
X-Received: by 10.180.21.175 with SMTP id w15mr1733457wie.58.1438802981764;
Wed, 05 Aug 2015 12:29:41 -0700 (PDT)
Received: by 10.194.31.230 with HTTP; Wed, 5 Aug 2015 12:29:41 -0700 (PDT)
In-Reply-To: <35CCF69C-D8FB-4E4E-BF58-FB61D07D60FB@petertodd.org>
References: <CABm2gDoxr4yY6XPZOEG0CF_iPO+b1H3_yFoKnYa68Y4b=Tcwrw@mail.gmail.com>
<CABsx9T0c10SDHCBy5=iPKVvsNPmKr2ejUxLp0rJPZmPRPQpfig@mail.gmail.com>
<CABm2gDonaiD_VxGoRHjXC8Ut3jxRG-cHVfdL9Y4voZz5m=z7SA@mail.gmail.com>
<35CCF69C-D8FB-4E4E-BF58-FB61D07D60FB@petertodd.org>
Date: Wed, 5 Aug 2015 21:29:41 +0200
Message-ID: <CABm2gDrLv=JnwnegcdKjeaDYvaMPuRTznfCc6Qj85Zjha0FwPA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Peter Todd <pete@petertodd.org>
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: =?UTF-8?Q?Jorge_Tim=C3=B3n_via_bitcoin=2Ddev?=
<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: Wed, 05 Aug 2015 19:29:44 -0000
I'm not sure how bip102 is less secure than other blocksize proposal
but please let's keep defects specific to each proposal in their own
threads.
In any case, I understand that you agree that 95% confirmation is a
good idea for uncontroversial hardforks (like in uncontroversial
softforks).
I'm not sure if you prefer that to happen before or after the time
threshold, but I guess you're fine with doing it after the threshold
since you didn't complained about that specifically (you can always
clarify your preferences of course).
On Tue, Aug 4, 2015 at 11:29 PM, Peter Todd <pete@petertodd.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
>
> On 4 August 2015 16:02:53 GMT-04:00, "Jorge Tim=C3=B3n via bitcoin-dev" <=
bitcoin-dev@lists.linuxfoundation.org> wrote:
>>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.
>
> To be clear, without a strong supermajority of miner support the fork ris=
ks attack. Requiring 95% approval - which is actually just a 50% majority v=
ote as the majority can squelch the minority - is an obvious minimum safety=
requirement.
>
> Another option is Hearn's proposal of using centralised checkpoints to ov=
erride PoW consensus; obviously that raises serious questions, including le=
gal issues.
>
> For forks without miner approval miners have a number of options to defea=
t them. For instance, they can make their own fork with a new consensus alg=
orithm that requires miners to prove they're attacking the unwanted chain -=
Garzik's recent 2MB blocks proposal is a hilarious, and probably accidenta=
l, example of such a design, with the original Bitcoin protocol rules havin=
g the effect of attacking the Garzik 2MB chain.
>
> -----BEGIN PGP SIGNATURE-----
>
> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVwS7F
> AAoJEMCF8hzn9Lnc47AH/3926JLE4Rn9Fil+wvfxhfmBqIm0wtfStPDAqsQMDIbh
> kbxOw/Mai/AbqNUkYUWvoM2ZfJ/JNkA6HA977CE6huT1ozYVz8TJQmcqN/p1QXfX
> w1559UsXXop2fepY1dbnyBUwB6w6VwBrfj3awYkJsblgcdHrEsAesYeAHphAkwL/
> kxQ0b+QmttaDCSK76hNloKVcN7AczdCSw1pux2rzmsG9zkwWJrIqR/prAO1nuk9Y
> LgQUCvYkZiMmMD8kNx9ZVRG2Y951uLS6594Qy6ZoAMAdA6QxNsP4qyE7s8M2HAon
> WjdS0UqTRyJuDVqpNav6WX4jTllK/UuHRUAOmBmYaRs=3D
> =3D0cKq
> -----END PGP SIGNATURE-----
>
|
