Pieter Wuille [ARCHIVE] on Nostr: 📅 Original date posted:2013-03-13 📝 Original message:On Wed, Mar 13, 2013 at ...
📅 Original date posted:2013-03-13
📝 Original message:On Wed, Mar 13, 2013 at 07:01:02PM +0100, Michael Gronager wrote:
> Please note that it was not 0.8 that had issues, but 0.7(and downwards).
>
> I really think changing features in 0.8 aiming for a fluffy limit to avoid lock object errors on 0.7 is the wrong way to go, and it will never cover for a similar situations in the future.
The current behaviour in 0.7 and before is indeed broken, and we cannot afford to keep
that as an implicitly-defined rule on the network. I fully agree with that, but it will
require a hardfork.
But we cannot just drop support for old nodes. It is completely unreasonable to put the
_majority_ of the network on a fork, without even as much as a discussion about it.
"Oh, you didn't get the memo? The rules implemented in your client are outdated." - that
is not how Bitcoin works: the network defines the rules.
IMHO, the way to go is first get a 0.8.1 out that mimics the old behaviour - just as a
stopgap solution. That will allow miners to safely use 0.8-based code at least. We can
also get patches for 0.7 and previous branches that fix the lock limit issue, but enforce
the same limit as 0.8.1 does, simply as band-aid for those who do not yet wish to upgrade
to 0.8.
Finally, we'll have to schedule a hard fork to drop the 0.8.1 limit. This is something
that requires widespread community consensus - far more than just miners and developers -
but as this is about fixing a bug that would otherwise prevent most evolution, I hope it
can be a very non-controversial one. To that end, I would prefer to limit this hard fork
to only direct bug fixes, and leave the block limit issue for later. By now, I think it
is clear that a hard fork will be inevitable, and by doing one, I think we can learn a
lot that can make later ones easier.
--
Pieter
📝 Original message:On Wed, Mar 13, 2013 at 07:01:02PM +0100, Michael Gronager wrote:
> Please note that it was not 0.8 that had issues, but 0.7(and downwards).
>
> I really think changing features in 0.8 aiming for a fluffy limit to avoid lock object errors on 0.7 is the wrong way to go, and it will never cover for a similar situations in the future.
The current behaviour in 0.7 and before is indeed broken, and we cannot afford to keep
that as an implicitly-defined rule on the network. I fully agree with that, but it will
require a hardfork.
But we cannot just drop support for old nodes. It is completely unreasonable to put the
_majority_ of the network on a fork, without even as much as a discussion about it.
"Oh, you didn't get the memo? The rules implemented in your client are outdated." - that
is not how Bitcoin works: the network defines the rules.
IMHO, the way to go is first get a 0.8.1 out that mimics the old behaviour - just as a
stopgap solution. That will allow miners to safely use 0.8-based code at least. We can
also get patches for 0.7 and previous branches that fix the lock limit issue, but enforce
the same limit as 0.8.1 does, simply as band-aid for those who do not yet wish to upgrade
to 0.8.
Finally, we'll have to schedule a hard fork to drop the 0.8.1 limit. This is something
that requires widespread community consensus - far more than just miners and developers -
but as this is about fixing a bug that would otherwise prevent most evolution, I hope it
can be a very non-controversial one. To that end, I would prefer to limit this hard fork
to only direct bug fixes, and leave the block limit issue for later. By now, I think it
is clear that a hard fork will be inevitable, and by doing one, I think we can learn a
lot that can make later ones easier.
--
Pieter