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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VZmSk-0007Rn-H6 for bitcoin-development@lists.sourceforge.net; Fri, 25 Oct 2013 18:50:22 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of swipeclock.com designates 64.95.72.244 as permitted sender) client-ip=64.95.72.244; envelope-from=mcaldwell@swipeclock.com; helo=mxout.myoutlookonline.com; Received: from mxout.myoutlookonline.com ([64.95.72.244]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1VZmSj-0000D3-37 for bitcoin-development@lists.sourceforge.net; Fri, 25 Oct 2013 18:50:22 +0000 Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id CCFD88BE735 for ; Fri, 25 Oct 2013 14:50:15 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB023.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 01F328BE653 for ; Fri, 25 Oct 2013 14:50:15 -0400 (EDT) Received: from MAILR023.mail.lan ([10.110.18.122]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Fri, 25 Oct 2013 14:50:14 -0400 From: Mike Caldwell To: "bitcoin-development@lists.sourceforge.net" Date: Fri, 25 Oct 2013 14:50:10 -0400 Thread-Topic: BIP 38 Thread-Index: Ac7Rsu9HbXD/AZodT+GOXEAigqKqVg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B09A5DE3EF411243BB3328232CD25A5D998989775BMAILR023maill_" MIME-Version: 1.0 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [64.95.72.244 listed in list.dnswl.org] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1VZmSj-0000D3-37 Subject: [Bitcoin-development] BIP 38 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: Fri, 25 Oct 2013 18:50:22 -0000 --_000_B09A5DE3EF411243BB3328232CD25A5D998989775BMAILR023maill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey everyone, I have noticed that there was a recent change to BIP 0038 (Password-Protect= ed Private Key) on the Wiki, which is a proposal I wrote in late 2012. Gre= gory, it looks to me as though you have made this change, and I'm hoping fo= r your help here. The change suggests that the number was never assigned, = and that there has been no discussion regarding the proposal on this list. I had this number assigned by Amir Taaki in November of 2012, consistent wi= th what I understood the procedure to be at the time by reading BIP 0001 on= the Wiki. First off, I want to confirm that when I send to the list, that there isn't= a technical reason it's not getting to everybody. I believe I most recent= ly mentioned BIP 38 to this list on August 17, 2013. (EDIT: seems my prior = messages, including an earlier revision of this message, have not made it t= o the list) Secondly, in the case that it is deemed that this has never been properly s= ubmitted, discussed, or pushed forward, I'd like to propose that this happe= n, and request help with the formalities where I'm lacking. I believe BIP 38 is a valuable proposal that is seeing real-world use. BIP= 38 allows people to create private keys (including paper wallets) protecte= d by a password, and also allows one party to select the password for paper= wallets to be created by another party. Real-world use includes a working implementation at BitAddress.org, one at = Bit2Factor.org, implementation by Mycelium, and others. Also, others are i= nformally using it as a sort of abbreviated escrow scheme where a buyer and= seller agree on the buyer maintaining control over the release of funds. = In short, it would be terribly confusing to reassign the number BIP 38 afte= r already having had an established meaning for the better part of the year= , particularly on what appears to be procedural grounds. Mike --_000_B09A5DE3EF411243BB3328232CD25A5D998989775BMAILR023maill_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hey everyone,

 

= I have noticed that there was a recent change to BIP 0038 (Password-Protect= ed Private Key) on the Wiki, which is a proposal I wrote in late 2012. = ; Gregory, it looks to me as though you have made this change, and I’= m hoping for your help here.  The change suggests that the number was = never assigned, and that there has been no discussion regarding the proposa= l on this list.

 

I had this number assigned by Amir Taaki in November of 2= 012, consistent with what I understood the procedure to be at the time by r= eading BIP 0001 on the Wiki.

 =

First off, I want to confirm that when I sen= d to the list, that there isn’t a technical reason it’s not get= ting to everybody.  I believe I most recently mentioned BIP 38 to this= list on August 17, 2013. (EDIT: seems my prior messages, including an earl= ier revision of this message, have not made it to the list)

<= p class=3DMsoNormal> 

Secondly, in = the case that it is deemed that this has never been properly submitted, dis= cussed, or pushed forward, I’d like to propose that this happen, and = request help with the formalities where I’m lacking.

 

I believe BIP = 38 is a valuable proposal that is seeing real-world use.  BIP 38 allow= s people to create private keys (including paper wallets) protected by a pa= ssword, and also allows one party to select the password for paper wallets = to be created by another party.

&nb= sp;

Real-world use includes a working impleme= ntation at BitAddress.org, one at Bit2Factor.org, implementation by Myceliu= m, and others.  Also, others are informally using it as a sort of abbr= eviated escrow scheme where a buyer and seller agree on the buyer maintaini= ng control over the release of funds.  In short, it would be terribly = confusing to reassign the number BIP 38 after already having had an establi= shed meaning for the better part of the year, particularly on what appears = to be procedural grounds.

 

Mike

&n= bsp;

= --_000_B09A5DE3EF411243BB3328232CD25A5D998989775BMAILR023maill_--