Date: Sun, 14 Mar 2021 15:13:32 +0000
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Robert Spigler <RobertSpigler@protonmail.ch>
From: SomberNight <somber.night@protonmail.com>
Reply-To: SomberNight <somber.night@protonmail.com>
Message-ID: <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

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 Det=
erministic Wallets.

> There are many issues with the current standards. As background, BIP 44/4=
9/84 specifies:
> `m / purpose' / coin_type' / account' / change / address_index`
> where the BIP43 `purpose'` path is separate for each script (P2PKH, P2WPK=
H-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 wallet sh=
ould create extended private/public keys independent of the script or signa=
ture type

You say that keys and scripts should not be mixed in the same layer, and im=
ply that this was solely done due to these standards predating output scrip=
t descriptors. Even if this was the case, it is not the only reason for doi=
ng 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 f=
airly certain BIP44 was designed with recovering from a BIP39 seed (and no =
additional information backed up) in mind. Note the "Account discovery" sec=
tion of BIP44.
(Electrum seeds go even further, as such seeds contain a version number tha=
t 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 purposes.
> For example, in multisignature wallets, before sending a new key record t=
o a coordinator, the wallet must increment the `account'` level.  Before cr=
eating 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, recovering mo=
st non-singlesig scripts from that is obviously infeasible. However, all si=
nglesig scripts at least can be discovered if the keys are using the sugges=
ted 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 prop=
osal, during recovery from seed the wallet would have to check all script t=
ypes for all account indices (which is only ever going to get more expensiv=
e as new script types come).
The workaround and I imagine your suggested solution is clearly to backup b=
oth seed words and output script descriptors; and to keep appending new out=
put script descriptors to existing backups when the account index is increm=
ented. While much less user-friendly than backing up just a seed, it is mor=
e generic and extendable.

My point is simply that your proposal is making a tradeoff here. The tradeo=
ff 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