Pieter Wuille [ARCHIVE] on Nostr: 📅 Original date posted:2013-07-22 📝 Original message:Hello, I should have ...
📅 Original date posted:2013-07-22
📝 Original message: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
📝 Original message: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