path: root/12/dccc12124628349253f37e0810f768554c7b6f

Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <bitcoin-list@bluematt.me>) id 1QrC7p-0002tz-Gh
	for bitcoin-development@lists.sourceforge.net;
	Wed, 10 Aug 2011 16:59:25 +0000
Received-SPF: pass (sog-mx-4.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-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1QrC7n-0001tF-Ah for bitcoin-development@lists.sourceforge.net;
	Wed, 10 Aug 2011 16:59:25 +0000
Received: from [192.168.0.10] (i59F7664C.versanet.de [89.247.102.76])
	by mail.bluematt.me (Postfix) with ESMTPSA id ACA3E2B54
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 10 Aug 2011 18:58:59 +0200 (CEST)
From: Matt Corallo <bitcoin-list@bluematt.me>
To: bitcoin-development@lists.sourceforge.net
In-Reply-To: <CABsx9T2pTg8YG_Q09cnAvsrxquLO-6cWr1tb=fdWtLPBEyJzng@mail.gmail.com>
References: <CABsx9T2pTg8YG_Q09cnAvsrxquLO-6cWr1tb=fdWtLPBEyJzng@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha1";
	protocol="application/pgp-signature";
	boundary="=-XP0Gqka9fJ0aMGR0yVdn"
Date: Wed, 10 Aug 2011 18:59:14 +0200
Message-ID: <1312995554.17416.22.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: 1QrC7n-0001tF-Ah
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: Wed, 10 Aug 2011 16:59:25 -0000


--=-XP0Gqka9fJ0aMGR0yVdn
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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.
>=20
> Here are the things on my priority list:
>=20
> 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?
>=20
> 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.
>=20
> 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?
>=20
> 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.
>=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.
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).
>=20
> 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.
>=20
>=20
> Stuff I'd like to see in the release-after-next:
>=20
> 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?)
>=20
> And research-y features I'd like to see happen soon:
>=20
> "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 h=
onest
>=20
>=20
> 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.
>=20
> Did I miss anything important? I'll create a Roadmap page on the
> bitcoin wiki if there is general consensus about priorities.


Matt

--=-XP0Gqka9fJ0aMGR0yVdn
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)

iQIcBAABAgAGBQJOQrjdAAoJEBrh01BD4I5UYl4P/jJITnlZrULTgzVPFWvRdbmt
MWx15c25/ptcnnpyNc5vKlZlt+IsxFIiRSJS0+mhYcbdaVD6mWU4/lr36uN37BQG
1SG731oKXNa0t9haa4uBMEI/Xe0nSu6IqsRLyC50kUvpNH9xb7inYLWUP33OMbiZ
SYbx9cRqVZ/S2g267v5ehuEZKLbRBirbDM/av8sY3+bd51cr7PKH0DmImdmP3F+R
iGUEITr00zcmoWnosUXmEdefeFKL49oclNaY/SDozxKmPkoBwkQdq5hGqo2btDIy
eV47ELm4HyiwvZh7WPMZgRYZ0bVTQPfXhPuuC/JL7zKzYZN3YjrM1Ota+AxxkDrc
nDCs3HzITm+F5rIveFeWeEZoitDkgS/LN+kUN/hjy+Vy5Dn2JXoUPQr0+MKGoemL
PpzTGQfhXM5BrrK+JXhrA9YSKhHAv4xgPhUDl33W1BD3Sgw9ogKLrMPjnYCeG2XY
0Oc1+Mz1Z0bBdlaaih3M9KMBoHqeyQcSj5HdcwEEif+DFt9eUUGbBwcDEV4S8wa+
xXOPbDQeyeD5Kgi1o3lEEXnxvVm/ONn7rjK7LwGJdES0+K9Yux5znz1JJ235IsnS
D1qRqjl7pVBNcjIwPD4QnWz0OxpeImNYu1uNPoDSsE473GvFzUU3zEjr7Ab7uSAR
FdpBtYd4L3aiVJt87J5l
=6VS4
-----END PGP SIGNATURE-----

--=-XP0Gqka9fJ0aMGR0yVdn--