From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 ; 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 ; Wed, 13 Jul 2011 02:18:00 +0200 (CEST) From: Matt Corallo 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--