Re: [bitcoin-dev] BIP proposal: Generalized version bits voting (bip-genvbvoting)

> 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

Re: [bitcoin-dev] BIP proposal: Generalized version bits voting (bip-genvbvoting)

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

Re: [bitcoin-dev] BIP draft: Extended block header hardfork

On Sunday, 2 April 2017 22:39:13 CEST Russell O'Connor via bitcoin-dev wrote: > Someone told me a while back that it would be more natural if we move the > nHeight from the coinbase script to the coinbase locktime. Have you > considered doing this? That change would not be a consensus change

Re: [bitcoin-dev] BIP draft: Extended block header hardfork

It is a consensus rule https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki On Tue, Apr 4, 2017 at 6:47 AM, Tom Zander via bitcoin-dev wrote: > On Sunday, 2 April 2017 22:39:13 CEST Russell O'Connor via bitcoin-dev > wrote: >> Someone told me a

Re: [bitcoin-dev] BIP draft: Extended block header hardfork

Can you tell me where it is enforced? The only place I found was here; https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1793 which doesn’t enforce it, all that code does is check that the txid is unknown or fully spent. And since the below idea from Russel would change the

Re: [bitcoin-dev] BIP draft: Extended block header hardfork

That's BIP30, he linked BIP34: https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L3004 On Tue, Apr 4, 2017 at 11:32 AM, Tom Zander via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Can you tell me where it is enforced? > > The only place I found was here; >

Re: [bitcoin-dev] BIP proposal: Generalized version bits voting (bip-genvbvoting)

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

Re: [bitcoin-dev] BIP proposal: Generalized version bits voting (bip-genvbvoting)

[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

Re: [bitcoin-dev] BIP proposal: Generalized version bits voting (bip-genvbvoting)

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

Re: [bitcoin-dev] Extension block proposal by Jeffrey et al

Recently there has been some discussion of an apparent work-in-progress extension block proposal by Christopher Jeffrey, Joseph Poon, Fedor Indutny, and Steven Pair. Since this hasn't been formally posted on the ML yet, perhaps it is still in pre-draft stages and not quite ready for review, but