From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TLy8H-00070r-10 for bitcoin-development@lists.sourceforge.net; Wed, 10 Oct 2012 15:23:37 +0000 Received-SPF: pass (sog-mx-3.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-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1TLy8D-0000sE-6I for bitcoin-development@lists.sourceforge.net; Wed, 10 Oct 2012 15:23:37 +0000 Received: by mail-ie0-f175.google.com with SMTP id c13so1129776ieb.34 for ; Wed, 10 Oct 2012 08:23:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.236.74 with SMTP id us10mr5738603igc.5.1349882605978; Wed, 10 Oct 2012 08:23:25 -0700 (PDT) Received: by 10.64.34.4 with HTTP; Wed, 10 Oct 2012 08:23:25 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Oct 2012 11:23:25 -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.4 (-) 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.0 T_FILL_THIS_FORM_SHORT Fill in a short form with personal information 0.2 AWL AWL: From: address is in the auto white-list X-Headers-End: 1TLy8D-0000sE-6I 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: Wed, 10 Oct 2012 15:23:37 -0000 On Wed, Oct 10, 2012 at 7:19 AM, Mike Hearn wrote: > +gary > >> Electrum also has a daemon for merchants. > > Well, I suggest taking it up with Thomas directly. A thread here won't do= much. I tried in IRC and got no response. These messages are copying the only contact email address I could find. > I thought it used SSL. Maybe I'm thinking of BCCAPI which is a similar ap= proach. Yes, so do a lot of people. It doesn't. > 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 There is a middle ground: You can not hide it without explaining it. AFAICT we don't see ~any questions about the reference client waiting for six confirmations before saying confirmed. > 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. There have been a great many circulated on the network. People don't report all losses=E2=80=94 e.g. we've never seen a report from those who've burned hundreds of bitcoins in fees on transactions. > of the security models involved. It may be worth adding one-liners > that link to a page explaining different security models (full, SPV, > superlight). Perhaps. > 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. I think this is very hard because this matter is rapidly politicized. There are some in the community who will instantly allege misconduct when there is a mis-agreement. Basically: No one sane should want the job, and anyone who wants should on no account be allowed to have it. At this point I think we also will get better results communicating among technical people in order to get the development focus adjusted in a way that mitigates those risks that can be mitigated and those cautions that can be offered offered. After all, if the Electrum project is _unwilling_ to disclose the limitations of their implementation and security model on their own site, even after having them pointed out then someone updating Bitcoin.org to include them will be politically contentious. I want to make sure that we've followed all reasonable avenues before going that route=E2=80=94 first I attempted informally on IRC, now I've brought t= he discussion here... instead of, e.g. starting the process to remove it from the bitcoin.org clients page. > 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 I agree, thats why I started this thread.