diff options
| author | Mike Hearn <mike@plan99.net> | 2012-10-10 13:19:00 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2012-10-10 11:19:12 +0000 |
| commit | ed04da69109355c5e4afdfb9fc336f6aa3c1a377 (patch) | |
| tree | 6b1d742bddf2877b02b4936f64ed9bc99fa13436 | |
| parent | d42fc212bfb8545c7ad7f47bff43ca00eea11951 (diff) | |
| download | pi-bitcoindev-ed04da69109355c5e4afdfb9fc336f6aa3c1a377.tar.gz pi-bitcoindev-ed04da69109355c5e4afdfb9fc336f6aa3c1a377.zip | |
Re: [Bitcoin-development] Electrum security model concerns
| -rw-r--r-- | 5c/e767b15520a20fa42c40947be0e15a41c64349 | 129 |
1 files changed, 129 insertions, 0 deletions
diff --git a/5c/e767b15520a20fa42c40947be0e15a41c64349 b/5c/e767b15520a20fa42c40947be0e15a41c64349 new file mode 100644 index 000000000..074fbe9b4 --- /dev/null +++ b/5c/e767b15520a20fa42c40947be0e15a41c64349 @@ -0,0 +1,129 @@ +Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] + helo=mx.sourceforge.net) + by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <mh.in.england@gmail.com>) id 1TLuJk-0003XN-Jd + for bitcoin-development@lists.sourceforge.net; + Wed, 10 Oct 2012 11:19:12 +0000 +Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com + designates 74.125.82.53 as permitted sender) + client-ip=74.125.82.53; envelope-from=mh.in.england@gmail.com; + helo=mail-wg0-f53.google.com; +Received: from mail-wg0-f53.google.com ([74.125.82.53]) + by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1TLuJf-0003DV-3B + for bitcoin-development@lists.sourceforge.net; + Wed, 10 Oct 2012 11:19:12 +0000 +Received: by mail-wg0-f53.google.com with SMTP id dr1so280555wgb.10 + for <bitcoin-development@lists.sourceforge.net>; + Wed, 10 Oct 2012 04:19:01 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.216.201.156 with SMTP id b28mr14257045weo.4.1349867940884; + Wed, 10 Oct 2012 04:19:00 -0700 (PDT) +Sender: mh.in.england@gmail.com +Received: by 10.216.236.30 with HTTP; Wed, 10 Oct 2012 04:19:00 -0700 (PDT) +In-Reply-To: <CAAS2fgQjeSBJGOr+qH7PQpTB5cx1rdaPCC2e=2J7OG=5Pby5GA@mail.gmail.com> +References: <CAAS2fgTVp7PhdJMfz-huyOsp=6Ca9wH6cVkedMgntXnK+ZpDXg@mail.gmail.com> + <CANEZrP0bx7c1sm+9o6iXx_OnSdRH6a0jRNQcRb2Z3qbf0KFKiw@mail.gmail.com> + <CAAS2fgQjeSBJGOr+qH7PQpTB5cx1rdaPCC2e=2J7OG=5Pby5GA@mail.gmail.com> +Date: Wed, 10 Oct 2012 13:19:00 +0200 +X-Google-Sender-Auth: Bwirub5s68h7n39qirUQ0CTTG7s +Message-ID: <CANEZrP3u7Nyq0qZDxwgdOmqM=OqVmAYaj-YBDFwY6Ps-XTc46A@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: 1TLuJf-0003DV-3B +Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>, + electrum.desktop@gmail.com +Subject: Re: [Bitcoin-development] Electrum security model concerns +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: Wed, 10 Oct 2012 11:19:12 -0000 + ++gary + +> Electrum also has a daemon for merchants. + +Well, I suggest taking it up with Thomas directly. A thread here won't do m= +uch. + +> Considering the dislike of +> Java that exist reflexively in much of the non-java community and the +> greater ease of deployment and the integration of type-2 split key +> management + +I'm hoping that MultiBit Merchant will provide something similar based +on bcj, ie, you don't have to actually be a Java developer to use it, +it can just talk to your app via POSTs and GETs. + +WRT deterministic wallets, yes, right now that's indeed a competitive +advantage of Electrum. So much code to write, so little time. + +> Generally for thin clients=E2=80=94 a lying server can make clients think +> they've received confirmed payments they haven't, and unless the +> client is constructed to be a bit less thin a lying server can lie +> about input values and cause thin clients to spend large values to +> fees. + +Yes indeed. This also gives [hacked] server operators a way to steal +money from users without private keys, they can get clients to create +some very high fee transactions and then provide them directly to a +miner who promises to cut them in (or they can mine themselves, of +course). + +> Beyond that the protocol between the clients and servers is +> unauthenticated cleartext JSON in TCP. + +I thought it used SSL. Maybe I'm thinking of BCCAPI which is a similar appr= +oach. + +> that the payment is unconfirmed. There is a "pro" mode, that shows +> 'processing' for unconfirmed transactions + +I think communicating transaction confidence to users is something of +an open UI design problem right now. I agree that hiding it entirely +seems suboptimal, but in reality explaining what the risks are for a +given number confirmations is difficult. Given the lack of actually +reported double-spends against unconfirmed transactions, I can +understand this choice, even if I wouldn't recommend it. + +> My only question is will they know this because we as a community and +> the authors of the thin clients provided clear explanations and +> appropriate caution + +Well, I pushed for English-text explanations of clients on bitcoin.org +rather than a feature matrix, for this kind of reason :) Unfortunately +the current texts are too small to really give a detailed explanation +of the security models involved. It may be worth adding one-liners +that link to a page explaining different security models (full, SPV, +superlight). + +One thing I'm really hoping we can find and get agreement on is +somebody clueful and trustworthy to work on the bitcoin.org website. +Bitcoin, the project, needs a stronger voice than it currently has, +partly to speak about such issues. For instance, an FAQ that isn't on +the wiki would be good. And a simple "Welcome to Bitcoin" flow on the +bitcoin.org website that guides people to appropriate clients, teaches +them the security basics, etc, would be excellent. + + |