From mboxrd@z Thu Jan 1 00:00:00 1970 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 1YVpZX-0002iy-Ig for bitcoin-development@lists.sourceforge.net; Wed, 11 Mar 2015 22:57:51 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.175 as permitted sender) client-ip=209.85.212.175; envelope-from=voisine@gmail.com; helo=mail-wi0-f175.google.com; Received: from mail-wi0-f175.google.com ([209.85.212.175]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YVpZW-0000a1-1l for bitcoin-development@lists.sourceforge.net; Wed, 11 Mar 2015 22:57:51 +0000 Received: by widem10 with SMTP id em10so15777203wid.2 for ; Wed, 11 Mar 2015 15:57:44 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.23.39 with SMTP id j7mr83501896wjf.9.1426114664071; Wed, 11 Mar 2015 15:57:44 -0700 (PDT) Received: by 10.27.76.193 with HTTP; Wed, 11 Mar 2015 15:57:43 -0700 (PDT) In-Reply-To: References: <54F32EED.6040103@electrum.org> <550057FD.6030402@electrum.org> <1426100677.1908596.239033309.7C4F8D47@webmail.messagingengine.com> Date: Wed, 11 Mar 2015 15:57:43 -0700 Message-ID: From: Aaron Voisine To: Gregory Maxwell Content-Type: multipart/alternative; boundary=047d7b3a8bcef60a9405110b31d5 X-Spam-Score: -0.6 (/) 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 (voisine[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -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 X-Headers-End: 1YVpZW-0000a1-1l Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Electrum 2.0 has been tagged 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, 11 Mar 2015 22:57:51 -0000 --047d7b3a8bcef60a9405110b31d5 Content-Type: text/plain; charset=UTF-8 I'm not convinced that wallet seed interoperability is such a great thing. There is a wide variability in the quality and security level of wallet implementations and platforms. Each new device and wallet software a user types their seed into increases their attack surface and exposure to flaws. Their security level is reduced to the lowest common denominator. I see the need for a "fire exit", certainly, but we must also remember that fire exits are potential entrances for intruders. Aaron Voisine co-founder and CEO breadwallet.com On Wed, Mar 11, 2015 at 12:46 PM, Gregory Maxwell wrote: > On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe > wrote: > > i guess you look at the glass half full :) > > even though what you say is true, we should aim for wallets not to > > require those instructions, by standardizing these things in BIPs. > > let's hope bitcoin doesn't fail in standards as our industries have in > > the past... > > There are genuine principled disagreements on how some things should > be done. There are genuine differences in functionality. > > We cannot expect and should not expect complete compatibility. If you > must have complete compatibility: use the same software (or maybe not > even then, considering how poor the forward compatibility of some > things has been..). > > What we can hope to do, and I think the best we can hope to do, is to > minimize the amount of gratuitous incompatibility and reduce the > amount of outright flawed constructions (so if there are choices which > must be made, they're at least choices among relatively good options). > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --047d7b3a8bcef60a9405110b31d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not convinced that wallet seed interoperability is= such a great thing. There is a wide variability in the quality and securit= y level of wallet implementations and platforms. Each new device and wallet= software a user types their seed into increases their attack surface and e= xposure to flaws. Their security level is reduced to the lowest common deno= minator. I see the need for a "fire exit", certainly, but we must= also remember that fire exits are potential entrances for intruders.

Aaron Voisine
co-founder and CEObreadwallet.com

On Wed, Mar 11, 2015 at 12:46 PM, Gregory Ma= xwell <gmaxwell@gmail.com> wrote:
On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe <ricardojdfilipe@gmail.com<= /a>> wrote:
> i guess you look at the glass half full :)
> even though what you say is true, we should aim for wallets not to
> require those instructions, by standardizing these things in BIPs.
> let's hope bitcoin doesn't fail in standards as our industries= have in
> the past...

There are genuine principled disagreements on how some things should=
be done. There are genuine differences in functionality.

We cannot expect and should not expect complete compatibility. If you
must have complete compatibility: use the same software (or maybe not
even then, considering how poor the forward compatibility of some
things has been..).

What we can hope to do, and I think the best we can hope to do, is to
minimize the amount of gratuitous incompatibility and reduce the
amount of outright flawed constructions (so if there are choices which
must be made, they're at least choices among relatively good options).<= br>

---------------------------------------------------------------------------= ---
Dive into the World of Parallel Programming The Go Parallel Website, sponso= red
by Intel and developed in partnership with Slashdot Media, is your hub for = all
things parallel software development, from weekly thought leadership blogs = to
news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--047d7b3a8bcef60a9405110b31d5--