Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.49 as permitted sender)
	client-ip=209.85.219.49; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f49.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <CAAS2fgTka6Dw94V0-vHBHxG=zadu9EmhKmfVm7Y_dQUUgrTf6w@mail.gmail.com>
References: <1372353053.10405.140661249237317.77984E1F@webmail.messagingengine.com>
	<CAAS2fgTka6Dw94V0-vHBHxG=zadu9EmhKmfVm7Y_dQUUgrTf6w@mail.gmail.com>
Date: Fri, 28 Jun 2013 11:05:51 +0200
Message-ID: <CANEZrP2gv2qus1CKTTSFMYcNQDbrSctKmA03YE_eZFDTQsQhXw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: MultiBit as default desktop
 client on bitcoin.org
Precedence: list

> There were a number of issues with it at the time, in
> particular the frequent deadlocks=E2=80=94 though Mike was saying that th=
ose
> should be fixed.

Yes. There were a number of lock cycles that didn't cause issues so
much when traffic was lower and as Bitcoin got more popular it became
a critical problem. I redid a lot of the concurrency to fix that, and
now all the core locks are cycle detecting so regressions should be
detected fairly fast. I'm still making changes to the concurrency
design but mostly to improve the API at this point, not fix bugs.

There is one deadlock I'm still aware of, thanks to Netty. However
it's very rare and was only reported by someone who kept a server
running for many days in a row. We want to junk Netty soon anyway.
It's a network library but it doesn't really add much value for our
use case and it turned out to have some serious design issues
internally.

> I see some of the the other things that were concerning for me at the
> time are still uncorrected though, e.g. no proxy support (so users
> can't follow our recommended best practices of using it with Tor),

Yeah. That's not the primary privacy issue with bitcoinj though. I'm
much, much more concerned about leaks via the block chain than the
network layer. Especially as Tor is basically a giant man in the
middle, without any kind of authentication you can easily end up
connected to a sybil network without any idea. I'd be surprised if Tor
usage was very high amongst Bitcoin users.

> that it reuses addresses (esp for change), that it doesn't clearly
> distinguish confirmation level.

It does actually, but the iconography is not very clear. I'm not
convinced any users really care about the difference between two and
three blocks these days. Maybe exchanges and other security-critical
applications do, but I doubt desktop users do.

It's not a library limitation anyway, it's a case of how best to
present information to a user who is not familiar with how Bitcoin
works. "Safe" and "Not safe" is still a rather misleading distinction
given the general absence of double spends against mempool
transactions, but it's still a lot more meaningful than "2 confirms"
vs "3 confirms", something that would just make a new user ask what
the heck a confirm is.