[bitcoin-dev] Consensus fork activation thresholds: Block.nTime vs median time vs block.nHeight
jtimon at jtimon.cc
Wed Aug 5 19:29:41 UTC 2015
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
In any case, I understand that you agree that 95% confirmation is a
good idea for uncontroversial hardforks (like in uncontroversial
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 at petertodd.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> On 4 August 2015 16:02:53 GMT-04:00, "Jorge Timón via bitcoin-dev" <bitcoin-dev at 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 risks attack. Requiring 95% approval - which is actually just a 50% majority vote as the majority can squelch the minority - is an obvious minimum safety requirement.
> Another option is Hearn's proposal of using centralised checkpoints to override PoW consensus; obviously that raises serious questions, including legal issues.
> For forks without miner approval miners have a number of options to defeat them. For instance, they can make their own fork with a new consensus algorithm that requires miners to prove they're attacking the unwanted chain - Garzik's recent 2MB blocks proposal is a hilarious, and probably accidental, example of such a design, with the original Bitcoin protocol rules having the effect of attacking the Garzik 2MB chain.
> -----BEGIN PGP SIGNATURE-----
> -----END PGP SIGNATURE-----
More information about the bitcoin-dev