diff options
| author | William Yager <will.yager@gmail.com> | 2014-03-12 14:55:39 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-03-12 19:55:48 +0000 |
| commit | c104593ee5f8b594ab6395fca5ce85cc65568036 (patch) | |
| tree | b483ceb401a6ea24688e3383771ba4f58da53307 | |
| parent | 414b1602a729938287bc2e92d5ce1fcb62a7a698 (diff) | |
| download | pi-bitcoindev-c104593ee5f8b594ab6395fca5ce85cc65568036.tar.gz pi-bitcoindev-c104593ee5f8b594ab6395fca5ce85cc65568036.zip | |
Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption
| -rw-r--r-- | 7b/ca86b55c6a6ce0e16a554297cdc4091216b2a2 | 147 |
1 files changed, 147 insertions, 0 deletions
diff --git a/7b/ca86b55c6a6ce0e16a554297cdc4091216b2a2 b/7b/ca86b55c6a6ce0e16a554297cdc4091216b2a2 new file mode 100644 index 000000000..33c5fb382 --- /dev/null +++ b/7b/ca86b55c6a6ce0e16a554297cdc4091216b2a2 @@ -0,0 +1,147 @@ +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 <will.yager@gmail.com>) id 1WNpFk-0007RD-S0 + for bitcoin-development@lists.sourceforge.net; + Wed, 12 Mar 2014 19:55:48 +0000 +Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.216.173 as permitted sender) + client-ip=209.85.216.173; envelope-from=will.yager@gmail.com; + helo=mail-qc0-f173.google.com; +Received: from mail-qc0-f173.google.com ([209.85.216.173]) + by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1WNpFh-0000Jm-9a + for bitcoin-development@lists.sourceforge.net; + Wed, 12 Mar 2014 19:55:48 +0000 +Received: by mail-qc0-f173.google.com with SMTP id r5so12013246qcx.32 + for <bitcoin-development@lists.sourceforge.net>; + Wed, 12 Mar 2014 12:55:39 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.224.89.71 with SMTP id d7mr28618863qam.54.1394654139904; + Wed, 12 Mar 2014 12:55:39 -0700 (PDT) +Received: by 10.140.31.135 with HTTP; Wed, 12 Mar 2014 12:55:39 -0700 (PDT) +In-Reply-To: <5320B7F1.8060701@gk2.sk> +References: <44fcb02b-3784-45a6-816a-312c78d940cd@me.com> + <5320B7F1.8060701@gk2.sk> +Date: Wed, 12 Mar 2014 14:55:39 -0500 +Message-ID: <CAG8oi1M_jnn9vzHjN5h+0x-dYEKudgJ-DEqOKrdv-sCDaFV3NA@mail.gmail.com> +From: William Yager <will.yager@gmail.com> +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Content-Type: multipart/alternative; boundary=001a11c3e16697f87a04f46e3875 +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 + (will.yager[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 1.2 MISSING_HEADERS Missing To: header + 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: 1WNpFh-0000Jm-9a +Subject: Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet + root key with optional encryption +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, 12 Mar 2014 19:55:49 -0000 + +--001a11c3e16697f87a04f46e3875 +Content-Type: text/plain; charset=ISO-8859-1 + +On Wed, Mar 12, 2014 at 2:39 PM, Pavol Rusnak <stick@gk2.sk> wrote: + +> On 03/12/2014 08:26 PM, Jean-Paul Kogelman wrote: +> > So upon entering a password with a typo, the user will not be notified +> of an +> > error, but be presented with a wallet balance of 0, after the blockchain +> has +> > been scanned. I'm sorry, but that's not the kind of experience I would +> want to +> > present to my users. +> +> Sure, you can have either plausible deniability or typo checking, not +> both at the same time. +> +> +The proposed BIP uses a bloom filter, so it has both plausible deniability *and +*typo checking. The bloom filter is optimized for two elements and will +catch something like 99.9975% of typos, despite allowing two different +passwords. + +> Would you care to elaborate how optional outsourcing of the KDF breaks +> > compatibility? +> +> I'm afraid one would end up with code generated in one client that is +> unusable in a different client, because the client's developer thought +> that using fancier algorithm instead of the proposed ones was a good idea. +> +> +This is clearly in violation of the spec. You could argue this about +anything in Bitcoin. What if a developer decided to replace SHA256 with +SHA3 in their implementation of a Bitcoin client? Obviously this would +cause issues. + +Will + +--001a11c3e16697f87a04f46e3875 +Content-Type: text/html; charset=ISO-8859-1 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">On Wed, Mar 12, 2014 at 2:39 PM, Pavol Rusnak <span dir=3D= +"ltr"><<a href=3D"mailto:stick@gk2.sk" target=3D"_blank">stick@gk2.sk</a= +>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote= +"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:= +1px #ccc solid;padding-left:1ex"> +<div class=3D"">On 03/12/2014 08:26 PM, Jean-Paul Kogelman wrote:<br> +> So upon entering a password with a typo, the user will not be notified= + of an<br> +> error, but be presented with a wallet balance of 0, after the blockcha= +in has<br> +> been scanned. I'm sorry, but that's not the kind of experience= + I would want to<br> +> present to my users.<br> +<br> +</div>Sure, you can have either plausible deniability or typo checking, not= +<br> +both at the same time.<br> +<div class=3D""><br></div></blockquote><div><br></div><div>The proposed BIP= + uses a bloom filter, so it has both plausible deniability <i>and </i>typo = +checking. The bloom filter is optimized for two elements and will catch som= +ething like 99.9975% of typos, despite allowing two different passwords.</d= +iv> +<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= +;border-left:1px #ccc solid;padding-left:1ex"><div class=3D""> +> Would you care to elaborate how optional outsourcing of the KDF breaks= +<br> +> compatibility?<br> +<br> +</div>I'm afraid one would end up with code generated in one client tha= +t is<br> +unusable in a different client, because the client's developer thought<= +br> +that using fancier algorithm instead of the proposed ones was a good idea.<= +br> +<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div><= +br></div><div>This is clearly in violation of the spec. You could argue thi= +s about anything in Bitcoin. What if a developer decided to replace SHA256 = +with SHA3 in their implementation of a Bitcoin client? Obviously this would= + cause issues.=A0</div> +<div><br></div><div>Will</div></div></div></div> + +--001a11c3e16697f87a04f46e3875-- + + |