From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 45F4EC0001 for ; Sun, 14 Mar 2021 20:46:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 1FC2583A7A for ; Sun, 14 Mar 2021 20:46:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-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=protonmail.ch 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 2cIrtaT5DXAr for ; Sun, 14 Mar 2021 20:46:22 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) by smtp1.osuosl.org (Postfix) with ESMTPS id 74E9083A79 for ; Sun, 14 Mar 2021 20:46:22 +0000 (UTC) Date: Sun, 14 Mar 2021 20:46:14 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.ch; s=protonmail; t=1615754779; bh=jiK4oKjOb1czOc0vaXBe9MehcgISI0qj2age8Uhw7sA=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=dCE6hQlJ4JL9t2WYd0fiYJHpHnHomyDwHtRnpHaCPN2Oa1DPHxde2uW7vS7Poyx1M lhbZDBQqE0BruQEdd5Vt2VH/qHhlcxbFrtxCb3f7zrBBjXi4YKiknCAPssZP7DsOfs gz323ysIoVyg6bKL0eM+5eez6B1Zz++NehK47gT8= To: SomberNight , "bitcoin-dev@lists.linuxfoundation.org" From: Robert Spigler Reply-To: Robert Spigler Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 16 Mar 2021 12:18:47 +0000 Subject: Re: [bitcoin-dev] Signature and Script Independent Hierarchy for Deterministic Wallets. 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: Sun, 14 Mar 2021 20:46:24 -0000 No, wallets don't and shouldn't have to check all script types on recovery.= Descriptor Wallets solve all of this. To back up a multisignature wallet, each cosigner stores their xprv (how yo= u do this; BIP39, WIF, etc, is out of scope). and the wallet descriptor. T= his is done, for example, in Yeti. To recover, simply combine `M` private k= eys, and check the script designated in 1 of the descriptor copies. For single signature wallets, it is the same, except only one signature is = needed. Store xprv and descriptor. It is not fair nor accurate to say that currently, in order to recover, wal= lets need "just the seed words". They also need all public keys, and deriv= ation paths. Descriptors (and this BIP), is a much cleaner way to handle wallet creation= and backup, by separating the two layers (keys and scripts) and getting ri= d of redundant information. Personal Fingerprint:=C2=A0 BF0D 3C08 A439 5AC6 11C1 5395 B70B 4A77 F850 54= 8F =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Sunday, March 14, 2021 11:13 AM, SomberNight wrote: > See some replies inline. (quoted text from BIP draft) > > > Date: Sun, 14 Mar 2021 01:51:15 +0000 > > From: Robert Spigler RobertSpigler@protonmail.ch > > Subject: [bitcoin-dev] Signature and Script Independent Hierarchy for D= eterministic Wallets. > > > There are many issues with the current standards. As background, BIP 44= /49/84 specifies: > > `m / purpose' / coin_type' / account' / change / address_index` > > where the BIP43 `purpose'` path is separate for each script (P2PKH, P2W= PKH-in-P2SH, and P2WPKH respectively). However, these per-script derivation= s are made redundant with descriptors > > > We should not be mixing keys and scripts in the same layer. The wallet = should create extended private/public keys independent of the script or sig= nature type > > You say that keys and scripts should not be mixed in the same layer, and = imply that this was solely done due to these standards predating output scr= ipt descriptors. Even if this was the case, it is not the only reason for d= oing it. BIP44/49/84 mixing scripts and keys in the same layer makes recove= ry from seed/mnemonic much easier. > Note the significant overlap between the authors of BIP39 and BIP44. I am= fairly certain BIP44 was designed with recovering from a BIP39 seed (and n= o additional information backed up) in mind. Note the "Account discovery" s= ection of BIP44. > (Electrum seeds go even further, as such seeds contain a version number t= hat encodes both the script type and the key derivation path to use.) > > > We define the following 5 levels in the BIP32 path: > > `m / purpose' / coin_type' / account' / change / address_index` > > > [Account] > > It is crucial that this level is increased for each new wallet joined o= r private/public keys created; for both privacy and cryptographic purposes. > > For example, in multisignature wallets, before sending a new key record= to a coordinator, the wallet must increment the `account'` level. Before c= reating it's own single signature wallet, the `account'` level must again b= e incremented. > > Imagine a user who has a BIP39 (or similar) seed. Even today, recovering = most non-singlesig scripts from that is obviously infeasible. However, all = singlesig scripts at least can be discovered if the keys are using the sugg= ested derivation paths. > By trying to create a standard that mixes discoverable and non-discoverab= le scripts in the same derivation scheme and incrementing a single index, y= ou are turning all scripts into being non-discoverable. > Note that even if a user only used singlesig scripts and followed this pr= oposal, during recovery from seed the wallet would have to check all script= types for all account indices (which is only ever going to get more expens= ive as new script types come). > The workaround and I imagine your suggested solution is clearly to backup= both seed words and output script descriptors; and to keep appending new o= utput script descriptors to existing backups when the account index is incr= emented. While much less user-friendly than backing up just a seed, it is m= ore generic and extendable. > > My point is simply that your proposal is making a tradeoff here. The trad= eoff itself seems easy to miss on first read of the text, so I just wanted = to explicitly point it out for the record. > > ghost43 / SomberNight