MIME-Version: 1.0
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
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
Precedence: list

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-----
>