Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QrBfJ-0000sj-KF for bitcoin-development@lists.sourceforge.net; Wed, 10 Aug 2011 16:29:57 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.210.42 as permitted sender) client-ip=209.85.210.42; envelope-from=gavinandresen@gmail.com; helo=mail-pz0-f42.google.com; Received: from mail-pz0-f42.google.com ([209.85.210.42]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1QrBfI-0000wu-TG for bitcoin-development@lists.sourceforge.net; Wed, 10 Aug 2011 16:29:57 +0000 Received: by pzk37 with SMTP id 37so2102345pzk.1 for ; Wed, 10 Aug 2011 09:29:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.150.12 with SMTP id x12mr42322wfd.90.1312993790982; Wed, 10 Aug 2011 09:29:50 -0700 (PDT) Received: by 10.142.212.13 with HTTP; Wed, 10 Aug 2011 09:29:50 -0700 (PDT) Date: Wed, 10 Aug 2011 12:29:50 -0400 Message-ID: From: Gavin Andresen To: Bitcoin Dev Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.1 (-) 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 (gavinandresen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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 0.5 AWL AWL: From: address is in the auto white-list X-Headers-End: 1QrBfI-0000wu-TG Subject: [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:29:57 -0000 I've been wading through the pull requests and bug lists to figure out a roadmap for the next few months. Here are the things on my priority list: 1. Where are we at with network health? What metrics should we be using? Is there work to be done? And meta-issue: can somebody volunteer to be the Bitcoin Network Health Inspector to keep track of this? 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. 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). 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). 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. 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. Stuff I'd like to see in the release-after-next: fClient mode (download headers only, for faster initial startup; I've started the work, talk to me if you want to take over) Sipa's wallet and key export/import Move from wxWidgets to qt for the GUI Un-hardcode fee handling (anybody already working on this?) And research-y features I'd like to see happen soon: "Impolite peer" detection/reaction to prevent various DOS/Sybil attacks Better detection/reaction to double spend attempts or block-chain splits Code for mining pool participants that helps keep mining pool operators honest 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. Did I miss anything important? I'll create a Roadmap page on the bitcoin wiki if there is general consensus about priorities. -- -- Gavin Andresen