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 ) id 1V1HMM-0005bi-BH for bitcoin-development@lists.sourceforge.net; Mon, 22 Jul 2013 14:45:10 +0000 X-ACL-Warn: Received: from vps7135.xlshosting.net ([178.18.90.41]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1V1HMH-0008Mq-J9 for bitcoin-development@lists.sourceforge.net; Mon, 22 Jul 2013 14:45:10 +0000 Received: by vps7135.xlshosting.net (Postfix, from userid 1000) id AA48033CE09; Mon, 22 Jul 2013 16:44:59 +0200 (CEST) Date: Mon, 22 Jul 2013 16:44:59 +0200 From: Pieter Wuille To: Bitcoin Dev Message-ID: <20130722144458.GA22993@vps7135.xlshosting.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: -0.2 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pieter.wuille[at]gmail.com) 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED -1.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing list X-Headers-End: 1V1HMH-0008Mq-J9 Subject: [Bitcoin-development] [RFC] Standard for private keys with birth timestamp 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: Mon, 22 Jul 2013 14:45:10 -0000 Hello, I should have brought up this suggestion before, as there seems to be relevant other work. I'd like to propose encoding keys data (whatever type) with a birth timestamp as: * @ The reason for not incorporating this inside the key serialization (for example BIP32), is because birth timestamps are more generally a property of an address, rather than the key it is derived from. For one, it is useful for non-extended standard serialized private keys, but for P2SH addresses, the "private key" is really the actual scriptPubKey, but birth data is equally useful for this. Reason for choosing the '@' character: it's not present in the base58, hex, or base64 encodings that are typically used for key/script data. One downside is that this means no checksum-protection for the timestamp, but the advantage is increased genericity. It's also longer than using a binary encoding, but this is an optional part anyway, and I think "human typing" is already fairly hard anyway. -- Pieter