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
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
|
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 <bitcoin-list@bluematt.me>) id 1Qgn9j-0006TF-Rq
for bitcoin-development@lists.sourceforge.net;
Wed, 13 Jul 2011 00:18:23 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bluematt.me
designates 208.79.240.5 as permitted sender)
client-ip=208.79.240.5; envelope-from=bitcoin-list@bluematt.me;
helo=smtpauth.rollernet.us;
Received: from smtpauth.rollernet.us ([208.79.240.5])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1Qgn9f-0008Gk-KQ
for bitcoin-development@lists.sourceforge.net;
Wed, 13 Jul 2011 00:18:23 +0000
Received: from smtpauth.rollernet.us (localhost [127.0.0.1])
by smtpauth.rollernet.us (Postfix) with ESMTP id 49D98594038
for <bitcoin-development@lists.sourceforge.net>;
Tue, 12 Jul 2011 17:17:57 -0700 (PDT)
Received: from mail.bluematt.me (unknown
[IPv6:2001:470:9ff2:2:20c:29ff:fe16:f239])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
(Authenticated sender: @bluematt.me)
by smtpauth.rollernet.us (Postfix) with ESMTPSA
for <bitcoin-development@lists.sourceforge.net>;
Tue, 12 Jul 2011 17:17:51 -0700 (PDT)
Received: from [IPv6:2001:470:9ff2:1:2c0:caff:fe33:858b] (unknown
[IPv6:2001:470:9ff2:1:2c0:caff:fe33:858b])
by mail.bluematt.me (Postfix) with ESMTPSA id 40A0BB3F8
for <bitcoin-development@lists.sourceforge.net>;
Wed, 13 Jul 2011 02:18:00 +0200 (CEST)
From: Matt Corallo <bitcoin-list@bluematt.me>
To: bitcoin-development@lists.sourceforge.net
In-Reply-To: <602127524.20110712224712@web.de>
References: <602127524.20110712224712@web.de>
Content-Type: multipart/signed; micalg="pgp-sha1";
protocol="application/pgp-signature";
boundary="=-FZNRfq5gHiiJg/l5X17t"
Date: Wed, 13 Jul 2011 02:17:59 +0200
Message-ID: <1310516279.2279.20.camel@Desktop666>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.2
X-Rollernet-Abuse: Processed by Roller Network Mail Services. Contact
abuse@rollernet.us to report violations. Abuse policy:
http://rollernet.us/abuse.php
X-Rollernet-Submit: Submit ID 63da.4e1ce42f.eaaab.0
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 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1Qgn9f-0008Gk-KQ
Subject: Re: [Bitcoin-development] overall bitcoin client code quality
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 Jul 2011 00:18:23 -0000
--=-FZNRfq5gHiiJg/l5X17t
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tue, 2011-07-12 at 22:47 +0100, Michael Offel wrote:
> Monday, July 11, 2011, 12:31:20 AM, Jeff Garzik wrote:
> >> 2. isolation of modules
> > It is a long term goal to move towards 'libbitcoin"
> What about creating a branch and start libbtc by implementing a small
> module like irc or p2p connection handling and use the new lib in the
> client. I think this would be a proper start for a new clean code base
> without having a non functional client for some time and it also
> provides some kind of red line between libbtc (cleaned up code) and
> the old code base, making it easy to maintain order.
> Would this approach be accepted for a merge?
I had been planning on, and putting off starting work on, a central hub
infrastructure to Bitcoin until fairly recently. Its a central hub
where net/main/wallet/etc can subscribe to get notified of new
blocks/txes/etc, push new blocks/txes/etc and can get information about
blocks/txes/etc. I started work fairly recently, but hopefully it will
be functional sometime in the not-too-distant future.
As I said earlier, the Bitcoin code base really isn't all that messy,
its only its lack of clear lines between classes that makes it seem that
way. It does some things inefficiently, however its general algorithms
are quite good the way they stand. (though net could probably stand a
ground-up rewrite of the backend). If you want to rewrite for a more
optimized handling of p2p connections/etc, it would be apprecitated and
(assuming its done well) certainly merged.
>=20
> It was more meant as an rhetorical question. A documented decision
> would give anyone the chance of arguing against the usage of a library
> instead of asking stupid questions. A mailing list archive suits well
> for this type of information, so let me try to get some information
> here. Db4 is an excellent choice if you need indexed database
> functionality without SQL interface. But compared to an stl map lookup
> and fopen, fwrite and fclose it is much harder to understand and
> brings a lot performance overhead. This is true as long as your
> information are small enough to stay in main memory. A stl map storing
> file offsets is also not that hard to write and understand. On the
> other side using an SQL interface would bring the advantage of
> swapping database providers. An enterprise website could use oracle
> while the average user could use sqlite. Also is db4 used for any type
> of disk storage, this makes files like wallet.dat some kind of hard to
> read. It is in no way more secure than storing private key's in an xml
> file. But it is much harder to maintain and understand by the user and
> the average programer.
I can't speak for satoshi here, but I would agree with his decision on
the grounds that BDB offers a good mix. Compared to a sql-driven
library, it offers a much lighter-weight footprint. Compared to rolling
our own, its much, much simpler to use the existing code that people
have spent years writing/optimizing/fixing/etc. It also provides good
Database transactioning which Bitcoin does depend on on some (rare,
though hopefully less so as time goes on) circumstances.
>=20
> >>
> >> 6. hardcoded values
> >> =20
> >> There are tons of hardcoded values for the official and the testnet bl=
ock chain. It would be a great step to move all chain related settings to a=
chain description file. This would allow custom chains and clean up the co=
de.
> > This one is an interesting debate. There is no real reason to do this
> > aside from some questionable code cleanup. Also, there is no reason to
> > encourage improperly-implemented alternate chains. Alternate chains
> > should be designed in such a way as to share the main chain's difficult=
y
> > as described by Mike on the forum, not just make a new chain and hope i=
t
> > sticks.
> It is not that interesting as it looks first.
Interesting might have been the wrong word. Let me rephrase that too
"of hot topic if you ask several people who incessantly create new
chains for no reason other than to create new chains".
> There is no good in
> running multiple chains for production use. To share the difficulty is
> indeed a good start to solve the problem. That's also one of the
> things I don't like off the QBitcoin client.=20
Neither the original client nor any other client or patch currently
implements work-sharing, I don't think you understood my statement here.
I was referring to http://forum.bitcoin.org/?topic=3D7219.0
> What I meant is just
> to have the possibility to have all adjustable parameters in one place
> and to be able to quickly build an internal testnet without crazy
> firewalling to prevent it from dying. The first would allow to detect
> problematic ddos protection settings early and giving the average user
> the possibility to adjust all important settings if he knows what he
> does.
Those parameters are available, though I don't think they show up in
--help output. If someone had the time to go back and document the
parameters not in --help, it would be much appreciated ;)
> That includes not only alternate chains. One could choose to
> include transactions only at a higher fee or at no fee at all.
> Everyone could do such things by changing the code anyway. But not all
> brilliant administrators or users are programmers.
That is yet another debated issue. The transaction (relay) fees are
there for a reason much more than just for the hell of it. If
transaction (relay) fees were easily changeable, they would serve no
purpose as they would all be set to 0. Transaction fee handling needs a
rethinking and recoding, but offering each user the option to just relay
every transaction off the wire is not an option.
>=20
> Tuesday, July 12, 2011, 4:31:07 AM, Gavin Andresen wrote:
> > We'll just tell everybody to stop using bitcoin so much for six months
> > or so while we implement a much better client. It will be exactly
> > like the bitcoin we have now, except with a much nicer internal
> > architecture and much cleaner code-base, and we're pretty sure we can
> > get it done in six months if everything goes exactly as planned.
> It is some kind of arrogant to believe that anyone would stop using
> bitcoin if some programers decide to stop working for some month. And
> it is also fond to not fix bugs in the old code base if they appear.
> Also there are lots of people out there using old clients anyway. The
> important improvement is more about quick extendibility and therefore
> more feature rich secure code. This would not only help the official
> code base, it would also improve trust and result in better external
> bitcoin related projects.
That was not at all the point of that comment. Trying to fix bugs on an
old codebase while rewriting a new one is worthless and just creating
way more effort than is necessary.
Matt
--=-FZNRfq5gHiiJg/l5X17t
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJOHOQrAAoJEBrh01BD4I5Ukg0QAKD2F+J92lSW4ZPLo9qCM5rc
gFYcccO33v8TC4z6M9b/uk1Ax3Nf7URo5MzFRWyB9pOtoqTarmQPdGCvDC031dBk
3D7pWF4kHkpY0nx9G02oBmULf1BF0Dj3L/a5/VYpox5MJuS19/mioiY8ymNSHyTm
LH9+V4OTuYhYnx2GxFHpS0SWTqqoGGQYeUX3+nh5FuPMUPDateJ6YzlYmmGznOkr
ril8CiYxjt98jVGeu8oHhbwbURKLENb9BxxkHPA0W5U3GV7ZxcTNFBpLh6YVIUgZ
orgVF4bpMFufJYRFID5ezzeiVwSmittGJW2LOJOQuuXi052A5WBKfOQR8LthXtqS
arX4iLizZenWtPhibpS7hB3kyZFmLDIYnF4tpST+LL1fddDFocpYOvdAOhP3IXEn
G1wBVp7V7tUId4P78uUWZ59rzTIfwFK0CgWxfhAldqjgJn2MFTP0S6HD1SNeFEZC
FbmVe/xkgYQ6Z+BhwGGXB6Kmu90eF8Il+GtUsq1NbDUP1Han0lOAdtuDdzpNQrWG
m/RqkqTJcNHu0W4Qqd0FOL89S0EIdvr5cqtatx/Dhx6zO2hxxWJlie1qLioHjQ+P
0YMgWCfarfneOTb/5aq/CuzMFWG797oz9GSYWRO//BF3hzm4rTwBRlNBv3IGCJ98
D4Doe7WwRFvicb0VDVfF
=kvjP
-----END PGP SIGNATURE-----
--=-FZNRfq5gHiiJg/l5X17t--
|
