Date: Sun, 14 Mar 2021 20:46:14 +0000
To: SomberNight <somber.night@protonmail.com>,
 "bitcoin-dev@lists.linuxfoundation.org"
 <bitcoin-dev@lists.linuxfoundation.org>
From: Robert Spigler <RobertSpigler@protonmail.ch>
Reply-To: Robert Spigler <RobertSpigler@protonmail.ch>
Message-ID: <QZfbtDnhhbNNFo6859MyCotRPeN-sdotrP2qM-Uitq5DYATVzqIgIb_UEtXETGk941M3HWDzxCmO9j84wjzuKndHOo6kxg3A9qCd8WWlAOI=@protonmail.ch>
In-Reply-To: <z1Vokp3jct_xwR8wt3n6r8t24DqtMpnrogF22YFc0_V3riIMWEq3WBiOriJOm2kVrVgtsu5p7wDTMrN3dLdA8DilhITMXb4tHY6wCnk3y1g=@protonmail.com>
References: <z1Vokp3jct_xwR8wt3n6r8t24DqtMpnrogF22YFc0_V3riIMWEq3WBiOriJOm2kVrVgtsu5p7wDTMrN3dLdA8DilhITMXb4tHY6wCnk3y1g=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Signature and Script Independent Hierarchy for
	Deterministic Wallets.
Precedence: list

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 <somber.night@protonmail.co=
m> 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