Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TLQOW-0006yZ-Bw for bitcoin-development@lists.sourceforge.net; Tue, 09 Oct 2012 03:22:08 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.175 as permitted sender) client-ip=209.85.223.175; envelope-from=gmaxwell@gmail.com; helo=mail-ie0-f175.google.com; Received: from mail-ie0-f175.google.com ([209.85.223.175]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1TLQOV-00088A-Er for bitcoin-development@lists.sourceforge.net; Tue, 09 Oct 2012 03:22:08 +0000 Received: by mail-ie0-f175.google.com with SMTP id c13so11466398ieb.34 for ; Mon, 08 Oct 2012 20:22:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.47.227 with SMTP id g3mr440066ign.5.1349752921762; Mon, 08 Oct 2012 20:22:01 -0700 (PDT) Received: by 10.64.34.4 with HTTP; Mon, 8 Oct 2012 20:22:01 -0700 (PDT) In-Reply-To: References: Date: Mon, 8 Oct 2012 23:22:01 -0400 Message-ID: From: Gregory Maxwell To: Mike Hearn Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.3 (-) 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 (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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 0.3 AWL AWL: From: address is in the auto white-list X-Headers-End: 1TLQOV-00088A-Er Cc: Bitcoin Development , 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 03:22:08 -0000 On Mon, Oct 8, 2012 at 7:52 AM, Mike Hearn wrote: > I don't think it's worth worrying about this too much right now. In > future the software end users and merchants use will diverge > significantly. Electrum also has a daemon for merchants. 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 wouldn't be surprised if it became quite popular quickly especially if the status quo of failing to disclose and discuss the security limitations of the client continues. What I've found is that even fairly sophisticated bitcoin participants are actually unaware of the security implications=E2=80=94 not just of thin clients architecturally but of electrum specifically. I think even you may find my findings of the latter a bit surprising. 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 think clients to spend large values to fees. Servers can also monitor clients and deanonymize them and selectively deny service to particular clients or transactions. Thin clients must trust their servers to be available, and to not perform these attacks. Users can use tools like tor to reduce the privacy attacks, but doing so inhibits having a trust relationship to protect against the other attacks. And none of these attacks leave cryptographic proof of their existence, so a victim can't convince the public of a server's treachery. Us experts know about these risks, but I don't think the general users do. But thats not the limit of it=E2=80=94 It seems some people believe Electr= um does majority quorum between servers, complicating attacks arising from the fact that today users virtually never have a reason to trust their server operators. This isn't true=E2=80=94 it connect to one at a ti= me. (And sibyl attacks would make that pretty weak protection even if it did that, as someone could use a a botnet to run tens of thousands of 'servers' (really proxies)). Beyond that the protocol between the clients and servers is unauthenticated cleartext JSON in TCP. So any network advisory with access to the network near the server has the same power to attack as the server operator... and one near the client has the same power to attack as the sum of all the server operators. A passive attacker near the client has full deanonymization power. But I don't even know if any of these limitations matter much=E2=80=94 The electrum client instantly displays unconfirmed transactions and allows users to spend them. The default user interface gives _no_ indication that the payment is unconfirmed. There is a "pro" mode, that shows 'processing' for unconfirmed transactions... but it looks as final as it ever will be once it gets a single confirm. Only the most cautious and well informed users would open the pro interface and right click and select details to see the count=E2=80=94 and even then there is no guidance on what numbers are good (beyond '1'). So I suspect people can probably rob typical electrum users (including electrum running merchants) without actually using any of the above. When a thin client is willing to provide arbitrary features like showing unconfirmed payments and simplified UI without regard to security it removes the functional advantage of running more secure software like SPV and various degrees of full node... the only motivation is security, and it's not much of a motivation when the risks aren't even disclosed. ...and I haven't even gotten into delving into what kind of attacks are possible due to deeper implementation specifics. But I do share your view that people will migrate to stronger client models in the future=E2=80=94 but I don't agree that it will be due to thos= e clients improving (though they will improve), it will be because people will know that they provide better security and will choose them for that reason. 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, or will it be because they're getting robbed blind, producing a bunch of bad press for thin clients in particular and Bitcoin generally?