Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allow bip44 address option when creating wallet #294

Open
tzarebczan opened this issue Jul 8, 2019 · 5 comments
Open

allow bip44 address option when creating wallet #294

tzarebczan opened this issue Jul 8, 2019 · 5 comments
Labels
hacktoberfest Welcome to Hacktoberfest level: 3 Significant knowledge of the existing code is recommended type: new feature New functionality that does not exist yet

Comments

@tzarebczan
Copy link
Contributor

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.

@tzarebczan tzarebczan added the type: new feature New functionality that does not exist yet label Jul 8, 2019
@BrannonKing
Copy link
Member

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
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Member

@BrannonKing BrannonKing added hacktoberfest Welcome to Hacktoberfest level: 3 Significant knowledge of the existing code is recommended labels Sep 19, 2019
@BrannonKing
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hacktoberfest Welcome to Hacktoberfest level: 3 Significant knowledge of the existing code is recommended type: new feature New functionality that does not exist yet
Projects
None yet
Development

No branches or pull requests

2 participants