diff options
author | Natanael <natanael.l@gmail.com> | 2015-03-12 19:27:24 +0100 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-03-12 18:27:36 +0000 |
commit | 66df6199a1028718eecbf974c7399ddbdb95b8e4 (patch) | |
tree | 57ba9fe16f6b4c32c535ff9e4c63c17921fbdd51 | |
parent | d62245bc1f60e27d2fb44219915a74d490681e6d (diff) | |
download | pi-bitcoindev-66df6199a1028718eecbf974c7399ddbdb95b8e4.tar.gz pi-bitcoindev-66df6199a1028718eecbf974c7399ddbdb95b8e4.zip |
Re: [Bitcoin-development] Electrum 2.0 has been tagged
-rw-r--r-- | 2e/328f08021508dbe43f805d949886e9c10bc5a8 | 197 |
1 files changed, 197 insertions, 0 deletions
diff --git a/2e/328f08021508dbe43f805d949886e9c10bc5a8 b/2e/328f08021508dbe43f805d949886e9c10bc5a8 new file mode 100644 index 000000000..49cef4bbf --- /dev/null +++ b/2e/328f08021508dbe43f805d949886e9c10bc5a8 @@ -0,0 +1,197 @@ +Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] + helo=mx.sourceforge.net) + by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <natanael.l@gmail.com>) id 1YW7pY-0001oC-OV + for bitcoin-development@lists.sourceforge.net; + Thu, 12 Mar 2015 18:27:36 +0000 +Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com + designates 74.125.82.178 as permitted sender) + client-ip=74.125.82.178; envelope-from=natanael.l@gmail.com; + helo=mail-we0-f178.google.com; +Received: from mail-we0-f178.google.com ([74.125.82.178]) + by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1YW7pS-00050i-Kz + for bitcoin-development@lists.sourceforge.net; + Thu, 12 Mar 2015 18:27:36 +0000 +Received: by wesu56 with SMTP id u56so18245142wes.12 + for <bitcoin-development@lists.sourceforge.net>; + Thu, 12 Mar 2015 11:27:24 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.194.104.99 with SMTP id gd3mr86952065wjb.114.1426184844636; + Thu, 12 Mar 2015 11:27:24 -0700 (PDT) +Received: by 10.194.28.170 with HTTP; Thu, 12 Mar 2015 11:27:24 -0700 (PDT) +Received: by 10.194.28.170 with HTTP; Thu, 12 Mar 2015 11:27:24 -0700 (PDT) +In-Reply-To: <CANEZrP2AhCfks7Q+16PHGB0ZEeWwbdbbQM_xj3ebrkgDBgbosg@mail.gmail.com> +References: <54F32EED.6040103@electrum.org> + <CANEZrP23buJF0ENfrKGRuzpQ3Uod09s-kRcb3CBw1-OmUxEyZg@mail.gmail.com> + <550057FD.6030402@electrum.org> + <CANEZrP2UrRYG2wh3DHHj9B3Sp1X=n+gPCRcoj1Fouu4Lg157UA@mail.gmail.com> + <CAJna-HhHkmOTqNW2R6=Cih+tM_Eeu5o1LBxA4ZNzp-6vm1p6fg@mail.gmail.com> + <CANEZrP2AhCfks7Q+16PHGB0ZEeWwbdbbQM_xj3ebrkgDBgbosg@mail.gmail.com> +Date: Thu, 12 Mar 2015 19:27:24 +0100 +Message-ID: <CAAt2M1_zVXnp_EjtZHiP9wSq+cERgibZ_C992zZHtv+Lpmgsfw@mail.gmail.com> +From: Natanael <natanael.l@gmail.com> +To: Mike Hearn <mike@plan99.net> +Content-Type: multipart/alternative; boundary=089e010d879c0c7a8a05111b89aa +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 + (natanael.l[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: 1YW7pS-00050i-Kz +Cc: 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 18:27:36 -0000 + +--089e010d879c0c7a8a05111b89aa +Content-Type: text/plain; charset=UTF-8 + +Den 12 mar 2015 17:48 skrev "Mike Hearn" <mike@plan99.net>: +>> +>> b) "Creation date" is just a short-term hack. +> +> +> I agree, but we need things to be easy in the short term as well as the +long term :) +> +> The long term solution is clearly to have the 12 word seed be an +encryption key for a wallet backup with all associated metadata. We're +heading in that direction one step at a time. Unfortunately it will take +time for wallets to start working this way, and all the pieces to fall into +place. Restoring from the block chain will be a semi regular operation for +users until then. + +This have been mentioned a few times before, and what I think is necessary +is to create a common file format that can be interpreted by a library +which all wallets can use. I see it as similar as the work to create +libconsensus for parsing the blockchain. + +We need something extensible that can describe how to derive all addresses +used by the user. What HD branches to derive and how, with block numbers +(or bloom filters of block hashes or similar) to note where all previously +known transactions related to the wallet have occurred, and the last known +block (so only new blocks need to be scanned). + +A way to describe one HD tree as a multisignature wallet tied to a hardware +wallet if you have that (could include serial number or MAC of the device +for simple identification by the wallet client). A way to describe another +set of addresses as using a custom extension. A way to denote one private +key as being used for stealth addresses together with details for how to +identify the transactions (prefix, mailbox to look in, etc). Labels for +transactions. P2SH script templates so those addresses can be recovered. A +way to describe Copay style multisignature wallets and what server to use +for coordinating with the other coowners. A way to describe threshold +crypto group signature wallets and how to coordinate. Computer parsable +descriptions of HD branches as change addresses, as being used for +receiving payments in merchant payment systems, etc... Also, you should +really be talking to people like accountants and auditors to see what +features they'd like to see when it comes to things like how company +wallets could have rules defined for how to use the various HD branches. + +And so on... I think you get my point by now. + +The basic idea is that the wallet uses the library to parse the wallet file +and tells the user which sections it understands (can't expect all wallets +to handle custom extensions or stealth addresses, etc), then proceeds to +scan the blockchain for those addresses. Then the user also won't be +surprised that not all funds are found and won't think they're lost. + +I think it should be referred to as an import/export format, more than as a +backup format. + +You always want the most recent metadata the wallet of origin can provide +when importing, to reduce unnecessary extra work. You don't want really old +backup files. If people add new seeds and various new extensions that can't +be automatically recovered from old wallet backups, they need new backups. +You might as well use the wallet's own internal formats for backup, as the +wallet developer might better know how to optimize for the use cases he +have designed for. But at the same time we should ask wallet developers to +offer conversion tools to generate export format files from custom wallet +data files. + +--089e010d879c0c7a8a05111b89aa +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<p dir=3D"ltr"><br> +Den 12 mar 2015 17:48 skrev "Mike Hearn" <<a href=3D"mailto:mi= +ke@plan99.net">mike@plan99.net</a>>:<br> +>><br> +>> b) "Creation date" is just a short-term hack. <br> +><br> +><br> +> I agree, but we need things to be easy in the short term as well as th= +e long term :)=C2=A0<br> +><br> +> The long term solution is clearly to have the 12 word seed be an encry= +ption key for a wallet backup with all associated metadata. We're headi= +ng in that direction one step at a time. Unfortunately it will take time fo= +r wallets to start working this way, and all the pieces to fall into place.= + Restoring from the block chain will be a semi regular operation for users = +until then.</p> +<p dir=3D"ltr">This have been mentioned a few times before, and what I thin= +k is necessary is to create a common file format that can be interpreted by= + a library which all wallets can use. I see it as similar as the work to cr= +eate libconsensus for parsing the blockchain. </p> +<p dir=3D"ltr">We need something extensible that can describe how to derive= + all addresses used by the user. What HD branches to derive and how, with b= +lock numbers (or bloom filters of block hashes or similar) to note where al= +l previously known transactions related to the wallet have occurred, and th= +e last known block (so only new blocks need to be scanned).</p> +<p dir=3D"ltr">A way to describe one HD tree as a multisignature wallet tie= +d to a hardware wallet if you have that (could include serial number or MAC= + of the device for simple identification by the wallet client). A way to de= +scribe another set of addresses as using a custom extension. A way to denot= +e one private key as being used for stealth addresses together with details= + for how to identify the transactions (prefix, mailbox to look in, etc). La= +bels for transactions. P2SH script templates so those addresses can be reco= +vered. A way to describe Copay style multisignature wallets and what server= + to use for coordinating with the other coowners. A way to describe thresho= +ld crypto group signature wallets and how to coordinate. Computer parsable = +descriptions of HD branches as change addresses, as being used for receivin= +g payments in merchant payment systems, etc... Also, you should really be t= +alking to people like accountants and auditors to see what features they= +9;d like to see when it comes to things like how company wallets could have= + rules defined for how to use the various HD branches. </p> +<p dir=3D"ltr">And so on... I think you get my point by now. </p> +<p dir=3D"ltr">The basic idea is that the wallet uses the library to parse = +the wallet file and tells the user which sections it understands (can't= + expect all wallets to handle custom extensions or stealth addresses, etc),= + then proceeds to scan the blockchain for those addresses. Then the user al= +so won't be surprised that not all funds are found and won't think = +they're lost. </p> +<p dir=3D"ltr">I think it should be referred to as an import/export format,= + more than as a backup format.</p> +<p dir=3D"ltr">You always want the most recent metadata the wallet of origi= +n can provide when importing, to reduce unnecessary extra work. You don'= +;t want really old backup files. If people add new seeds and various new ex= +tensions that can't be automatically recovered from old wallet backups,= + they need new backups. You might as well use the wallet's own internal= + formats for backup, as the wallet developer might better know how to optim= +ize for the use cases he have designed for. But at the same time we should = +ask wallet developers to offer conversion tools to generate export format f= +iles from custom wallet data files.</p> + +--089e010d879c0c7a8a05111b89aa-- + + |