Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1F506C000A for ; Wed, 17 Mar 2021 07:27:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 1A3C56F69D for ; Wed, 17 Mar 2021 07:27:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 1.602 X-Spam-Level: * X-Spam-Status: No, score=1.602 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uE9l0Dfg2XnZ for ; Wed, 17 Mar 2021 07:27:02 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) by smtp3.osuosl.org (Postfix) with ESMTPS id 9B2E760592 for ; Wed, 17 Mar 2021 07:27:02 +0000 (UTC) Received: by mail-io1-xd2b.google.com with SMTP id f20so39898307ioo.10 for ; Wed, 17 Mar 2021 00:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=VGyRl4MLlqiEuEMfNqtgoJp3E6saiy1t+8ID2rQWJAM=; b=gP3jNRc9g5H3+AGgSC/WMwM6/uAKlXlPnid1MIL1wZThFWfQgh3j1O+x1Diu7AplgI WznQcK2MknutBpqNpzhQMpuBRWCf/SaO2myvb92qo04Faey0PwOB2tq4tDXytN6kqq03 gFdepxNwagLBYCE8tXc8PpkmXWWIMWJU17gmYQDi6AcgJfkjS3ry174nDHKAKKnLNs+m gHqeIFIB/4fhc9DvCSOaepvFc9bk0UuFTT0vpUx+/l8/QX19zESaIFDlNXp0hrhr8UUT xx+JhadiE/M2RjsFrxkQnaOiok/l+TuBBuhNF/w7hkG13ij+jvA49qROvmjbmPLR9Ah8 ZYSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=VGyRl4MLlqiEuEMfNqtgoJp3E6saiy1t+8ID2rQWJAM=; b=mAPS9Uu8t8F2dqh7AqqYKbZqnEweKy16K/bFZG5hJuD6V65u79awgP6YEWguKyP2Sl nqXKEbS+8ynVBfZrGcKOEIJUwtzTCxzqhpy3gDw2MR3+G9uHpV82MkuTKtJLJc0hJz5R 8WxuEWgXQJsBWRdy1b2WoOnhzmxabYq7kfsdSbQ42CuAtwYwYRMrG6scPFoRZ5rMOxEh 0K8rlceiySWFkqnyY7ApXylQy67pvWD7M1KWZN5EoWvW1P1OE9BRQ4MxEDuSVPcsQs+Q BuHZWlp6j4t3y65bolTXfwDkVPi9dEyKvPFIfXz/afM42XjbC9R5As28fTlVtV4BdhBg 9eeg== X-Gm-Message-State: AOAM531EV3aSnC/I8ri3RblPkuOVP/w6kWsIC90tSBcn3VqnFL0DcyLw eg69KcgsLEee0JxUCWmnVvR1IVW0uAtEFPnLIKsIU2sE4uo= X-Google-Smtp-Source: ABdhPJyt/cYs3wOskgDpuyS9V0+z9tRKtKhTTTD3bmk4wdvOSgqS9cycvHOL6uBdltif9tKPcGR50OByfsJ74tR6haE= X-Received: by 2002:a5d:9d13:: with SMTP id j19mr6023328ioj.110.1615966021330; Wed, 17 Mar 2021 00:27:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Craig Raw Date: Wed, 17 Mar 2021 09:26:50 +0200 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000aba9c605bdb668c5" X-Mailman-Approved-At: Wed, 17 Mar 2021 19:03:56 +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: Wed, 17 Mar 2021 07:27:04 -0000 --000000000000aba9c605bdb668c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The motivation for this BIP proposal states that encoding the script type in the derivation is redundant because output descriptors are becoming commonplace. However, I think it's important to note that this shifts more burden of wallet backup onto the user, who now has an additional item (the output descriptor) to backup correctly. This is particularly important when we consider that performing this backup is often laborious, including stamping onto metal etc. There are two ways to go here: 1. Use derivation paths that do not encode the script type, and conduct a global education effort to encourage users to backup output descriptors in addition to their seed words, without which their funds may be lost. 2. Use a standard set of derivation paths that encode the script type, ensuring that even if users do not back this up, they can check against a handful of common derivations and recover the funds. Option 1 is obviously cleaner and more precise from a technical POV, but I feel it is less practical. The approach of using common words to encode the seed was chosen because these words are short and familiar - an output descriptor on the other hand is technical and longer form, and thus more difficult to record correctly, particularly on damage-resistant media. Craig On Tue, Mar 16, 2021 at 2:19 PM Robert Spigler via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 > you do this; BIP39, WIF, etc, is out of scope). and the wallet descriptor= . > This is done, for example, in Yeti. To recover, simply combine `M` privat= e > keys, and check the script designated in 1 of the descriptor copies. > > For single signature wallets, it is the same, except only one signature i= s > needed. Store xprv and descriptor. > > It is not fair nor accurate to say that currently, in order to recover, > wallets need "just the seed words". They also need all public keys, and > derivation 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 rid of redundant information. > > > Personal Fingerprint: BF0D 3C08 A439 5AC6 11C1 5395 B70B 4A77 F850 548F > > > > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original = Message =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 < > somber.night@protonmail.com> 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 > Deterministic 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, > P2WPKH-in-P2SH, and P2WPKH respectively). However, these per-script > derivations are made redundant with descriptors > > > > > We should not be mixing keys and scripts in the same layer. The walle= t > should create extended private/public keys independent of the script or > signature type > > > > You say that keys and scripts should not be mixed in the same layer, an= d > imply that this was solely done due to these standards predating output > script descriptors. Even if this was the case, it is not the only reason > for doing it. BIP44/49/84 mixing scripts and keys in the same layer makes > recovery 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 (a= nd > no additional information backed up) in mind. Note the "Account discovery= " > section of BIP44. > > (Electrum seeds go even further, as such seeds contain a version number > that 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 > or private/public keys created; for both privacy and cryptographic purpos= es. > > > For example, in multisignature wallets, before sending a new key > record to a coordinator, the wallet must increment the `account'` level. > Before creating it's own single signature wallet, the `account'` level mu= st > again be incremented. > > > > Imagine a user who has a BIP39 (or similar) seed. Even today, recoverin= g > most non-singlesig scripts from that is obviously infeasible. However, al= l > singlesig scripts at least can be discovered if the keys are using the > suggested derivation paths. > > By trying to create a standard that mixes discoverable and > non-discoverable scripts in the same derivation scheme and incrementing a > single index, you are turning all scripts into being non-discoverable. > > Note that even if a user only used singlesig scripts and followed this > proposal, during recovery from seed the wallet would have to check all > script types for all account indices (which is only ever going to get mor= e > expensive 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 appendi= ng > new output script descriptors to existing backups when the account index = is > incremented. While much less user-friendly than backing up just a seed, i= t > is more generic and extendable. > > > > My point is simply that your proposal is making a tradeoff here. The > tradeoff 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 > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000aba9c605bdb668c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The motivation for this BIP proposal states that encoding = the script type in the derivation is redundant because=C2=A0output descript= ors are becoming commonplace. However, I think it's important to note t= hat this shifts more burden of wallet backup onto the user, who now has an = additional item (the output descriptor) to backup correctly. This is partic= ularly important when we consider that performing this backup is often labo= rious, including stamping onto metal etc.

