Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QrC7p-0002tz-Gh for bitcoin-development@lists.sourceforge.net; Wed, 10 Aug 2011 16:59:25 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of bluematt.me designates 173.246.101.161 as permitted sender) client-ip=173.246.101.161; envelope-from=bitcoin-list@bluematt.me; helo=mail.bluematt.me; Received: from vps.bluematt.me ([173.246.101.161] helo=mail.bluematt.me) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1QrC7n-0001tF-Ah for bitcoin-development@lists.sourceforge.net; Wed, 10 Aug 2011 16:59:25 +0000 Received: from [192.168.0.10] (i59F7664C.versanet.de [89.247.102.76]) by mail.bluematt.me (Postfix) with ESMTPSA id ACA3E2B54 for ; Wed, 10 Aug 2011 18:58:59 +0200 (CEST) From: Matt Corallo To: bitcoin-development@lists.sourceforge.net In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-XP0Gqka9fJ0aMGR0yVdn" Date: Wed, 10 Aug 2011 18:59:14 +0200 Message-ID: <1312995554.17416.22.camel@BMThinkPad.lan.bluematt.me> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 X-Spam-Score: -2.3 (--) 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_PASS SPF: sender matches SPF record -0.8 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1QrC7n-0001tF-Ah Subject: Re: [Bitcoin-development] Roadmap/schedules 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, 10 Aug 2011 16:59:25 -0000 --=-XP0Gqka9fJ0aMGR0yVdn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2011-08-10 at 12:29 -0400, Gavin Andresen wrote: > I've been wading through the pull requests and bug lists to figure out > a roadmap for the next few months. >=20 > Here are the things on my priority list: >=20 > 1. Where are we at with network health? What metrics should we be > using? Is there work to be done? We really don't have too many metrics here. AFAIK the only real metric keeping place would be my dnsseed (as well as the one run by IO- ) and they don't look good (I show about 3x as many 0.3.23 nodes listening as 0.3.24, likely due to the rate that 0.3.23 nodes will drop connections, made worse by recent block size increases). > And meta-issue: can somebody volunteer to be the Bitcoin Network > Health Inspector to keep track of this? Very much needed, didn't TD say something about a friend who wanted to do research in this area? >=20 > 2. We've got a chronic problem with new code causing CRITICAL_SECTION > deadlocks (see issue #453 for the latest). Detecting potential > deadlocks early should be done; longer term I think re-architecting to > be single-threaded/asio is probably the right thing to do. Sipa had begin looking at doing some redoing of the locking system (to support more broad stuff like read-only locks, etc) to solve that exact bug, but I never heard anything about if he actually started writing code or how far he got. >=20 > 3. Wallet security. I'd like to get Matt's wallet encryption shipped > soon, along with all or part of groffer's Multisign patch (#319 -- > since that will enable the creation of trojan-resistant secure wallet > solutions). I was under the impression all that was left on the to-do for 0.4 was wallet import/export testing and merge (and a few bug fixes like #453), I agree #319 should be pulled sometime soon, but maybe for 0.4 just the IsStandard parts in 0.4 as those need to get out first anyway? >=20 > 4. Bug fixing. 44 bugs in the issue list, some of which I think are > already fixed. Anybody else want to volunteer to be BugKeeper? (job > would be: prioritize/assign bugs, make sure they get closed when > they're fixed). Personally, I'd like to see a better bug tracking system used anyway, ie one with a full feature set, better tagging system, etc (I really hate github's system here, but moving would be hard...). Anyway, many of them are future "would be nice to have things" or a minor or annoying bug which effects almost no one (or is at least doesnt keep anyone from using the client) but require a lot of effort to fix. >=20 > 5. Testing. I don't have time to personally test every PULL request, > but if a pull involves more than trivial code changes I'm not going to > pull it unless it has been thoroughly tested. We had a very good rule > at a company I used to work for-- programmers were NOT allowed to be > the only ones to test their own code. Help finding money and/or people > for a dedicated "core bitcoin quality assurance team" is welcome. > More unit tests and automated testing is also certainly welcome. Would be really nice. I'm looking to move the jenkins server somewhere (moving to college means move as much as possible to VPSs instead of my parent's basement where I can't manage it) but it could allow for pretty good sanity tests on patches (which they often currently fail) including unit tests and build tests. If someone trusted wants to part with a VPS or can spare some bitcoins so I can grab one myself, it would be much appreciated (or if someone wants to take over that server, that would be nicer). >=20 > If this was open source blogging software I'd be much less uptight > about testing and code review and bugs. But it's not, it is software > for handling money. >=20 >=20 > Stuff I'd like to see in the release-after-next: >=20 > fClient mode (download headers only, for faster initial startup; I've > started the work, talk to me if you want to take over) Need to talk here, I started work on splitting the block/transaction check/store and net with the ultimate goal of making a nice api that they communicate over (as well as wallet and potentially other) and allowing for a different block/transaction check module for lightweight nodes. It would also mean a bit cleaner codebase which could allow for, say, a partial rewrite of net code without far-reaching changes. Whether or not its even a good idea, I don't know, but I've written some code anyway. > Sipa's wallet and key export/import I was under the impression the plan was for this to go in 0.4 aka next release, but personally, I don't care too much either way. > Move from wxWidgets to qt for the GUI > Un-hardcode fee handling (anybody already working on this?) Sipa did some good thinking through for algorithms that could be really useful here, but I don't think any code was ever written, nor did he finish (is he off doing the studying thing?) >=20 > And research-y features I'd like to see happen soon: >=20 > "Impolite peer" detection/reaction to prevent various DOS/Sybil attacks > Better detection/reaction to double spend attempts or block-chain splits Not sure what is meant here. Personally, I'm animately against any kind of notification to spread through the network in case of a double spend, and I really think it double-spend detection could be very efficiently done now. I was under the impression block-chain splits were fairly efficiently handled already? > Code for mining pool participants that helps keep mining pool operators h= onest >=20 >=20 > Everything else I consider lower priority. But if it is important to > you, is important to other people (and non-controversial), you > thoroughly test it, and there's zero chance it introduces a security > vulnerability... then I'll have no objections to pulling it. >=20 > Did I miss anything important? I'll create a Roadmap page on the > bitcoin wiki if there is general consensus about priorities. Matt --=-XP0Gqka9fJ0aMGR0yVdn 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) iQIcBAABAgAGBQJOQrjdAAoJEBrh01BD4I5UYl4P/jJITnlZrULTgzVPFWvRdbmt MWx15c25/ptcnnpyNc5vKlZlt+IsxFIiRSJS0+mhYcbdaVD6mWU4/lr36uN37BQG 1SG731oKXNa0t9haa4uBMEI/Xe0nSu6IqsRLyC50kUvpNH9xb7inYLWUP33OMbiZ SYbx9cRqVZ/S2g267v5ehuEZKLbRBirbDM/av8sY3+bd51cr7PKH0DmImdmP3F+R iGUEITr00zcmoWnosUXmEdefeFKL49oclNaY/SDozxKmPkoBwkQdq5hGqo2btDIy eV47ELm4HyiwvZh7WPMZgRYZ0bVTQPfXhPuuC/JL7zKzYZN3YjrM1Ota+AxxkDrc nDCs3HzITm+F5rIveFeWeEZoitDkgS/LN+kUN/hjy+Vy5Dn2JXoUPQr0+MKGoemL PpzTGQfhXM5BrrK+JXhrA9YSKhHAv4xgPhUDl33W1BD3Sgw9ogKLrMPjnYCeG2XY 0Oc1+Mz1Z0bBdlaaih3M9KMBoHqeyQcSj5HdcwEEif+DFt9eUUGbBwcDEV4S8wa+ xXOPbDQeyeD5Kgi1o3lEEXnxvVm/ONn7rjK7LwGJdES0+K9Yux5znz1JJ235IsnS D1qRqjl7pVBNcjIwPD4QnWz0OxpeImNYu1uNPoDSsE473GvFzUU3zEjr7Ab7uSAR FdpBtYd4L3aiVJt87J5l =6VS4 -----END PGP SIGNATURE----- --=-XP0Gqka9fJ0aMGR0yVdn--