summaryrefslogtreecommitdiff
path: root/45/f0e8064599f1b65312e7f349c39097bba07cf0
blob: efa06fdfa2787e4a324a12a29163089d03e65881 (plain)
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
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gronager@ceptacle.com>) id 1UFOJ4-0001Hw-Aa
	for bitcoin-development@lists.sourceforge.net;
	Tue, 12 Mar 2013 12:27:50 +0000
X-ACL-Warn: 
Received: from 2508ds5-oebr.1.fullrate.dk ([90.184.5.129]
	helo=mail.ceptacle.com)
	by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1UFOJ0-00028p-Hs for bitcoin-development@lists.sourceforge.net;
	Tue, 12 Mar 2013 12:27:50 +0000
Received: from localhost (localhost [127.0.0.1])
	by mail.ceptacle.com (Postfix) with ESMTP id BABEB2B86121;
	Tue, 12 Mar 2013 13:27:40 +0100 (CET)
X-Virus-Scanned: amavisd-new at ceptacle.com
Received: from mail.ceptacle.com ([127.0.0.1])
	by localhost (server.ceptacle.private [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id tbakdGFduNLP; Tue, 12 Mar 2013 13:27:33 +0100 (CET)
Received: from [109.105.106.206] (unknown [109.105.106.206])
	by mail.ceptacle.com (Postfix) with ESMTPSA id 9B1552B8610A;
	Tue, 12 Mar 2013 13:27:33 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Michael Gronager <gronager@ceptacle.com>
In-Reply-To: <CANEZrP1q4SnP=xEn0FNYQw3t6ZuzuLVF48YMr_hmVuYYmsWyfw@mail.gmail.com>
Date: Tue, 12 Mar 2013 13:27:32 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <D4AD3716-0349-4294-989D-F034A26B295A@ceptacle.com>
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>
	<CANEZrP1q4SnP=xEn0FNYQw3t6ZuzuLVF48YMr_hmVuYYmsWyfw@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
X-Mailer: Apple Mail (2.1499)
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1UFOJ0-00028p-Hs
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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:27:50 -0000

Well a reversed upgrade is an upgrade that went wrong ;)

Anyway, the incident makes it even more important for people to upgrade, =
well except, perhaps, for miners...

Forks are caused by rejection criteria, hence:=20
1. If you introduce new rejection criteria in an upgrade miners should =
upgrade _first_.
2. If you loosen some rejection criteria miners should upgrade _last_.
3. If you keep the same criteria assume 2.

/M

On 12/03/2013, at 13:11, Mike Hearn <mike@plan99.net> wrote:

> 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.
>=20
> This really reinforces the importance of keeping nodes up to date.
>=20
> On Tue, Mar 12, 2013 at 12:44 PM, Pieter Wuille =
<pieter.wuille@gmail.com> wrote:
>> 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 and unknown criteria for block rejection, hence the upgrade =
went wrong.
>>=20
>> We're using "0.7" as a short moniker for all clients, but this was a =
limitation that all
>> BDB-based bitcoins ever had. The bug is simply a limit in the number =
of lock objects
>> that was reached.
>>=20
>> 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...
>>=20
>>> More space in the block is needed indeed, but the real problem you =
are describing is actually not missing space in the block, but proper =
handling of mem-pool transactions. They should be pruned on two =
criteria:
>>>=20
>>> 1. if they gets to old >24hr
>>> 2. if the client is running out of space, then the oldest should =
probably be pruned
>>>=20
>>> 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 way of handling things (dropping all is =
similar to a restart, except for no user intervention).
>>=20
>> 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) =
transactions 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 memory pool
>> when they run out of space seems a correct solution. I'm less =
convinced about a
>> deterministic time-based rule, as that creates a double spending =
incentive at that
>> time, and a counter incentive to spam the network with your =
risking-to-be-cleared
>> transaction as well.
>>=20
>> 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 actually convinced
>> there is right now a big need for larger blocks (note: right now). =
The competition for
>> block chain space is mostly an issue for client software which =
doesn't deal correctly
>> with non-confirming transactions, and misleading users. It's mostly a =
usability problem
>> now, but increasing block sizes isn't guaranteed to fix that; it may =
just make more
>> space for spam.
>>=20
>> However, the presence of this bug, and the fact that a full solution =
is available (0.8),
>> probably helps achieving consensus fixing it (=3Da hardfork) is =
needed, and we should take
>> advantage of that. But please, let's not rush things...
>>=20
>> --
>> Piter
>=20
> =
--------------------------------------------------------------------------=
----
> Symantec Endpoint Protection 12 positioned as A LEADER in The =
Forrester =20
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in =
the =20
> endpoint security space. For insight on selecting the right partner to=20=

> tackle endpoint security challenges, access the full report.=20
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development