summaryrefslogtreecommitdiff
path: root/ba/23f9fb90f4c5bb864d116fcbc9164df090f715
blob: 6fe1bd0f58a0d80a930b6068da37bb8695eea45a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
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 <gavinandresen@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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: <CABsx9T2pTg8YG_Q09cnAvsrxquLO-6cWr1tb=fdWtLPBEyJzng@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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