Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2017-09-07 📝 Original message:On Thu, Sep 07, 2017 at ...
📅 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>;
📝 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>;