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
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1RSeoo-0001M2-0R
for bitcoin-development@lists.sourceforge.net;
Tue, 22 Nov 2011 01:06:38 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.161.47 as permitted sender)
client-ip=209.85.161.47; envelope-from=gavinandresen@gmail.com;
helo=mail-fx0-f47.google.com;
Received: from mail-fx0-f47.google.com ([209.85.161.47])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RSeoj-0005z4-Q5
for bitcoin-development@lists.sourceforge.net;
Tue, 22 Nov 2011 01:06:37 +0000
Received: by faat2 with SMTP id t2so9437015faa.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 21 Nov 2011 17:06:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.104.130 with SMTP id ge2mr10539900lab.43.1321923987472;
Mon, 21 Nov 2011 17:06:27 -0800 (PST)
Received: by 10.152.30.69 with HTTP; Mon, 21 Nov 2011 17:06:27 -0800 (PST)
Date: Mon, 21 Nov 2011 20:06:27 -0500
Message-ID: <CABsx9T2w7X1WJAMe6yuGcpZegb5G9Tjawt-Uk7d2RH7GAgoJaQ@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.6 (-)
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
X-Headers-End: 1RSeoj-0005z4-Q5
Subject: [Bitcoin-development] State of Bitcoin Development: November Brain
Dump
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: Tue, 22 Nov 2011 01:06:38 -0000
It has been a busy month; here's what I'm thinking about:
=95 It's great to get 0.5 out; congratulations to Wladimir for doing a
great job with the new GUI.
=95 The wallet encryption bug was embarrassing and stressful, and chewed
up a lot of my time over the past couple of weeks. Bugs happen, but
I've been spending time thinking about what I can do differently to
make it less likely major bugs slip into releases.
Finding the money to hire some professional QA people to help create
test plans and then execute them (the test plans, not the QA people)
is one possible answer. If you have experience finding funding for
open source projects (or know somebody who does) I'd like to talk with
you-- I would much rather spend my time writing code and thinking
about technical issues instead of trying to figure out if advertising
or sponsorship or a Donate menu entry in the client is a reasonable
way to get more testing resources for the project.
Last month I mentioned I was thinking about Organization; there is a
non-profit organization forming to handle Bitcoin PR and marketing,
which takes care of one big area of work.
=95 The BIP (Bitcoin Improvement Proposal) process seems to be working
well, with good proposals and good discussions (both here and on the
Forums):
https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals
Things I think are high priority but am not planning on working on:
=95 Implement BIP 14 (separate the protocol and client versions)
=95 Rework/rethink wallet handling: I think we could do a much better
job with both encryption and backups.
=95 Work on higher-level multi-signature/multi-device transaction
approval; I really want a version of bitcoin-qt that requires me to
poke an "OK" button on my iPhone before it can send coins.
=95 Code clean-up; I'd like to see more small code refactors that moves
non-performance-critical code from .h files to .cpp files, makes
classes more self-contained, etc. "Rename the world" or "change every
single file" pull requests are hard to deal with because there is
never a good time to pull them, but a steady stream of "makes the
code a little bit easier to work with" would be a Good Thing.
Especially if you submit unit tests for whatever you touch...
Thinks I think are high priority and AM planning on working on; if any
of them inspire you, feel free to steal them from me, I still have too
many things on my TODO list:
=95 Create a pull request for OP_EVAL/multisignature transactions
=95 Back-port OP_EVAL/multisig to 0.3/0.4 and release patches to make
it easy for the big mining pools to support it, so the network is
ready for multisig/multi-device transactions.
=95 Work on the 'headers-only' branch, so users have a better first-time
experience.
=95=A0I want to start doing some internal re-architecting, and I think
porting my old monitor transactions/blocks patch to use Boost.Signals
might be a good place to start. The internal pieces are pretty
obvious (GUI, database, network, wallet, transaction validation, and
block-chain handling) and I think starting to rearchitect to use
Boost.Signals for internal communications would be a big step towards
more re-usable code.
=95 Get back to the cross-platform testing infrastructure tool, and lots
of good and bad blockchains that can be used for cross-platform
testing.
I'm probably forgetting several things, but I think that's enough for
now. If you're going to the conference in Prague, have fun! Please
figure out all the hard questions while you're there, and report
back....
-------------------
Previous Brain Dump:
https://sourceforge.net/mailarchive/message.php?msg_id=3D28223657
--=20
--
Gavin Andresen
|
