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
86
87
88
89
90
91
92
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1UFlVR-0000Wl-Eh
for bitcoin-development@lists.sourceforge.net;
Wed, 13 Mar 2013 13:14:09 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.45 as permitted sender)
client-ip=209.85.215.45; envelope-from=gmaxwell@gmail.com;
helo=mail-la0-f45.google.com;
Received: from mail-la0-f45.google.com ([209.85.215.45])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UFlVP-0002DV-JX
for bitcoin-development@lists.sourceforge.net;
Wed, 13 Mar 2013 13:14:09 +0000
Received: by mail-la0-f45.google.com with SMTP id er20so1076148lab.4
for <bitcoin-development@lists.sourceforge.net>;
Wed, 13 Mar 2013 06:14:00 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.125.239 with SMTP id mt15mr17606144lab.26.1363180440883;
Wed, 13 Mar 2013 06:14:00 -0700 (PDT)
Received: by 10.112.96.164 with HTTP; Wed, 13 Mar 2013 06:14:00 -0700 (PDT)
In-Reply-To: <201303131256.30144.luke@dashjr.org>
References: <201303131256.30144.luke@dashjr.org>
Date: Wed, 13 Mar 2013 06:14:00 -0700
Message-ID: <CAAS2fgRJxx3VwBoQm2Tkwr-DbAg6wQityzegZXxddXbqBSh8dQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1UFlVP-0002DV-JX
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] 0.8.1 ideas
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 13:14:09 -0000
On Wed, Mar 13, 2013 at 5:56 AM, Luke-Jr <luke@dashjr.org> wrote:
> FROM block 262144 to block 393216 (hard fork #1):
> - Never make, and reject any block that includes more than 24391 transaction
> modifications on its own (this *should* be equivalent to 1 MB)
> - (this rules can make older client backports safe unless a reorg is more than
> 6 blocks deep)
I'm not a fan of the two stages, your before block 262144 part sounds
fine to me, though I thought the safe number was closer to 5000.
Perhaps 4911?
The goal here is to pick something which is _absolutely sure_ to be
less than what pre-0.8 accepts (so that its is just a soft fork), but
it need not be needlessly smaller than that.
I think we can accept some small risk of "backport" clients getting
stuck after large reorgs after there has been sufficient upgrade time.
Performance reasons mean that its very likely no one will be mining
on those nodes by then, and so if they get stuck they'll just need to
manually unstick them. Difficulty is high enough that its unlikely
anything important will remain stuck long enough for a malicious party
to exploit them by mining blocks on the stuck fork.
By allowing that risk you halve the complexity of your change by not
requiring two hard forks. The 'never make' half of it would probably
be fine.
As far as the size change, that should be a separate process after
we've proven the ability to make a hardforking change with something
low risk/low controversy like this, and only after someone has
actually shown that the software is stable under those conditions lest
we get another issue like we have now where the increase in block
target from 500k/250k to 1MB by a miner exposed inadequate testing.
|
