public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Hearn <mike@plan99•net>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
Date: Fri, 28 Jun 2013 11:05:51 +0200	[thread overview]
Message-ID: <CANEZrP2gv2qus1CKTTSFMYcNQDbrSctKmA03YE_eZFDTQsQhXw@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgTka6Dw94V0-vHBHxG=zadu9EmhKmfVm7Y_dQUUgrTf6w@mail.gmail.com>

> 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.



  parent reply	other threads:[~2013-06-28  9:05 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-27 17:10 Jim
2013-06-27 17:30 ` Jeff Garzik
2013-06-27 18:04   ` Luke-Jr
2013-06-27 18:41     ` Gregory Maxwell
2013-06-27 19:18       ` Jim
2013-06-27 19:40         ` Jim
2013-06-27 19:50           ` Jim
2013-06-27 21:12         ` Alex Kravets
2013-06-27 21:56           ` Jeff Garzik
2013-06-27 22:53             ` Alex Kravets
2013-06-27 22:03           ` Gary Rowe
2013-06-28 10:59       ` John Dillon
2013-06-28  9:10   ` Mike Hearn
2013-06-28 14:24     ` Gavin Andresen
     [not found]       ` <CAFtwHRewE0wgvWsf-785hpCb8ns7wiGaKHAQ-1QmDD-W+diBJA@mail.gmail.com>
2013-06-28 20:37         ` Bill Hees
2013-06-28 20:42           ` Jim
2013-06-30 11:42       ` Mike Hearn
2013-06-30 15:19         ` Jim
2013-06-30 16:39           ` Gary Rowe
2013-07-09  0:22             ` Robert Backhaus
2013-07-09  1:20               ` Caleb James DeLisle
2013-07-09 10:36                 ` Mike Hearn
2013-07-09 10:56                   ` Jim
2013-07-09 11:04                     ` Mike Hearn
2013-07-09 11:13                       ` Will
2013-07-09 11:15                       ` Jim
2013-07-09 11:18                       ` Mike Hearn
2013-07-09 14:00                     ` Daniel F
2013-07-09 14:06                       ` Jeff Garzik
2013-07-09 14:28                         ` Mike Hearn
2013-07-09 14:46                           ` Jim
2013-07-09 14:57                           ` Daniel F
2013-07-09 15:27                             ` Mike Hearn
2013-07-09 15:32                               ` Nick Simpson
2013-07-09 15:51                                 ` Johnathan Corgan
2013-07-09 16:44                                   ` Mike Hearn
2013-07-09 15:59                                 ` Jeff Garzik
2013-07-09 16:03                                   ` Nick Simpson
2013-07-09 22:15                                   ` Andreas Petersson
2013-06-27 17:56 ` Gregory Maxwell
2013-06-27 18:05   ` Alex Kravets
2013-06-27 23:45   ` Caleb James DeLisle
2013-06-28  9:05   ` Mike Hearn [this message]
2013-06-28 10:09     ` John Dillon
2013-06-28 10:20       ` Mike Hearn
2013-06-28 10:32         ` John Dillon
2013-06-30 10:12       ` Peter Todd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CANEZrP2gv2qus1CKTTSFMYcNQDbrSctKmA03YE_eZFDTQsQhXw@mail.gmail.com \
    --to=mike@plan99$(echo .)net \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=gmaxwell@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox