From: Matt Corallo <bitcoin-list@bluematt•me>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Roadmap/schedules
Date: Wed, 10 Aug 2011 18:59:14 +0200 [thread overview]
Message-ID: <1312995554.17416.22.camel@BMThinkPad.lan.bluematt.me> (raw)
In-Reply-To: <CABsx9T2pTg8YG_Q09cnAvsrxquLO-6cWr1tb=fdWtLPBEyJzng@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5971 bytes --]
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.
>
> 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?
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?
>
> 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.
>
> 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?
>
> 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.
>
> 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).
>
> 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)
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?)
>
> 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
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 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.
Matt
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2011-08-10 16:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-10 16:29 Gavin Andresen
2011-08-10 16:59 ` Matt Corallo [this message]
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=1312995554.17416.22.camel@BMThinkPad.lan.bluematt.me \
--to=bitcoin-list@bluematt$(echo .)me \
--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