path: root/e3/de9fd79a8dbd405134ab644f4cdfe09407b718

Return-Path: <hoenicke@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 2239EC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Mar 2021 15:29:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 1009E83449
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Mar 2021 15:29:22 +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: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
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 nM72PUf7sa6C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Mar 2021 15:29:20 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com
 [IPv6:2607:f8b0:4864:20::102f])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 9F47D83408
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Mar 2021 15:29:20 +0000 (UTC)
Received: by mail-pj1-x102f.google.com with SMTP id s21so3118232pjq.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Mar 2021 08:29:20 -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=p/ssewgh/wiOU/lPnMDoZgi+UTUTMkWAaMUWebx9Drg=;
 b=V5CP+HA15McT7lFd+UdCqDWPPJZ2xf4shzm3OsCOSUukUZEKIrmguHyyktxuSdfWXb
 ge8VpEy8p+t7HT3Essoc2fsXWNrNoUB2SRRx1g8ByWbOvkeHxhygJnWowsBGXghKEmes
 AnnKsmv22FF+XcyEhG6LFoYx9QBtecw2AzV/wps/ibaZVRWxAJP76k7BUaYzuaTNe5Se
 PXwy6r9HJgDVhBOZMva+y2XFP2Q9BHfXeUTlh8JdswOAALnrb2PeflCpmoA/njufRL0N
 EceqNFqkk9lX+yoeAuW0MKTOQUmaJfjhh0vjB0W9ikyV1UkMnLYknWtltp9EckBCEYJR
 jmaA==
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=p/ssewgh/wiOU/lPnMDoZgi+UTUTMkWAaMUWebx9Drg=;
 b=FRMV3IA/cTxSvucpjVdxkLq0Gtfml2ZYohpmEcT2Ii7mhRJ93ajA0/Vtr9ymMKgxmt
 YbcaeBKEPLKYLF7fmpY3qugV+cOoqksQ5zdr0k4Q9ZY5okVur/XFS5bKZPbN+0OBAVNZ
 lg/vmP3ynY8cRYmh4xBcVk1AMEE/sxWp7KDKlQG4gfsK2qdv3qxtY8Jc4+uzvNTPxbPI
 w6nuTnOg5rCl55noPsD1DnCe8c0mGECZRnmgICwTOqj3SJnKsLnQKsjoK4G4ptr+iAND
 OHYMt+mi+tBgfZif+oGX6/BPicDgM/UeFjMSU66XKbB1tKtZQPcW49NwQjmgUe447Bg1
 vQrw==
X-Gm-Message-State: AOAM5300r53WD4sF9j6FuPqd6NN83D+SVOaexhQLXZYgcGHjunRgGPmq
 SekaOOS2gPPl8mzsX7Qo/+e1gBlAPMVTTht9cvE=
X-Google-Smtp-Source: ABdhPJzh8hV2cf+I8oA2to77j1irmwkKM7icoMU5HglkvewO5qz1VyqTJQ8ILX5bm4l83iS0cg8U1VP3Zy+rAq2uUF8=
X-Received: by 2002:a17:90a:ad87:: with SMTP id
 s7mr5147704pjq.20.1616081359847; 
 Thu, 18 Mar 2021 08:29:19 -0700 (PDT)
MIME-Version: 1.0
References: <z1Vokp3jct_xwR8wt3n6r8t24DqtMpnrogF22YFc0_V3riIMWEq3WBiOriJOm2kVrVgtsu5p7wDTMrN3dLdA8DilhITMXb4tHY6wCnk3y1g=@protonmail.com>
 <QZfbtDnhhbNNFo6859MyCotRPeN-sdotrP2qM-Uitq5DYATVzqIgIb_UEtXETGk941M3HWDzxCmO9j84wjzuKndHOo6kxg3A9qCd8WWlAOI=@protonmail.ch>
In-Reply-To: <QZfbtDnhhbNNFo6859MyCotRPeN-sdotrP2qM-Uitq5DYATVzqIgIb_UEtXETGk941M3HWDzxCmO9j84wjzuKndHOo6kxg3A9qCd8WWlAOI=@protonmail.ch>
From: Jochen Hoenicke <hoenicke@gmail.com>
Date: Thu, 18 Mar 2021 16:29:07 +0100
Message-ID: <CANYHNmJsiho0SxUUe7pmpQkkd-xAMnc2H8yHsGB_Urd9dw3usg@mail.gmail.com>
To: Robert Spigler <RobertSpigler@protonmail.ch>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000061c3eb05bdd143eb"
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Mar 2021 15:29:22 -0000

--00000000000061c3eb05bdd143eb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Robert,

you wrote:
> 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.

No a BIP39/BIP44 wallet can recover all BIP44 accounts using just the seed
words.  Read the section account recovery closely to see how it's done.  No
public keys or derivation paths needed, as the derivation path can just be
enumerated and for single signature wallets you don't need external public
keys. Similarly a BIP39/BIP44/BIP49/BIP84 can recover all these accounts
using just the seed words and for example the Trezor Suite does this.  Most
hardware wallets currently rely on this feature, as they don't store any
additional information like output descriptors (which would be possible,
but would make regular backups necessary).  Of course, autodiscover doesn't
work for multisig wallets, unless you would store some output descriptor in
an OP_RETURN on the blockchain.

It's okay to make a new standard that requires regular backups, but you
should at least keep in mind that this complicates some use cases.

  Jochen


On Tue, 16 Mar 2021 at 13:19, 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
>

--00000000000061c3eb05bdd143eb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div>Hello Robert,</div><div><br></div><d=
iv>you wrote:</div>&gt; It is not fair nor accurate to say that currently, =
in order to recover, wallets need &quot;just the seed words&quot;.=C2=A0 Th=
ey also need all public keys, and derivation paths.<br><div><br></div><div>=
No a BIP39/BIP44 wallet can recover all BIP44 accounts using just the seed =
words.=C2=A0 Read the section account recovery closely to see how it&#39;s =
done.=C2=A0 No public keys or derivation paths needed, as the derivation pa=
th can just be enumerated and for single signature wallets you don&#39;t ne=
ed external public keys. Similarly a BIP39/BIP44/BIP49/BIP84 can recover al=
l these accounts using just the seed words and for example the Trezor Suite=
 does this.=C2=A0 Most hardware wallets currently rely on this feature, as =
they don&#39;t store any additional information like output=C2=A0descriptor=
s (which would be possible, but would make regular backups necessary).=C2=
=A0 Of course, autodiscover doesn&#39;t work for multisig wallets,=C2=A0unl=
ess you would store some output descriptor in an OP_RETURN on the blockchai=
n.</div><div><br></div><div>It&#39;s okay to make a new standard that requi=
res regular backups, but you should at least keep in mind that this complic=
ates some use cases.</div><div><br></div><div>=C2=A0 Jochen</div><div><br><=
/div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_a=
ttr">On Tue, 16 Mar 2021 at 13:19, Robert Spigler via bitcoin-dev &lt;<a hr=
ef=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linux=
foundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">No, wallets don&#39;t and shouldn&#39;t have to check all scr=
ipt types on recovery.=C2=A0 Descriptor Wallets solve all of this.<br>
<br>
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.<br=
>
<br>
For single signature wallets, it is the same, except only one signature is =
needed.=C2=A0 Store xprv and descriptor.<br>
<br>
It is not fair nor accurate to say that currently, in order to recover, wal=
lets need &quot;just the seed words&quot;.=C2=A0 They also need all public =
keys, and derivation paths.<br>
<br>
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.<br>
<br>
<br>
Personal Fingerprint:=C2=A0 BF0D 3C08 A439 5AC6 11C1 5395 B70B 4A77 F850 54=
8F<br>
<br>
<br>
<br>
=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<br>
On Sunday, March 14, 2021 11:13 AM, SomberNight &lt;<a href=3D"mailto:sombe=
r.night@protonmail.com" target=3D"_blank">somber.night@protonmail.com</a>&g=
t; wrote:<br>
<br>
&gt; See some replies inline. (quoted text from BIP draft)<br>
&gt;<br>
&gt; &gt; Date: Sun, 14 Mar 2021 01:51:15 +0000<br>
&gt; &gt; From: Robert Spigler <a href=3D"mailto:RobertSpigler@protonmail.c=
h" target=3D"_blank">RobertSpigler@protonmail.ch</a><br>
&gt; &gt; Subject: [bitcoin-dev] Signature and Script Independent Hierarchy=
 for Deterministic Wallets.<br>
&gt;<br>
&gt; &gt; There are many issues with the current standards. As background, =
BIP 44/49/84 specifies:<br>
&gt; &gt; `m / purpose&#39; / coin_type&#39; / account&#39; / change / addr=
ess_index`<br>
&gt; &gt; where the BIP43 `purpose&#39;` path is separate for each script (=
P2PKH, P2WPKH-in-P2SH, and P2WPKH respectively). However, these per-script =
derivations are made redundant with descriptors<br>
&gt;<br>
&gt; &gt; 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<br>
&gt;<br>
&gt; 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.<br>
&gt; 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 &quot;Account disc=
overy&quot; section of BIP44.<br>
&gt; (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.)<br=
>
&gt;<br>
&gt; &gt; We define the following 5 levels in the BIP32 path:<br>
&gt; &gt; `m / purpose&#39; / coin_type&#39; / account&#39; / change / addr=
ess_index`<br>
&gt;<br>
&gt; &gt; [Account]<br>
&gt; &gt; 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.<br>
&gt; &gt; For example, in multisignature wallets, before sending a new key =
record to a coordinator, the wallet must increment the `account&#39;` level=
. Before creating it&#39;s own single signature wallet, the `account&#39;` =
level must again be incremented.<br>
&gt;<br>
&gt; 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.<br>
&gt; 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.<br>
&gt; 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).<br>
&gt; 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.<br>
&gt;<br>
&gt; 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.<br>
&gt;<br>
&gt; ghost43 / SomberNight<br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--00000000000061c3eb05bdd143eb--