1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pw@vps7135.xlshosting.net>) id 1UFqPN-0000Ec-0f
for bitcoin-development@lists.sourceforge.net;
Wed, 13 Mar 2013 18:28:13 +0000
X-ACL-Warn:
Received: from vps7135.xlshosting.net ([178.18.90.41])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1UFqPM-0001R9-2f for bitcoin-development@lists.sourceforge.net;
Wed, 13 Mar 2013 18:28:12 +0000
Received: by vps7135.xlshosting.net (Postfix, from userid 1000)
id 7B74333C896; Wed, 13 Mar 2013 19:28:06 +0100 (CET)
Date: Wed, 13 Mar 2013 19:28:06 +0100
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Michael Gronager <gronager@ceptacle.com>
Message-ID: <20130313182805.GA7921@vps7135.xlshosting.net>
References: <CABsx9T0xOpNpFG4bo7wjcMV8a_xtw_jrRx_fiSutX08yfP8P7Q@mail.gmail.com>
<20130313174838.GA22621@savin>
<2FCCE0F7-66B0-4EBE-8448-C5F0F92A75FF@ceptacle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2FCCE0F7-66B0-4EBE-8448-C5F0F92A75FF@ceptacle.com>
X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Score: -1.2 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(pieter.wuille[at]gmail.com)
0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is
CUSTOM_MED
-2.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit,
and not from a mailing list
X-Headers-End: 1UFqPM-0001R9-2f
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Blocksize and off-chain transactions
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 13 Mar 2013 18:28:13 -0000
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
|
