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
Published at
2023-06-07 15:04:54Event JSON
{
"id": "6f7b0be8503cde11fb9e67c0fcc43723cab4dad29787cb88db9079da7e52376c",
"pubkey": "5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6",
"created_at": 1686150294,
"kind": 1,
"tags": [
[
"e",
"b27736b6b6a9e4a4f64e737bccac1ea1d52d8b9a0a4f8f0910e04fb5f30c97bc",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2013-07-22\n📝 Original message:Hello,\n\nI should have brought up this suggestion before, as there seems to be relevant other work.\n\nI'd like to propose encoding keys data (whatever type) with a birth timestamp as:\n * \u003cserialized key\u003e@\u003cunix timestamp in decimal\u003e\n\nThe reason for not incorporating this inside the key serialization (for example BIP32), is because\nbirth timestamps are more generally a property of an address, rather than the key it is derived from.\nFor one, it is useful for non-extended standard serialized private keys, but for P2SH addresses,\nthe \"private key\" is really the actual scriptPubKey, but birth data is equally useful for this.\n\nReason for choosing the '@' character: it's not present in the base58, hex, or base64 encodings that\nare typically used for key/script data.\n\nOne downside is that this means no checksum-protection for the timestamp, but the advantage is\nincreased genericity. It's also longer than using a binary encoding, but this is an optional\npart anyway, and I think \"human typing\" is already fairly hard anyway.\n\n-- \nPieter",
"sig": "6513d153f986e4239073a4903e9fc2d8cbf926ce6ad0f96ad13c5c4947ca9d96147a0c4a19c56ac4a6f293291204052cb34064c7cadc69717753d8a7ede37a64"
}