There are = two ways to go here:
1. Use derivation paths that do not encode t= he script type, and conduct a global education effort to encourage users to= backup output descriptors in addition to their seed words, without which t= heir funds may be lost.
2. Use a standard set of derivation paths= that encode the script type, ensuring that even if users do not back this = up, they can check against a handful of common derivations and recover the = funds.

Option 1 is obviously cleaner and more prec= ise from a technical POV, but I feel it is less practical. The approach of = using common words to encode the seed was chosen because these words are sh= ort and familiar - an output descriptor on the other hand is technical and = longer form, and thus more difficult to record correctly, particularly on d= amage-resistant media.=C2=A0

Craig

=
On Tue, Ma= r 16, 2021 at 2:19 PM Robert Spigler via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.or= g> wrote:
No, wallets don't and shouldn't have to check all script types on = recovery.=C2=A0 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.=C2= =A0 This is done, for example, in Yeti. To recover, simply combine `M` priv= ate keys, 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.=C2=A0 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".=C2=A0 They also need all public = keys, and derivation 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 <somber.night@protonmail.com&g= t; 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 Deterministic Wallets.
>
> > There are many issues with the current standards. As background, = BIP 44/49/84 specifies:
> > `m / purpose' / coin_type' / account' / change / addr= ess_index`
> > where the BIP43 `purpose'` path is separate for each script (= P2PKH, P2WPKH-in-P2SH, and P2WPKH respectively). However, these per-script = derivations are made redundant with descriptors
>
> > We should not be mixing keys and scripts in the same layer. The w= allet should create extended private/public keys independent of the script = or signature type
>
> You say that keys and scripts should not be mixed in the same layer, a= nd imply that this was solely done due to these standards predating output = script descriptors. Even if this was the case, it is not the only reason fo= r doing it. BIP44/49/84 mixing scripts and keys in the same layer makes rec= overy 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 (an= d no additional information backed up) in mind. Note the "Account disc= overy" section of BIP44.
> (Electrum seeds go even further, as such seeds contain a version numbe= r that 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 / addr= ess_index`
>
> > [Account]
> > It is crucial that this level is increased for each new wallet jo= ined or private/public keys created; for both privacy and cryptographic pur= poses.
> > For example, in multisignature wallets, before sending a new key = record to a coordinator, the wallet must increment the `account'` level= . Before creating it's own single signature wallet, the `account'` = level must again be incremented.
>
> Imagine a user who has a BIP39 (or similar) seed. Even today, recoveri= ng most non-singlesig scripts from that is obviously infeasible. However, a= ll singlesig scripts at least can be discovered if the keys are using the s= uggested derivation paths.
> By trying to create a standard that mixes discoverable and non-discove= rable scripts in the same derivation scheme and incrementing a single index= , you are turning all scripts into being non-discoverable.
> Note that even if a user only used singlesig scripts and followed this= proposal, during recovery from seed the wallet would have to check all scr= ipt types for all account indices (which is only ever going to get more exp= ensive as new script types come).
> The workaround and I imagine your suggested solution is clearly to bac= kup both seed words and output script descriptors; and to keep appending ne= w output script descriptors to existing backups when the account index is i= ncremented. While much less user-friendly than backing up just a seed, it i= s more generic and extendable.
>
> My point is simply that your proposal is making a tradeoff here. The t= radeoff itself seems easy to miss on first read of the text, so I just want= ed to explicitly point it out for the record.
>
> ghost43 / SomberNight


_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000aba9c605bdb668c5--