> 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
I feel particularly disappointed that while this BIP is 80% similar to my
proposal made 2 months ago (
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013490.html
), Matt Corallo was only the person replied me. Also, this BIP seems ignored
the txid malleability of the resol
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
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
Tom,
It's clear that you have some rather large gaps in your knowledge of Bitcoin,
its rules, implementation and game theory. I highly encourage you spend some
time learning more about these things before continuing posting here.
https://www.reddit.com/r/BitcoinBeginners/ is a good place to st
[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
I notice you didn’t read the actual full line :)
If you click on it, you’ll notice at the end of the line it says;
“chainparams.GetConsensus().BIP34Hash”
so, this is about BIP34.
On Tuesday, 4 April 2017 17:44:40 CEST Greg Sanders wrote:
> That's BIP30, he linked BIP34:
> https://github.com/bit
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;
> https:/
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 txid
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 while back that it would be more natural
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 an
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
13 matches
Mail list logo
