sparrow
sparrow copied to clipboard
Feature Request: prioritise displaying yPUB or zPUB over xPUB if available
Feature request:
Where available I believe it would be of greater benefit to users to prioritise displaying the zPUB
or yPUB
in the setting menu instead of the xPUB
. This would be applied to wallets with script type "Native Segwit" and "Nested Segwit" respectively. Wallets with script type "Legacy" or "Taproot" would be unaffected.
RE: Testnet. Same to be applied to prioritise displaying vPUB
or uPUB
instead of tPUB
for wallets with script type "Native Segwit" and "Nested Segwit" respectively.
Side note:
IMO it is not desirable to display (or give the option for a user to switch to) the xPUB
for wallets with script type "Native Segwit" or "Nested Segwit", and displaying an xPUB
for these script type wallets should be removed. I have observed lesser educated users to fall into issues when interacting with third-party services, copying over the xPUB
(instead of yPUB
or zPUB
), and Legacy addresses being derived by that third-party service. Users in this instance have believed their bitcoin has been lost, and require help to recover.
Agree 100%
I know some users having problems with xPUB
A software developer, I regard SLIP-0132 as a engineering misstep in combining key information with a wallet script type, which is/was a restrictive design choice. It certainly appears to be an evolutionary dead end, since we cannot tell from looking at an xpub whether it represents a legacy or a taproot singlesig wallet.
Even though I understand the reasons for asking for this change, it is really in the users best interests to be going backwards? Should we not rather be educating about output descriptors, which use xpubs exclusively, and can also represent multisig wallets and more? And should wallets who do rely on SLIP-0132 not check for existing funds across other script types when they are presented with an xpub?
We also believe zpub, ypubs and even xpubs are the wrong interchange format, and that bitcoin software should use descriptors instead, or at the very least the [mfp/derivation-path]xpub...
format.
@bro-rabbit , @4rkad I believe it would be helpful to list your use case for zpub/ypubs; in particular, what software are you using that insists on extended keys rather than descriptors or xpubs prefixed with the derivation path? We found an issue in bluewallet, but that should be fixed by now.