> There were a number of issues with it at the time, in > particular the frequent deadlocks— though Mike was saying that those > 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. ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
