Thomas,
> the change is not opt-in and will require coordination; and the continuation
> of the chain thereafter depends on people actually running the hard-fork
> code, not just being aware there is something happening.
This situation applies to soft forks as well.
- if you wish your software
A schism is just that: miners can't ameliorate a HF transition in the way they
can censor transactions without permission. This is how miners became a
convenient way to activate soft-forks.
So while BIP9 can indicate the later censorship (a soft fork) in a way that
nodes can follow (or not) a
On Tuesday, 4 April 2017 20:01:51 CEST Luke Dashjr via bitcoin-dev wrote:
> BIP 9 provides a mechanism for having
> miners coordinate softforks because they can make the upgrade process
> smoother this way. But the same is not true of hardforks: miners are
> essentially irrelevant to them, and cann
> BIP 9 doesn't limit itself, merely acknowledges the *inherent* nature of it
> not being applicable to hardforks. BIP 9 provides a mechanism for having
> miners coordinate softforks because they can make the upgrade process smoother
> this way. But the same is not true of hardforks: miners are ess
On Monday, April 03, 2017 9:06:02 AM Sancho Panza via bitcoin-dev wrote:
> While BIP9 has served the community reasonably well until now, the
> author remarks several shortcomings in its approach:
>
> - it limits itself to backward-compatible changes, precluding its
> applicability to hard forks
[Apologies, reposting this in an attempt to improve on the botched formatting
of previous reply. I am still getting used to the limitations of this mail
service.]
Thanks for the feedback.
I'll post a link to more refined proposal on github once that elaboration is
more complete.
For now I think
Thanks for the feedback.
I'll post a link to more refined proposal on github once that elaboration is
more complete.
For now I think more discussion will be very helpful.
I think the flexibility around the tallying window size will take the most
careful consideration, so that a user of this propo
On Monday, 3 April 2017 11:06:02 CEST Sancho Panza wrote:
> ==Specification==
>
> To be elaborated.
Please do elaborate :)
The meat of the proposal is missing.
> It is thought that only cosmetic changes are needed to generalize from
> only soft forks to 'soft or hard forks', and to add the add
�Hola!
Please find below a proposal [resubmission] for a new informational BIP
provisionally named 'bip-genvbvoting'.
I present it here in rough draft for your esteemed consideration and as
a basis for discussion.
Best regards,
Sancho
--- begin draft of bip-genvbvoting ---
==Preamble==
BIP: ?
