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
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1UFO3S-0007wN-4y
for bitcoin-development@lists.sourceforge.net;
Tue, 12 Mar 2013 12:11:42 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.49 as permitted sender)
client-ip=209.85.219.49; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f49.google.com;
Received: from mail-oa0-f49.google.com ([209.85.219.49])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UFO3Q-0006F0-2c
for bitcoin-development@lists.sourceforge.net;
Tue, 12 Mar 2013 12:11:42 +0000
Received: by mail-oa0-f49.google.com with SMTP id j6so5552772oag.22
for <bitcoin-development@lists.sourceforge.net>;
Tue, 12 Mar 2013 05:11:34 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.14.226 with SMTP id s2mr11730768oec.124.1363090294763;
Tue, 12 Mar 2013 05:11:34 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.86.169 with HTTP; Tue, 12 Mar 2013 05:11:34 -0700 (PDT)
In-Reply-To: <20130312114426.GA3701@vps7135.xlshosting.net>
References: <CAPg+sBip_4Jtxhq+rm-na2=RSJ_PuoZt+akGgJyo0b_Bwbr1Dw@mail.gmail.com>
<CAPg+sBjm+e=A+edSRHXU7JSqyfSc4hou_SRdQHF48xhKQGA4zA@mail.gmail.com>
<CANEZrP2V9uDQ-dmyaUBbsCuj5u3Mrh+jvU9RDpYkrKQV6+t0tQ@mail.gmail.com>
<FB4ED2C4-8B65-438B-8B77-44234A644051@ceptacle.com>
<20130312114426.GA3701@vps7135.xlshosting.net>
Date: Tue, 12 Mar 2013 13:11:34 +0100
X-Google-Sender-Auth: hJz-zRZwnFBjbYH7VpDkLyMakwk
Message-ID: <CANEZrP1q4SnP=xEn0FNYQw3t6ZuzuLVF48YMr_hmVuYYmsWyfw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.5 (-)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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: 1UFO3Q-0006F0-2c
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Michael Gronager <gronager@ceptacle.com>
Subject: Re: [Bitcoin-development] Warning: many 0.7 nodes break on large
number of tx/block; fork risk
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: Tue, 12 Mar 2013 12:11:42 -0000
I'm not even sure I'd say the upgrade "went wrong". The problem if
anything is the upgrade didn't happen fast enough. If we had run out
of block space a few months from now, or if miners/merchants/exchanges
had upgraded faster, it'd have made more sense to just roll forward
and tolerate the loss of the older clients.
This really reinforces the importance of keeping nodes up to date.
On Tue, Mar 12, 2013 at 12:44 PM, Pieter Wuille <pieter.wuille@gmail.com> w=
rote:
> On Tue, Mar 12, 2013 at 11:13:09AM +0100, Michael Gronager wrote:
>> Yes, 0.7 (yes 0.7!) was not sufficiently tested it had an undocumented a=
nd unknown criteria for block rejection, hence the upgrade went wrong.
>
> We're using "0.7" as a short moniker for all clients, but this was a limi=
tation that all
> BDB-based bitcoins ever had. The bug is simply a limit in the number of l=
ock objects
> that was reached.
>
> It's ironic that 0.8 was supposed to solve all problems we had due to BDB=
(except the
> wallet...), but now it seems it's still coming back to haunt us. I really=
hated telling
> miners to go back to 0.7, given all efforts to make 0.8 signficantly more=
tolerable...
>
>> More space in the block is needed indeed, but the real problem you are d=
escribing is actually not missing space in the block, but proper handling o=
f mem-pool transactions. They should be pruned on two criteria:
>>
>> 1. if they gets to old >24hr
>> 2. if the client is running out of space, then the oldest should probabl=
y be pruned
>>
>> clients are anyway keeping, and re-relaying, their own transactions and =
hence it would mean only little, and only little for clients. Dropping free=
/ old transaction is a much a better behavior than dying... Even a scheme =
where the client dropped all or random mempool txes would be a tolerable wa=
y of handling things (dropping all is similar to a restart, except for no u=
ser intervention).
>
> Right now, mempools are relatively small in memory usage, but with small =
block sizes,
> it indeed risks going up. In 0.8, conflicting (=3Ddouble spending) transa=
ctions in the
> chain cause clearing the mempool of conflicts, so at least the mempool is=
bounded by
> the size of the UTXO subset being spent. Dropping transactions from the m=
emory pool
> when they run out of space seems a correct solution. I'm less convinced a=
bout a
> deterministic time-based rule, as that creates a double spending incentiv=
e at that
> time, and a counter incentive to spam the network with your risking-to-be=
-cleared
> transaction as well.
>
> Regarding the block space, we've seen the pct% of one single block chain =
space consumer
> grow simultaneously with the introduction of larger blocks, so I'm not ac=
tually convinced
> there is right now a big need for larger blocks (note: right now). The co=
mpetition for
> block chain space is mostly an issue for client software which doesn't de=
al correctly
> with non-confirming transactions, and misleading users. It's mostly a usa=
bility problem
> now, but increasing block sizes isn't guaranteed to fix that; it may just=
make more
> space for spam.
>
> However, the presence of this bug, and the fact that a full solution is a=
vailable (0.8),
> probably helps achieving consensus fixing it (=3Da hardfork) is needed, a=
nd we should take
> advantage of that. But please, let's not rush things...
>
> --
> Piter
|
