diff options
author | Mike Hearn <mike@plan99.net> | 2013-06-28 11:05:51 +0200 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2013-06-28 09:05:58 +0000 |
commit | ebe0e0e3692055869bb7516221e5c266a0b64742 (patch) | |
tree | d42e27957749f51805642af7dddec97423798ff1 | |
parent | 53ee6c4e10791334a48218da7a0ad34b750d6afd (diff) | |
download | pi-bitcoindev-ebe0e0e3692055869bb7516221e5c266a0b64742.tar.gz pi-bitcoindev-ebe0e0e3692055869bb7516221e5c266a0b64742.zip |
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
-rw-r--r-- | 0e/6ec01eadbae7610a33d0242c1eff57928fa59e | 108 |
1 files changed, 108 insertions, 0 deletions
diff --git a/0e/6ec01eadbae7610a33d0242c1eff57928fa59e b/0e/6ec01eadbae7610a33d0242c1eff57928fa59e new file mode 100644 index 000000000..ef27611fe --- /dev/null +++ b/0e/6ec01eadbae7610a33d0242c1eff57928fa59e @@ -0,0 +1,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. + + |