Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3D6FFC0001 for ; Sat, 20 Mar 2021 20:25:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 1FF43835D9 for ; Sat, 20 Mar 2021 20:25:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.603 X-Spam-Level: X-Spam-Status: No, score=0.603 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=gazeta.pl Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TzhGUp_4vb8 for ; Sat, 20 Mar 2021 20:25:45 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from smtpo70.poczta.onet.pl (smtpo70.poczta.onet.pl [141.105.16.20]) by smtp1.osuosl.org (Postfix) with ESMTPS id 04378835E0 for ; Sat, 20 Mar 2021 20:25:44 +0000 (UTC) Received: from pmq5v.m5r2.onet (pmq5v.m5r2.onet [10.174.35.25]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4F2shd0bGjzljDSg for ; Sat, 20 Mar 2021 21:25:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1616271937; bh=LbOHMO3K/cLk2OuKchK9NZrNQoZSv0c1jm04773Ro00=; h=From:To:Date:Subject:From; b=jfMaKXgQuXLxUc2r83hBGDHQdnhEHCiiUVIOQseIn/Gai7hgP6KJWjhf1Xy6HgLq4 NW3RsjZ+1rny86Bb20ogXJadgXoYlJzUHLXudSvgwEJ6dqTFYVyKT8K7kTpDRrpJU9 ZxgCgWO4vu4or0SBJoLwLcllvCncVVl725PyEPR4= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [5.173.253.132] by pmq5v.m5r2.onet via HTTP id 202103202124532751010001; Sat, 20 Mar 2021 21:25:37 +0100 From: vjudeu X-Priority: 3 To: "bitcoin-dev@lists.linuxfoundation.org" Date: Sat, 20 Mar 2021 21:25:36 +0100 Message-Id: <126113469-4f8fddbc2594365c5558c0e75fa55917@pmq5v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;5.173.253.132;PL;1 X-Mailman-Approved-At: Sat, 20 Mar 2021 21:00:48 +0000 Subject: Re: [bitcoin-dev] An alternative to BIP 32? X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2021 20:25:46 -0000 So, things have to be complicated to be secure? By definition, using some p= rivate key, calculating some public key from it and incrementing that key i= s secure (it is definitely no worse than address reuse). The only problem w= ith 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 t= he 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 t= his 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 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 = > > = > > = > =