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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 4 August 2015 16:02:53 GMT-04:00, "Jorge Timón via bitcoin-dev"
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 c
On Thu, Jul 30, 2015 at 8:16 PM, Gavin Andresen wrote:
> I still think using the version and timestamp fields in the block header are
> simplest and best.
To be clear, all options can use the version.
> Advantages:
> Available to SPV nodes with no change to the network protocol
> Available a
I still think using the version and timestamp fields in the block header
are simplest and best.
Advantages:
Available to SPV nodes with no change to the network protocol
Available after headers downloaded, before full block data is available
Once well past a fork, allows all block validation
When it comes to define thresholds for consensus fork activation there
are 3 options that I know of and each of them has at least a
disadvantage that the other 2 lack:
-Block.nTime: It's not monotonic
-median time: You cannot validate it without context (in contrast,
nTime is contained in the bloc
