diff options
| author | Gregory Maxwell <gmaxwell@gmail.com> | 2015-03-12 00:11:24 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-03-12 00:11:37 +0000 |
| commit | 08abeeb44c3a864cf079b7a4a6a27d15ef4fd44c (patch) | |
| tree | 03be4ae1e905241c3630e6a151b8922402d285aa | |
| parent | 85be991066d8e37a28d1dc197ac3bb550bd634a9 (diff) | |
| download | pi-bitcoindev-08abeeb44c3a864cf079b7a4a6a27d15ef4fd44c.tar.gz pi-bitcoindev-08abeeb44c3a864cf079b7a4a6a27d15ef4fd44c.zip | |
Re: [Bitcoin-development] Electrum 2.0 has been tagged
| -rw-r--r-- | 2c/7c63469cfa985577f52160242648dd34527506 | 113 |
1 files changed, 113 insertions, 0 deletions
diff --git a/2c/7c63469cfa985577f52160242648dd34527506 b/2c/7c63469cfa985577f52160242648dd34527506 new file mode 100644 index 000000000..67b9c8db1 --- /dev/null +++ b/2c/7c63469cfa985577f52160242648dd34527506 @@ -0,0 +1,113 @@ +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 <gmaxwell@gmail.com>) id 1YVqiv-0004cB-OJ + for bitcoin-development@lists.sourceforge.net; + Thu, 12 Mar 2015 00:11:37 +0000 +Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.223.169 as permitted sender) + client-ip=209.85.223.169; envelope-from=gmaxwell@gmail.com; + helo=mail-ie0-f169.google.com; +Received: from mail-ie0-f169.google.com ([209.85.223.169]) + by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1YVqiu-0007W8-Tl + for bitcoin-development@lists.sourceforge.net; + Thu, 12 Mar 2015 00:11:37 +0000 +Received: by iegc3 with SMTP id c3so4363596ieg.3 + for <bitcoin-development@lists.sourceforge.net>; + Wed, 11 Mar 2015 17:11:31 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.43.70.10 with SMTP id ye10mr46162988icb.66.1426119084169; + Wed, 11 Mar 2015 17:11:24 -0700 (PDT) +Received: by 10.107.6.133 with HTTP; Wed, 11 Mar 2015 17:11:24 -0700 (PDT) +In-Reply-To: <5500D4C3.4090207@niftybox.net> +References: <54F32EED.6040103@electrum.org> + <CANEZrP23buJF0ENfrKGRuzpQ3Uod09s-kRcb3CBw1-OmUxEyZg@mail.gmail.com> + <550057FD.6030402@electrum.org> + <CANEZrP2UrRYG2wh3DHHj9B3Sp1X=n+gPCRcoj1Fouu4Lg157UA@mail.gmail.com> + <1426100677.1908596.239033309.7C4F8D47@webmail.messagingengine.com> + <CALC81CPonBX5pGucU9Pu7P7S042c+h8=vNvocX=7f9Yi_kqv5w@mail.gmail.com> + <CAAS2fgRuBwn6HXeZeth+x-R8DAdsVZmYy4nMA3kN+oJaURftgw@mail.gmail.com> + <CACq0ZD64rZAQs1mWQdwgx1WJq2btAVs3GbegPpkO-Wh49SoGeA@mail.gmail.com> + <CANEZrP3ri6QDqomWKMnLqj_ZJxVDOY4QRvWa=L4RzdKFzz+WsQ@mail.gmail.com> + <5500D4C3.4090207@niftybox.net> +Date: Thu, 12 Mar 2015 00:11:24 +0000 +Message-ID: <CAAS2fgRVNAPRO5F7yzAv8g-yehgEJ8VoFXapxWmHqnN9-wdq=A@mail.gmail.com> +From: Gregory Maxwell <gmaxwell@gmail.com> +To: devrandom <c1.sf-bitcoin@niftybox.net> +Content-Type: text/plain; charset=UTF-8 +X-Spam-Score: -1.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 + (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 AWL AWL: Adjusted score from AWL reputation of From: address +X-Headers-End: 1YVqiu-0007W8-Tl +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +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: <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: Thu, 12 Mar 2015 00:11:37 -0000 + +On Wed, Mar 11, 2015 at 11:50 PM, devrandom <c1.sf-bitcoin@niftybox.net> wrote: +> That said, I do agree that mnemonic phrases should be portable, and find +> it unfortunate that the ecosystem is failing to standardize on phrase +> handling. + +The fact remains that there are several apparently unresolvable +well-principled perspectives on this subject. + +(And I can speak to this personally: There are several BIPs in this +space that I'd rather not see in product with my name on it.) + +Unless two wallets have exactly the same feature set, cross importing +keys is going to confuse or break something. Even if you're trying to +be fairly generic the testing overhead for all possible strategies and +structures is large. Expecting compatibility here would be like +expecting two large commercial accounting packages to support the same +internal file formats. Compatibility is only straight forward when the +feature set is as limited as possible. + +The space for weird behavior to harm users is pretty large... e.g. you +could load a key into two wallets, such that one can see all the funds +by the other, but not vice versa and and up losing funds by +incorrectly assuming you had no coins; or inadvertently rip of your +business partners by accounting for things incorrectly. + +Even ignoring compatibility, most demanded use cases here are ones +that create concurrent read/write use of single wallet without some +coordinating service is inherently somewhat broken because you can +double spend yourself, and end up with stalled and stuck transactions +and causing people to think you tried ripping them off. + +I certainly recognize the desirable aspects of just being able to load +a common wallet, and that inexperienced users expect it to just work. +But I don't think that expectation is currently very realistic except +within limited domains. It may be more realistic in the future when +the role of wallets is better established. I don't see any _harm_ in +trying to standardize what can be, I just don't expect to see a lot of +success. + +Ultimately, the most fundamental compatibility is guaranteed: you can +always send your funds to another wallet. This always works and +guarantees that you are never locked in to a single wallet. It is well +tested and cannot drive any software in to weird or confused states. + + |