diff options
| author | Pieter Wuille <pieter.wuille@gmail.com> | 2013-07-22 16:44:59 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2013-07-22 14:45:10 +0000 |
| commit | a320b558922be1cf80362325061de6bd8c6e3ccd (patch) | |
| tree | e4fe685c1474e8efe35fdaca89dae41509292adc | |
| parent | f2d3b8753bd0153d6d777d205286fe481aa5c7be (diff) | |
| download | pi-bitcoindev-a320b558922be1cf80362325061de6bd8c6e3ccd.tar.gz pi-bitcoindev-a320b558922be1cf80362325061de6bd8c6e3ccd.zip | |
[Bitcoin-development] [RFC] Standard for private keys with birth timestamp
| -rw-r--r-- | c5/e858dd5d75937b978a99009aeacc4f367e407a | 72 |
1 files changed, 72 insertions, 0 deletions
diff --git a/c5/e858dd5d75937b978a99009aeacc4f367e407a b/c5/e858dd5d75937b978a99009aeacc4f367e407a new file mode 100644 index 000000000..2a1141757 --- /dev/null +++ b/c5/e858dd5d75937b978a99009aeacc4f367e407a @@ -0,0 +1,72 @@ +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 <pw@vps7135.xlshosting.net>) 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 <pieter.wuille@gmail.com> +To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +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: <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: 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: + * <serialized key>@<unix timestamp in decimal> + +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 + + + |