diff options
author | Pieter Wuille <pieter.wuille@gmail.com> | 2013-10-26 23:30:37 +0200 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2013-10-26 21:30:43 +0000 |
commit | cae0c670677225f869f9252ff0610690b61d26b5 (patch) | |
tree | 53f89d4a2ec83d9ea72a86d3a649a2f0127cb256 | |
parent | e47d7a71f4c2f92ae1d3309ee0032c5282553abc (diff) | |
download | pi-bitcoindev-cae0c670677225f869f9252ff0610690b61d26b5.tar.gz pi-bitcoindev-cae0c670677225f869f9252ff0610690b61d26b5.zip |
Re: [Bitcoin-development] Proposal to replace BIP0039
-rw-r--r-- | 4b/bb97f688e66488b9b7eaa9b00bfb50e8cf74a3 | 161 |
1 files changed, 161 insertions, 0 deletions
diff --git a/4b/bb97f688e66488b9b7eaa9b00bfb50e8cf74a3 b/4b/bb97f688e66488b9b7eaa9b00bfb50e8cf74a3 new file mode 100644 index 000000000..902abca98 --- /dev/null +++ b/4b/bb97f688e66488b9b7eaa9b00bfb50e8cf74a3 @@ -0,0 +1,161 @@ +Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] + helo=mx.sourceforge.net) + by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <pieter.wuille@gmail.com>) id 1VaBRT-0004j2-QB + for bitcoin-development@lists.sourceforge.net; + Sat, 26 Oct 2013 21:30:43 +0000 +Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.223.174 as permitted sender) + client-ip=209.85.223.174; envelope-from=pieter.wuille@gmail.com; + helo=mail-ie0-f174.google.com; +Received: from mail-ie0-f174.google.com ([209.85.223.174]) + by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1VaBRS-0004jg-MZ + for bitcoin-development@lists.sourceforge.net; + Sat, 26 Oct 2013 21:30:43 +0000 +Received: by mail-ie0-f174.google.com with SMTP id qd12so8795201ieb.33 + for <bitcoin-development@lists.sourceforge.net>; + Sat, 26 Oct 2013 14:30:37 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.50.16.68 with SMTP id e4mr3501611igd.12.1382823037265; Sat, + 26 Oct 2013 14:30:37 -0700 (PDT) +Received: by 10.50.141.136 with HTTP; Sat, 26 Oct 2013 14:30:37 -0700 (PDT) +In-Reply-To: <CAJna-HgH1g8iiSvxXrJuga808SQJ6DKo4AYw4fxpwTRCsL+EyQ@mail.gmail.com> +References: <trinity-ba3941a0-f758-4372-b431-c64e9b44328a-1382635758149@3capp-gmx-bs09> + <CAJna-HjgpRhLdVGh+prx54VezHaH1vXGpPotW1Xkz2tiAiWrbg@mail.gmail.com> + <526BDEC2.2090709@gmx.de> + <CAJna-HgH1g8iiSvxXrJuga808SQJ6DKo4AYw4fxpwTRCsL+EyQ@mail.gmail.com> +Date: Sat, 26 Oct 2013 23:30:37 +0200 +Message-ID: <CAPg+sBiuLJJV3pB-EF3O9sgB_Z3tuLhEg9k=A9mcxJvgy3UQSw@mail.gmail.com> +From: Pieter Wuille <pieter.wuille@gmail.com> +To: slush <slush@centrum.cz> +Content-Type: text/plain; charset=ISO-8859-1 +X-Spam-Score: -1.6 (-) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. + See + http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block + for more information. [URIs: doubleclick.net] + -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 + (pieter.wuille[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 +X-Headers-End: 1VaBRS-0004jg-MZ +Cc: "bitcoin-development@lists.sourceforge.net" + <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Proposal to replace BIP0039 +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: Sat, 26 Oct 2013 21:30:44 -0000 + +Let's first try to agree on what we are solving. + +It seems that Thomas wants - in addition to the cryptographic data - +to encode the tree structure, or at least version information about +what features are used in it, inside the seed. + +I'm not sure whether we're ready to standardize on something like that +yet, not having established best practices regarding different wallet +structures. I do think we first need to see what possibilities and +developments are possible related to it. + +In addition, information about the wallet structure is strictly less +secret than the key data - it is even less confidential than address +book data, transaction annotations, labels and comments and +bookkeeping information. It could be backed up anywhere and everywhere +without any repercussions, as far as I can see. I understand that in +the case of Electrum, there is a strong reason to want this +encapsulated together with the seed, but it's not really a requirement +for most wallets. +(if really needed, any key derivation scheme that starts from random +strings can be augmented with metadata by enforcing property-bits on a +hash of the string (so not of the output), as this data doesn't need +protection from brute-forcing). + +Regarding other requirements, I wonder why we want the transformation +to be bidirectional? If it is just about generating master seeds, one +direction should be enough, and allows far nicer properties w.r.t. +security. If we do settle on a standard for 'brainwallets', I would +strongly prefer if it had at least some strengthening built-in, to +decrease the impact of worst-case situations. +If the reason is backward-compatibility, I think that any client that +supports seeds already can just keep supporting whatever they +supported before. Only if it matches both encoding schemes (as +mentioned before) there is a potential collision (and in that case, +the user could just be asked). + +-- +Pieter + + +On Sat, Oct 26, 2013 at 10:47 PM, slush <slush@centrum.cz> wrote: +> Hi Thomas, +> +> can you more elaborate on that "version" bits? What is exact meaning of it? +> I still think this is more an implementation problem. What stops Electrum to +> do the same algorithm for searching branches as it is now for used +> addresses? +> +> These "version bits" need to be covered by the specification as well, +> because if any client will use them differently (or won't use them at all), +> it will break cross-compatibility between clients, which was another goal of +> bip39. +> +> Marek +> +> +> +> +> On Sat, Oct 26, 2013 at 5:24 PM, Thomas Voegtlin <thomasv1@gmx.de> wrote: +>> +>> here is a simple implementation, with some ideas on how to format the +>> metadata: +>> https://en.bitcoin.it/wiki/Talk:BIP_0039 +>> +>> +>> +>> ------------------------------------------------------------------------------ +>> October Webinars: Code for Performance +>> Free Intel webinars can help you accelerate application performance. +>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most +>> from +>> the latest Intel processors and coprocessors. See abstracts and register > +>> +>> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk +>> _______________________________________________ +>> Bitcoin-development mailing list +>> Bitcoin-development@lists.sourceforge.net +>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development +> +> +> +> ------------------------------------------------------------------------------ +> October Webinars: Code for Performance +> Free Intel webinars can help you accelerate application performance. +> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most +> from +> the latest Intel processors and coprocessors. See abstracts and register > +> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk +> _______________________________________________ +> Bitcoin-development mailing list +> Bitcoin-development@lists.sourceforge.net +> https://lists.sourceforge.net/lists/listinfo/bitcoin-development +> + + |