📅 Original date posted:2021-03-18
📝 Original message: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 at 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` private
> 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. 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
>
>
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Sunday, March 14, 2021 11:13 AM, SomberNight <
> somber.night at 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 at 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 wallet
> 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, and
> 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 (and
> 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 purposes.
> > > 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, 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
> 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 more
> 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 appending
> new output script descriptors to existing backups when the account index is
> incremented. While much less user-friendly than backing up just a seed, it
> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210318/78c59965/attachment.html>;
Jochen Hoenicke [ARCHIVE] /
npub1tu…dca6f
2023-06-07 18:30:45
in reply to nevent1q…wxq0
Author Public Key
npub1tue9u2scw5pe77vn4fz0464zz0387gm0zwy2zjhqg2yap36zhj2s4dca6fPublished at
2023-06-07 18:30:45Event JSON
{
"id": "693ba76f5c850d2c442dcbfbe7ee08e398b2a857ef36766001e61c5fdcd943f1",
"pubkey": "5f325e2a1875039f7993aa44faeaa213e27f236f1388a14ae04289d0c742bc95",
"created_at": 1686162645,
"kind": 1,
"tags": [
[
"e",
"913d86f3b70d7097b85745228f5bcf5ab314d109dd3d1e78a2db64c8151cf10d",
"",
"root"
],
[
"e",
"39648f99e051cbe377fd3f45a22ebe71e4eaec0331744fca5e03761d9a3205f5",
"",
"reply"
],
[
"p",
"03111b3dcac4508bd5dcda221b0b2b4e419292ae403c6a77a615481933a12b2d"
]
],
"content": "📅 Original date posted:2021-03-18\n📝 Original message:Hello Robert,\n\nyou wrote:\n\u003e It is not fair nor accurate to say that currently, in order to recover,\nwallets need \"just the seed words\". They also need all public keys, and\nderivation paths.\n\nNo a BIP39/BIP44 wallet can recover all BIP44 accounts using just the seed\nwords. Read the section account recovery closely to see how it's done. No\npublic keys or derivation paths needed, as the derivation path can just be\nenumerated and for single signature wallets you don't need external public\nkeys. Similarly a BIP39/BIP44/BIP49/BIP84 can recover all these accounts\nusing just the seed words and for example the Trezor Suite does this. Most\nhardware wallets currently rely on this feature, as they don't store any\nadditional information like output descriptors (which would be possible,\nbut would make regular backups necessary). Of course, autodiscover doesn't\nwork for multisig wallets, unless you would store some output descriptor in\nan OP_RETURN on the blockchain.\n\nIt's okay to make a new standard that requires regular backups, but you\nshould at least keep in mind that this complicates some use cases.\n\n Jochen\n\n\nOn Tue, 16 Mar 2021 at 13:19, Robert Spigler via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e No, wallets don't and shouldn't have to check all script types on\n\u003e recovery. Descriptor Wallets solve all of this.\n\u003e\n\u003e To back up a multisignature wallet, each cosigner stores their xprv (how\n\u003e you do this; BIP39, WIF, etc, is out of scope). and the wallet descriptor.\n\u003e This is done, for example, in Yeti. To recover, simply combine `M` private\n\u003e keys, and check the script designated in 1 of the descriptor copies.\n\u003e\n\u003e For single signature wallets, it is the same, except only one signature is\n\u003e needed. Store xprv and descriptor.\n\u003e\n\u003e It is not fair nor accurate to say that currently, in order to recover,\n\u003e wallets need \"just the seed words\". They also need all public keys, and\n\u003e derivation paths.\n\u003e\n\u003e Descriptors (and this BIP), is a much cleaner way to handle wallet\n\u003e creation and backup, by separating the two layers (keys and scripts) and\n\u003e getting rid of redundant information.\n\u003e\n\u003e\n\u003e Personal Fingerprint: BF0D 3C08 A439 5AC6 11C1 5395 B70B 4A77 F850 548F\n\u003e\n\u003e\n\u003e\n\u003e ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐\n\u003e On Sunday, March 14, 2021 11:13 AM, SomberNight \u003c\n\u003e somber.night at protonmail.com\u003e wrote:\n\u003e\n\u003e \u003e See some replies inline. (quoted text from BIP draft)\n\u003e \u003e\n\u003e \u003e \u003e Date: Sun, 14 Mar 2021 01:51:15 +0000\n\u003e \u003e \u003e From: Robert Spigler RobertSpigler at protonmail.ch\n\u003e \u003e \u003e Subject: [bitcoin-dev] Signature and Script Independent Hierarchy for\n\u003e Deterministic Wallets.\n\u003e \u003e\n\u003e \u003e \u003e There are many issues with the current standards. As background, BIP\n\u003e 44/49/84 specifies:\n\u003e \u003e \u003e `m / purpose' / coin_type' / account' / change / address_index`\n\u003e \u003e \u003e where the BIP43 `purpose'` path is separate for each script (P2PKH,\n\u003e P2WPKH-in-P2SH, and P2WPKH respectively). However, these per-script\n\u003e derivations are made redundant with descriptors\n\u003e \u003e\n\u003e \u003e \u003e We should not be mixing keys and scripts in the same layer. The wallet\n\u003e should create extended private/public keys independent of the script or\n\u003e signature type\n\u003e \u003e\n\u003e \u003e You say that keys and scripts should not be mixed in the same layer, and\n\u003e imply that this was solely done due to these standards predating output\n\u003e script descriptors. Even if this was the case, it is not the only reason\n\u003e for doing it. BIP44/49/84 mixing scripts and keys in the same layer makes\n\u003e recovery from seed/mnemonic much easier.\n\u003e \u003e Note the significant overlap between the authors of BIP39 and BIP44. I\n\u003e am fairly certain BIP44 was designed with recovering from a BIP39 seed (and\n\u003e no additional information backed up) in mind. Note the \"Account discovery\"\n\u003e section of BIP44.\n\u003e \u003e (Electrum seeds go even further, as such seeds contain a version number\n\u003e that encodes both the script type and the key derivation path to use.)\n\u003e \u003e\n\u003e \u003e \u003e We define the following 5 levels in the BIP32 path:\n\u003e \u003e \u003e `m / purpose' / coin_type' / account' / change / address_index`\n\u003e \u003e\n\u003e \u003e \u003e [Account]\n\u003e \u003e \u003e It is crucial that this level is increased for each new wallet joined\n\u003e or private/public keys created; for both privacy and cryptographic purposes.\n\u003e \u003e \u003e For example, in multisignature wallets, before sending a new key\n\u003e record to a coordinator, the wallet must increment the `account'` level.\n\u003e Before creating it's own single signature wallet, the `account'` level must\n\u003e again be incremented.\n\u003e \u003e\n\u003e \u003e Imagine a user who has a BIP39 (or similar) seed. Even today, recovering\n\u003e most non-singlesig scripts from that is obviously infeasible. However, all\n\u003e singlesig scripts at least can be discovered if the keys are using the\n\u003e suggested derivation paths.\n\u003e \u003e By trying to create a standard that mixes discoverable and\n\u003e non-discoverable scripts in the same derivation scheme and incrementing a\n\u003e single index, you are turning all scripts into being non-discoverable.\n\u003e \u003e Note that even if a user only used singlesig scripts and followed this\n\u003e proposal, during recovery from seed the wallet would have to check all\n\u003e script types for all account indices (which is only ever going to get more\n\u003e expensive as new script types come).\n\u003e \u003e The workaround and I imagine your suggested solution is clearly to\n\u003e backup both seed words and output script descriptors; and to keep appending\n\u003e new output script descriptors to existing backups when the account index is\n\u003e incremented. While much less user-friendly than backing up just a seed, it\n\u003e is more generic and extendable.\n\u003e \u003e\n\u003e \u003e My point is simply that your proposal is making a tradeoff here. The\n\u003e tradeoff itself seems easy to miss on first read of the text, so I just\n\u003e wanted to explicitly point it out for the record.\n\u003e \u003e\n\u003e \u003e ghost43 / SomberNight\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210318/78c59965/attachment.html\u003e",
"sig": "ea1072c71426d17bac1e80cf00723dc9bef123f08ea2b2dd8c522cfb0c5f0a3c32ef92d2b0863858a5cd3fa391899d36fee4bf6839f6d41a5f635ca90f180f16"
}