From: vjudeu <vjudeu@gazeta•pl>
To: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] An alternative to BIP 32?
Date: Sat, 20 Mar 2021 21:25:36 +0100 [thread overview]
Message-ID: <126113469-4f8fddbc2594365c5558c0e75fa55917@pmq5v.m5r2.onet> (raw)
So, things have to be complicated to be secure? By definition, using some private key, calculating some public key from it and incrementing that key is secure (it is definitely no worse than address reuse). The only problem with using "privKey", "(privKey+1) mod n", "(privKey+2) mod n" and so on is that all of those public keys could be easily linked together. If that is the only problem, then by making offset deterministic but less predictable, it should be secure enough, right? So, instead of simple incrementation, we would have "privKey" (parent), "(privKey+firstOffset) mod n" (first child), "(privKey+secondOffset) mod n" (second child) and so on. And as long as this offset is not guessed by the attacker, it is impossible to link all of those keys together, right?
> On 2021-03-20 11:08:30 user Tim Ruffing <crypto@timruffing•de> wrote:
> > On Fri, 2021-03-19 at 20:46 +0100, vjudeu via bitcoin-dev wrote:
> > > is it safe enough to implement it and use in practice?
> >
> > This may be harsh but I can assure you that a HD wallet scheme that can
> > be specified in 3 lines (without even specifying what the security
> > goals are) should not be assumed safe to implement.
> >
> > Tim
> >
> >
>
next reply other threads:[~2021-03-20 20:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-20 20:25 vjudeu [this message]
2021-03-21 21:45 ` Tim Ruffing
-- strict thread matches above, loose matches on Subject: below --
2021-03-22 7:51 vjudeu
2021-03-20 20:25 vjudeu
2021-03-19 19:46 vjudeu
2021-03-20 1:32 ` Erik Aronesty
2021-03-20 2:08 ` Arik Sosman
2021-03-22 12:05 ` Erik Aronesty
2021-03-20 10:08 ` Tim Ruffing
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=126113469-4f8fddbc2594365c5558c0e75fa55917@pmq5v.m5r2.onet \
--to=vjudeu@gazeta$(echo .)pl \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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