From: Gregory Maxwell <gmaxwell@gmail.com>
To: Mike Hearn <mike@plan99.net>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>,
electrum.desktop@gmail.com
Subject: Re: [Bitcoin-development] Electrum security model concerns
Date: Wed, 10 Oct 2012 11:23:25 -0400 [thread overview]
Message-ID: <CAAS2fgSkVRx3Tk-7ufMDb3a44eTK=6COOh_FBWqrmwH4ogFhgA@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP3u7Nyq0qZDxwgdOmqM=OqVmAYaj-YBDFwY6Ps-XTc46A@mail.gmail.com>
On Wed, Oct 10, 2012 at 7:19 AM, Mike Hearn <mike@plan99.net> 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 approach.
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— 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— first I attempted informally on IRC, now I've brought the
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.
next prev parent reply other threads:[~2012-10-10 15:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-06 16:37 [Bitcoin-development] Electrum security model concerns Gregory Maxwell
2012-10-08 11:52 ` Mike Hearn
2012-10-09 3:22 ` Gregory Maxwell
2012-10-10 11:19 ` Mike Hearn
2012-10-10 14:06 ` Gary Rowe
2012-10-10 15:23 ` Gregory Maxwell [this message]
2012-10-10 15:55 ` Mike Hearn
2012-11-15 23:45 ` Gregory Maxwell
2012-11-16 15:59 ` Mike Hearn
2012-11-16 17:44 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAS2fgSkVRx3Tk-7ufMDb3a44eTK=6COOh_FBWqrmwH4ogFhgA@mail.gmail.com' \
--to=gmaxwell@gmail.com \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=electrum.desktop@gmail.com \
--cc=mike@plan99.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox