public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd•org>
To: Jonas Schnelli <dev@jonasschnelli•ch>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets
Date: Thu, 7 Sep 2017 14:09:02 -0400	[thread overview]
Message-ID: <20170907180902.GC13727@fedora-23-dvm> (raw)
In-Reply-To: <A806D2EB-744F-41A9-91C1-603F89E9005B@jonasschnelli.ch>

[-- Attachment #1: Type: text/plain, Size: 1428 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

  reply	other threads:[~2017-09-07 18:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-06 22:29 Pavol Rusnak
2017-09-07  3:52 ` Kabuto Samourai
2017-09-07 16:25   ` Pavol Rusnak
2017-09-07 16:30     ` Kabuto Samourai
2017-09-07 16:37       ` Pavol Rusnak
2017-09-07 18:02         ` Peter Todd
2017-09-07  4:29 ` Thomas Voegtlin
2017-09-07 16:23   ` Pavol Rusnak
2017-09-07 16:33     ` Kabuto Samourai
2017-09-07 19:35     ` Andreas Schildbach
2017-09-07 20:00       ` Pavol Rusnak
2017-09-07 20:39     ` Thomas Voegtlin
2017-09-07 16:47 ` Jonas Schnelli
2017-09-07 18:09   ` Peter Todd [this message]
2017-09-07 18:38   ` Pavol Rusnak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170907180902.GC13727@fedora-23-dvm \
    --to=pete@petertodd$(echo .)org \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=dev@jonasschnelli$(echo .)ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox