From: Pieter Wuille <pieter.wuille@gmail•com>
To: Michael Gronager <gronager@ceptacle•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Blocksize and off-chain transactions
Date: Wed, 13 Mar 2013 19:28:06 +0100 [thread overview]
Message-ID: <20130313182805.GA7921@vps7135.xlshosting.net> (raw)
In-Reply-To: <2FCCE0F7-66B0-4EBE-8448-C5F0F92A75FF@ceptacle.com>
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
next prev parent reply other threads:[~2013-03-13 18:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-13 17:01 Gavin Andresen
2013-03-13 17:48 ` Peter Todd
2013-03-13 18:01 ` Michael Gronager
2013-03-13 18:08 ` Luke-Jr
2013-03-13 18:28 ` Pieter Wuille [this message]
2013-03-13 19:29 ` Roy Badami
2013-03-13 19:43 ` Stephen Pair
2013-03-13 20:14 ` Michael Gronager
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130313182805.GA7921@vps7135.xlshosting.net \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gronager@ceptacle$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox