From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UsUcw-0004qu-Rf for bitcoin-development@lists.sourceforge.net; Fri, 28 Jun 2013 09:05:58 +0000 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; Received: from mail-oa0-f49.google.com ([209.85.219.49]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UsUcv-0000Cs-51 for bitcoin-development@lists.sourceforge.net; Fri, 28 Jun 2013 09:05:58 +0000 Received: by mail-oa0-f49.google.com with SMTP id n9so2004770oag.22 for ; Fri, 28 Jun 2013 02:05:51 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.230.163 with SMTP id sz3mr5992251obc.81.1372410351700; Fri, 28 Jun 2013 02:05:51 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.23.36 with HTTP; Fri, 28 Jun 2013 02:05:51 -0700 (PDT) In-Reply-To: References: <1372353053.10405.140661249237317.77984E1F@webmail.messagingengine.com> Date: Fri, 28 Jun 2013 11:05:51 +0200 X-Google-Sender-Auth: q6XPK5Wgc2KA4ZrhhTUU7TkUPsM Message-ID: From: Mike Hearn To: Gregory Maxwell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.5 (-) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 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: 1UsUcv-0000Cs-51 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 09:05:59 -0000 > 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.