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
147
148
149
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bitcoin-list@bluematt.me>) id 1QrQwA-0006Ce-01
for bitcoin-development@lists.sourceforge.net;
Thu, 11 Aug 2011 08:48:22 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of bluematt.me
designates 173.246.101.161 as permitted sender)
client-ip=173.246.101.161;
envelope-from=bitcoin-list@bluematt.me; helo=mail.bluematt.me;
Received: from vps.bluematt.me ([173.246.101.161] helo=mail.bluematt.me)
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1QrQw6-0001Dr-TA for bitcoin-development@lists.sourceforge.net;
Thu, 11 Aug 2011 08:48:19 +0000
Received: from [192.168.0.10] (i59F7121B.versanet.de [89.247.18.27])
by mail.bluematt.me (Postfix) with ESMTPSA id B24072B54
for <bitcoin-development@lists.sourceforge.net>;
Thu, 11 Aug 2011 10:47:52 +0200 (CEST)
From: Matt Corallo <bitcoin-list@bluematt.me>
To: bitcoin-development@lists.sourceforge.net
In-Reply-To: <CA+8xBpeuzO9+BWZtgpR8h2rSRdB-gQYjq9pyKnbxgBHDX=UnZg@mail.gmail.com>
References: <CABsx9T2pTg8YG_Q09cnAvsrxquLO-6cWr1tb=fdWtLPBEyJzng@mail.gmail.com>
<CA+8xBpeuzO9+BWZtgpR8h2rSRdB-gQYjq9pyKnbxgBHDX=UnZg@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha1";
protocol="application/pgp-signature";
boundary="=-xfGa2Ti5uc8BMypYniIM"
Date: Thu, 11 Aug 2011 10:48:09 +0200
Message-ID: <1313052489.20348.5.camel@BMThinkPad.lan.bluematt.me>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.2
X-Spam-Score: -2.3 (--)
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 SPF_PASS SPF: sender matches SPF record
-0.8 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1QrQw6-0001Dr-TA
Subject: Re: [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: Thu, 11 Aug 2011 08:48:22 -0000
--=-xfGa2Ti5uc8BMypYniIM
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> > 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).
>=20
> IMO the only thing lacking is docs. There is no real admin guide
> describing how to prepare bitcoind installations for encryption;
> doc/README does not mention RPC encryptwallet at all, nor does it
> describe the various states your wallet may be in, when before and
> after encryptwallet has been run. The information is very general,
> and not adequate for a competent admin to be able to evaluate. It
> does not describe encryption method or other security parameters. It
> does not describe the specific technical relationship between the
> master key and other keys.
My fault, Ill write something up on the train back today.
>=20
> > 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.
>=20
> I think Q/A will naturally grow out of some sort of dedicated support
> organization, rather than have a dev fiat requirement. Testing like
> that is always desireable in the "I'd love it, if it were this way"
> vein, but not always realistic at all for open source projects.
> Especially with open source, time has shown that the best testing
> comes from the field, and we have the biggest test lab in the world:
> the Internet. So IMO focus less on roadblocks to publishing software,
> and more on widely distributed test software.
>=20
> For new features, simple "it works" test at a minimum seems
> reasonable, most of the time. But in open source the testing and such
> tends to happen in the periphery, by organizations and individuals
> with the incentive to focus on those issues.
>=20
> In my recent emails describing linux-next and a proposed
> "bitcoin-next", one attribute of linux-next is that it is run through
> automated tests on a daily basis, right after the merge is complete.
> It forms a useful layer on top of the primary linux project & tree.
Jenkins + a large enough test suite could do very nice automatic sanity
testing IMHO...that is what it is designed for (even if not to
automatically test pre-merge, but it could be adapted). Many pull
requests build on Linux, but not on MinGW, OSX, etc so just that would
be useful IMHO.
> Not a big deal to me, I never use GUI :)
>=20
> > Un-hardcode fee handling (anybody already working on this?)
>=20
> Has anyone actually come up with a good idea to code?
>=20
> This is a widely acknowledged problem, sure, but where are the good
> solutions, even on paper?
Sipa's stuff is quite good IMHO, it still has some problems left to
solve (like choosing minor details of the underlying priority algorithm)
but aside from those, I think it could work. I'm not sure if sipa wants
to just publish the stuff he did so far and let this list debate on the
remaining details and eventual implementation, or if he wanted to come
up with something complete before publishing, it up to him, but it is
doable.
Matt
--=-xfGa2Ti5uc8BMypYniIM
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJOQ5dIAAoJEBrh01BD4I5UH2YP/RlEsmtqzPMmsCqTeHDPhDuM
489YTZH2hY68Cz4+wJWCrMmBvlmU8MuY4rBOJ6KC31BKhUTGhDunOGrgNTFmnEMf
VsZviNYKu19B2sUTblwVflyIM1DFJ1yLhKjeySO7jxN53wESj2z/SYAdc4FWitN6
SKMUrDY0CHV3goJoY7zU3PvvzCENfXAmy/JCLyXuU62g0SeyTlEVEJKODAxZSfdi
6fJ5STOpDust9wTWB8bBUZbpC3s596Jur7Kf+hxwY4tk6zVKxuKVap4bBVvDg7uN
DZmfFGyBFp489ifeZb9DGGaYtkdllFeUNcHhRu8gxbkcn53RYBJE7EcEHCgmecxI
2oFu0eZuZ6igyMZ4T0gVF8QgaltYorZQIvid8rrdW6YWVHcxUK49BrsZ5NONdIY7
flQ2IuzBOiBBkXLIbwa+o2gzUSQ/hS040RQCN/S1FKncP+M1xcQL5ZQXXx0+xkDj
uzE3ez7cBFlaXDe3TL01uuvrrcj55o0poZaekuAP+kAlHvDp9ListCHH7AGGFrxJ
UYmM7BvTBrKB5FG6dRvrSpf+exurBASgsZiv8EQKMC0X7mxrIBykMofWQFgIk2Bx
JrSqg+4/tXppxu3hQ1r9J5S99uoGZ4wAAzCEikmQi5tQl8Y8inmcGvoqlWdFWj0s
7roBcyWtAQMjsPl35Oyv
=JKDl
-----END PGP SIGNATURE-----
--=-xfGa2Ti5uc8BMypYniIM--
|
