From: Gavin Andresen <gavinandresen@gmail•com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: [Bitcoin-development] Roadmap/schedules
Date: Wed, 10 Aug 2011 12:29:50 -0400 [thread overview]
Message-ID: <CABsx9T2pTg8YG_Q09cnAvsrxquLO-6cWr1tb=fdWtLPBEyJzng@mail.gmail.com> (raw)
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
next reply other threads:[~2011-08-10 16:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-10 16:29 Gavin Andresen [this message]
2011-08-10 16:59 ` Matt Corallo
2011-08-10 18:57 ` Pieter Wuille
2011-08-11 11:56 ` Mike Hearn
2011-08-11 17:49 ` bgroff
2011-08-10 20:41 ` Jeff Garzik
2011-08-11 8:48 ` Matt Corallo
2011-08-11 18:20 ` Rick Wesson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABsx9T2pTg8YG_Q09cnAvsrxquLO-6cWr1tb=fdWtLPBEyJzng@mail.gmail.com' \
--to=gavinandresen@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox