path: root/5c/eba6d3bfe46875fb42193c80b65a7c544980ee

Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <g.rowe.froot@gmail.com>) id 1TLwvp-0006IN-3o
	for bitcoin-development@lists.sourceforge.net;
	Wed, 10 Oct 2012 14:06:41 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.47 as permitted sender)
	client-ip=209.85.212.47; envelope-from=g.rowe.froot@gmail.com;
	helo=mail-vb0-f47.google.com; 
Received: from mail-vb0-f47.google.com ([209.85.212.47])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1TLwvj-0004Cs-5G
	for bitcoin-development@lists.sourceforge.net;
	Wed, 10 Oct 2012 14:06:41 +0000
Received: by mail-vb0-f47.google.com with SMTP id ez10so438646vbb.34
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 10 Oct 2012 07:06:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.204.197 with SMTP id fn5mr13669349vcb.71.1349877989619;
	Wed, 10 Oct 2012 07:06:29 -0700 (PDT)
Sender: g.rowe.froot@gmail.com
Received: by 10.58.198.46 with HTTP; Wed, 10 Oct 2012 07:06:29 -0700 (PDT)
In-Reply-To: <CANEZrP3u7Nyq0qZDxwgdOmqM=OqVmAYaj-YBDFwY6Ps-XTc46A@mail.gmail.com>
References: <CAAS2fgTVp7PhdJMfz-huyOsp=6Ca9wH6cVkedMgntXnK+ZpDXg@mail.gmail.com>
	<CANEZrP0bx7c1sm+9o6iXx_OnSdRH6a0jRNQcRb2Z3qbf0KFKiw@mail.gmail.com>
	<CAAS2fgQjeSBJGOr+qH7PQpTB5cx1rdaPCC2e=2J7OG=5Pby5GA@mail.gmail.com>
	<CANEZrP3u7Nyq0qZDxwgdOmqM=OqVmAYaj-YBDFwY6Ps-XTc46A@mail.gmail.com>
Date: Wed, 10 Oct 2012 15:06:29 +0100
X-Google-Sender-Auth: PWrgXywdlOPuN-rBa3cy18l_BrM
Message-ID: <CAKm8k+2xaQLrFQdUPQf8W3+82o7=60ZW+EG7PA=d9A23pP6xBA@mail.gmail.com>
From: Gary Rowe <g.rowe@froot.co.uk>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=bcaec54fb4f20fb70204cbb4f603
X-Spam-Score: -0.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
	(g.rowe.froot[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	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: 1TLwvj-0004Cs-5G
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 14:06:41 -0000

--bcaec54fb4f20fb70204cbb4f603
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Just to chime in on the MultiBit Merchant aspect. The architecture is that
MBM is a Java backend, but executes as a simple command line:

java -jar mbm.jar server config.yml

As Mike expects, MBM offers a RESTful API using HAL+JSON. It provides a
comprehensive set of order and invoice processing, accounting,
inventory/delivery management and customer account handling facilities for
use with a wide variety of online business models.

There will be a variety of front ends, one of which is an online shop. They
also have the same startup command structure.

Since most folks are shy of using any technology, it is likely that MBM+<x
client> will be offered as part of a SaaS type solution. This allows anyone
who doesn't have the knowledge to configure it for themselves to make use
of it.

MBM will use BitcoinJ and will depend on a bucket of public keys for
transactions until the HD support is in place to allow generation of public
keys without private keys being present. This removes the need for private
keys to be present on the servers, and allows consumers of the SaaS model
to provide their own transaction keys.

The code is released under MIT license so anyone, anywhere can use it to
build the Bitcoin economy.

More info:
https://github.com/gary-rowe/MultiBitMerchant/wiki/Introduction
http://gary-rowe.com/agilestack/2012/06/06/multibit-merchant-genesis/

On 10 October 2012 12:19, 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.
>
> > 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 thi=
nk
> > 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
> approach.
>
> > 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.
>

--bcaec54fb4f20fb70204cbb4f603
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Just to chime in on the MultiBit Merchant aspect. The architecture is that =
MBM is a Java backend, but executes as a simple command line:<div><br></div=
><div>java -jar mbm.jar server config.yml</div><div><br></div><div>As Mike =
expects, MBM offers a RESTful API using HAL+JSON. It provides a comprehensi=
ve set of order and invoice processing, accounting, inventory/delivery mana=
gement and customer account handling facilities for use with a wide variety=
 of online business models.=C2=A0</div>
<div><br></div><div>There will be a variety of front ends, one of which is =
an online shop. They also have the same startup command structure.</div><di=
v><br></div><div>Since most folks are shy of using any technology, it is li=
kely that MBM+&lt;x client&gt; will be offered as part of a SaaS type solut=
ion. This allows anyone who doesn&#39;t have the knowledge to configure it =
for themselves to make use of it.=C2=A0</div>
<div><br></div><div>MBM will use BitcoinJ and will depend on a bucket of pu=
blic keys for transactions until the HD support is in place to allow genera=
tion of public keys without private keys being present. This removes the ne=
ed for private keys to be present on the servers, and allows consumers of t=
he SaaS model to provide their own transaction keys.</div>
<div><br></div><div>The code is released under MIT license so anyone, anywh=
ere can use it to build the Bitcoin economy.</div><div><br></div><div>More =
info:=C2=A0</div><div><a href=3D"https://github.com/gary-rowe/MultiBitMerch=
ant/wiki/Introduction">https://github.com/gary-rowe/MultiBitMerchant/wiki/I=
ntroduction</a></div>
<div><a href=3D"http://gary-rowe.com/agilestack/2012/06/06/multibit-merchan=
t-genesis/">http://gary-rowe.com/agilestack/2012/06/06/multibit-merchant-ge=
nesis/</a></div><div><br><div class=3D"gmail_quote">On 10 October 2012 12:1=
9, Mike Hearn <span dir=3D"ltr">&lt;<a href=3D"mailto:mike@plan99.net" targ=
et=3D"_blank">mike@plan99.net</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">+gary<br>
<div class=3D"im"><br>
&gt; Electrum also has a daemon for merchants.<br>
<br>
</div>Well, I suggest taking it up with Thomas directly. A thread here won&=
#39;t do much.<br>
<div class=3D"im"><br>
&gt; Considering the dislike of<br>
&gt; Java that exist reflexively in much of the non-java community and the<=
br>
&gt; greater ease of deployment and the integration of type-2 split key<br>
&gt; management<br>
<br>
</div>I&#39;m hoping that MultiBit Merchant will provide something similar =
based<br>
on bcj, ie, you don&#39;t have to actually be a Java developer to use it,<b=
r>
it can just talk to your app via POSTs and GETs.<br>
<br>
WRT deterministic wallets, yes, right now that&#39;s indeed a competitive<b=
r>
advantage of Electrum. So much code to write, so little time.<br>
<div class=3D"im"><br>
&gt; Generally for thin clients=E2=80=94 a lying server can make clients th=
ink<br>
&gt; they&#39;ve received confirmed payments they haven&#39;t, and unless t=
he<br>
&gt; client is constructed to be a bit less thin a lying server can lie<br>
</div>&gt; about input values and cause thin clients to spend large values =
to<br>
&gt; fees.<br>
<br>
Yes indeed. This also gives [hacked] server operators a way to steal<br>
money from users without private keys, they can get clients to create<br>
some very high fee transactions and then provide them directly to a<br>
miner who promises to cut them in (or they can mine themselves, of<br>
course).<br>
<div class=3D"im"><br>
&gt; Beyond that the protocol between the clients and servers is<br>
&gt; unauthenticated cleartext JSON in TCP.<br>
<br>
</div>I thought it used SSL. Maybe I&#39;m thinking of BCCAPI which is a si=
milar approach.<br>
<div class=3D"im"><br>
&gt; that the payment is unconfirmed. There is a &quot;pro&quot; mode, that=
 shows<br>
&gt; &#39;processing&#39; for unconfirmed transactions<br>
<br>
</div>I think communicating transaction confidence to users is something of=
<br>
an open UI design problem right now. I agree that hiding it entirely<br>
seems suboptimal, but in reality explaining what the risks are for a<br>
given number confirmations is difficult. Given the lack of actually<br>
reported double-spends against unconfirmed transactions, I can<br>
understand this choice, even if I wouldn&#39;t recommend it.<br>
<div class=3D"im"><br>
&gt; My only question is will they know this because we as a community and<=
br>
&gt; the authors of the thin clients provided clear explanations and<br>
&gt; appropriate caution<br>
<br>
</div>Well, I pushed for English-text explanations of clients on <a href=3D=
"http://bitcoin.org" target=3D"_blank">bitcoin.org</a><br>
rather than a feature matrix, for this kind of reason :) Unfortunately<br>
the current texts are too small to really give a detailed explanation<br>
of the security models involved. It may be worth adding one-liners<br>
that link to a page explaining different security models (full, SPV,<br>
superlight).<br>
<br>
One thing I&#39;m really hoping we can find and get agreement on is<br>
somebody clueful and trustworthy to work on the <a href=3D"http://bitcoin.o=
rg" target=3D"_blank">bitcoin.org</a> website.<br>
Bitcoin, the project, needs a stronger voice than it currently has,<br>
partly to speak about such issues. For instance, an FAQ that isn&#39;t on<b=
r>
the wiki would be good. And a simple &quot;Welcome to Bitcoin&quot; flow on=
 the<br>
<a href=3D"http://bitcoin.org" target=3D"_blank">bitcoin.org</a> website th=
at guides people to appropriate clients, teaches<br>
them the security basics, etc, would be excellent.<br>
</blockquote></div><br></div>

--bcaec54fb4f20fb70204cbb4f603--