1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
|
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 <mh.in.england@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <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
X-Google-Sender-Auth: q6XPK5Wgc2KA4ZrhhTUU7TkUPsM
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
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 <bitcoin-development@lists.sourceforge.net>
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: <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: 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.
|
