allow bip44 address option when creating wallet #294

New issue

Open

opened 2019-07-08 17:38:40 +02:00 by tzarebczan · 5 comments

tzarebczan commented

2019-07-08 17:38:40 +02:00

(Migrated from github.com)

Torba and lbrycrd use a different standard (bip44 vs bip32) so private keys do not produce the same set of addresses. I understand we don't want the bip44 method to be the default, but there should be an option to do so when creating a wallet.

BrannonKing commented

2019-07-10 17:47:49 +02:00

(Migrated from github.com)

This is potentially a relevant comment from Optech:

"Bitcoin Core #15427 extends the utxoupdatepsbt RPC with a descriptors parameter that takes an output script descriptor and uses it to update a BIP174 Partially-Signed Bitcoin Transaction (PSBT) with information about the scripts (addresses) involved in the transaction. This is in addition to the RPC’s previous behavior of adding information to the PSBT from the node’s mempool and UTXO set. This new feature is especially useful for hardware wallets and other paired wallets as it makes it possible to add HD key-path information to the PSBTs so that wallets asked to sign a PSBT can easily derive the keys needed for signing or verify that a change output does indeed pay back into the wallet."

This is potentially a relevant comment from Optech: "Bitcoin Core #15427 extends the utxoupdatepsbt RPC with a descriptors parameter that takes an output script descriptor and uses it to update a BIP174 Partially-Signed Bitcoin Transaction (PSBT) with information about the scripts (addresses) involved in the transaction. This is in addition to the RPC’s previous behavior of adding information to the PSBT from the node’s mempool and UTXO set. This new feature is especially useful for hardware wallets and other paired wallets as it makes it possible to add HD key-path information to the PSBTs so that wallets asked to sign a PSBT can easily derive the keys needed for signing or verify that a change output does indeed pay back into the wallet."

BrannonKing commented

2019-09-11 20:28:22 +02:00

(Migrated from github.com)

There are off-the-shelf wallets that support BIP44. Are any of those sufficient to cover this need? If not, is it because of a lack of LBRY support in a particular wallet? Would we do better making a certain 3rd-party wallet work with LBRY?

tzarebczan commented

2019-09-11 20:36:41 +02:00

(Migrated from github.com)

If we don't want to ever support the same keys on torba and lbrycrd, then we can just close this.

Maybe new torba wallets should use the format to match lbrycrd? Not sure if that makes things difficult to track with the two formats. @eukreign ?

If we don't want to ever support the same keys on torba and lbrycrd, then we can just close this. Maybe new torba wallets should use the format to match lbrycrd? Not sure if that makes things difficult to track with the two formats. @eukreign ?

BrannonKing commented

2019-09-11 20:36:42 +02:00

(Migrated from github.com)

Relevant:
https://github.com/bitcoin/bitcoin/pull/15414
https://github.com/bitcoin/bitcoin/pull/8723

Relevant: https://github.com/bitcoin/bitcoin/pull/15414 https://github.com/bitcoin/bitcoin/pull/8723

BrannonKing commented

2020-05-06 14:56:15 +02:00

(Migrated from github.com)

Pasting in from the Optech news letter:

Bitcoin Core #16528 allows the createwallet RPC to create a wallet that uses output script descriptors to derive just the particular scriptPubKeys that the wallet uses to receive payments. This is a major improvement over the way legacy wallets scan for payments by deriving every type of script handled by the wallet for each public key in the wallet—a technique that dates back to the original Bitcoin 0.1 release’s support for receiving to both P2PK and P2PKH scriptPubKeys. Descriptor wallets should be more efficient (because they don’t need to scan for unused script types), easier to upgrade to new types of script (e.g. for taproot), and easier to use with external tools (e.g. multisig wallets or HWI-compatible hardware wallets via partially-signed bitcoin transactions).

By default, descriptor wallets use the popular BIP32 HD wallet paths specified by BIPs 44, 49, and 84 rather than the non-standardized fully-hardened path used in legacy Bitcoin Core HD wallets. A number of wallet RPCs are unavailable with descriptor wallets, either because they don’t make sense with descriptors or because developers are still adapting them to new edge cases. The merge of this PR early in the 0.21 development cycle and the decision to make descriptor wallets a non-default option will give the new features six months to mature before their expected release.

Pasting in from the Optech news letter: > Bitcoin Core #16528 allows the createwallet RPC to create a wallet that uses output script descriptors to derive just the particular scriptPubKeys that the wallet uses to receive payments. This is a major improvement over the way legacy wallets scan for payments by deriving every type of script handled by the wallet for each public key in the wallet—a technique that dates back to the original Bitcoin 0.1 release’s support for receiving to both P2PK and P2PKH scriptPubKeys. Descriptor wallets should be more efficient (because they don’t need to scan for unused script types), easier to upgrade to new types of script (e.g. for taproot), and easier to use with external tools (e.g. multisig wallets or HWI-compatible hardware wallets via partially-signed bitcoin transactions). > > By default, descriptor wallets use the popular BIP32 HD wallet paths specified by BIPs 44, 49, and 84 rather than the non-standardized fully-hardened path used in legacy Bitcoin Core HD wallets. A number of wallet RPCs are unavailable with descriptor wallets, either because they don’t make sense with descriptors or because developers are still adapting them to new edge cases. The merge of this PR early in the 0.21 development cycle and the decision to make descriptor wallets a non-default option will give the new features six months to mature before their expected release.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: LBRYCommunity/lbrycrd#294

No description provided.