📅 Original date posted:2017-09-07
📝 Original message:On Thu, Sep 07, 2017 at 09:47:16AM -0700, Jonas Schnelli via bitcoin-dev wrote:
> Thanks for the proposal.
>
> Three points it could see as possible improvements:
>
> 1.
> From what I know, the exact birthday in seconds doesn’t matter that much therefore it may be possible to just use 13 or 16bits to create a representation in week from 2009-01-09 00:00 UTC. 13bits would give you 157 years.
> Always round down to the beginning of the week when the key was created.
> But not sure if it’s worth to save ~two bytes for that.
> Also not sure if the key-birthday in seconds could have a security or privacy implication (week maybe better).
Note how private key birthday is a potential privacy issue in certain cases.
Rare of course, because usually you don't release your private keys! But users
will on occasion have those keys be compromised.
Personally, I'd advocate rounding down to month-level resolution, as that
should be both enough to handle any likely reorg scenario, and it's still a
precision that won't add much extra scanning ot any reasonably old (~1yr)
wallet.
Note also how if transactions created with private keys in a seed use
nLockTime, you can ensure coins won't exist in a block older than the seed
birthday by simply ensuring that nLockTime is set to a more recent date then
that birthday under all circumstances.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170907/08ad4b1a/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2…a2np2
2023-06-07 18:05:33
in reply to nevent1q…mlh2
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 18:05:33Event JSON
{
"id": "c58b68bc530aea9612cc203531a26776a9e6788241f4442ad1d2ae704f491202",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686161133,
"kind": 1,
"tags": [
[
"e",
"8b6c82e376bdda93cb2f70dd4782d9cc9d7453907841b893f7135515b4f67b4c",
"",
"root"
],
[
"e",
"cbff85680ac742fcdd6f25d9e506f236e332a3f242fc2c3c0e895b9b25b70cc3",
"",
"reply"
],
[
"p",
"9a463e0fab8963b013698c15a0f2449d19c97f3b88458e5874095b5006df9a0c"
]
],
"content": "📅 Original date posted:2017-09-07\n📝 Original message:On Thu, Sep 07, 2017 at 09:47:16AM -0700, Jonas Schnelli via bitcoin-dev wrote:\n\u003e Thanks for the proposal.\n\u003e \n\u003e Three points it could see as possible improvements:\n\u003e \n\u003e 1.\n\u003e From what I know, the exact birthday in seconds doesn’t matter that much therefore it may be possible to just use 13 or 16bits to create a representation in week from 2009-01-09 00:00 UTC. 13bits would give you 157 years.\n\u003e Always round down to the beginning of the week when the key was created.\n\u003e But not sure if it’s worth to save ~two bytes for that.\n\u003e Also not sure if the key-birthday in seconds could have a security or privacy implication (week maybe better).\n\nNote how private key birthday is a potential privacy issue in certain cases.\nRare of course, because usually you don't release your private keys! But users\nwill on occasion have those keys be compromised.\n\nPersonally, I'd advocate rounding down to month-level resolution, as that\nshould be both enough to handle any likely reorg scenario, and it's still a\nprecision that won't add much extra scanning ot any reasonably old (~1yr)\nwallet.\n\nNote also how if transactions created with private keys in a seed use\nnLockTime, you can ensure coins won't exist in a block older than the seed\nbirthday by simply ensuring that nLockTime is set to a more recent date then\nthat birthday under all circumstances.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 455 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170907/08ad4b1a/attachment.sig\u003e",
"sig": "f82639eb92ddf42715df29a138159e01c8b8b9e4e55bc2a70b385ab3adb762e6dcc5531539008701a3a32e9791bddad73da7fc6b321c3176a5c27e186d1200fa"
}