From: "Jorge Timón" <jtimon@jtimon•cc>
To: Peter Todd <pete@petertodd•org>
Cc: "Jorge Timón via bitcoin-dev" <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Consensus fork activation thresholds: Block.nTime vs median time vs block.nHeight
Date: Wed, 5 Aug 2015 21:29:41 +0200 [thread overview]
Message-ID: <CABm2gDrLv=JnwnegcdKjeaDYvaMPuRTznfCc6Qj85Zjha0FwPA@mail.gmail.com> (raw)
In-Reply-To: <35CCF69C-D8FB-4E4E-BF58-FB61D07D60FB@petertodd.org>
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ón 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 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-----
>
> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVwS7F
> AAoJEMCF8hzn9Lnc47AH/3926JLE4Rn9Fil+wvfxhfmBqIm0wtfStPDAqsQMDIbh
> kbxOw/Mai/AbqNUkYUWvoM2ZfJ/JNkA6HA977CE6huT1ozYVz8TJQmcqN/p1QXfX
> w1559UsXXop2fepY1dbnyBUwB6w6VwBrfj3awYkJsblgcdHrEsAesYeAHphAkwL/
> kxQ0b+QmttaDCSK76hNloKVcN7AczdCSw1pux2rzmsG9zkwWJrIqR/prAO1nuk9Y
> LgQUCvYkZiMmMD8kNx9ZVRG2Y951uLS6594Qy6ZoAMAdA6QxNsP4qyE7s8M2HAon
> WjdS0UqTRyJuDVqpNav6WX4jTllK/UuHRUAOmBmYaRs=
> =0cKq
> -----END PGP SIGNATURE-----
>
prev parent reply other threads:[~2015-08-05 19:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-29 20:27 Jorge Timón
2015-07-30 18:16 ` Gavin Andresen
2015-08-04 20:02 ` Jorge Timón
2015-08-04 21:29 ` Peter Todd
2015-08-05 19:29 ` Jorge Timón [this message]
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='CABm2gDrLv=JnwnegcdKjeaDYvaMPuRTznfCc6Qj85Zjha0FwPA@mail.gmail.com' \
--to=jtimon@jtimon$(echo .)cc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)org \
/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