BIP-48 - define P2SH, P2TR derivation paths

[TheTrunk]

It would be useful to add P2SH script type derivation path to BIP-48 to further extend this standard.
Since BIP-48 can be expanded to altchains following SLIP-44 coin_type, this would be very helpful standard for blockchains that do not yet support Segwit or Bitcoin wallets that want to use more adopted standard of BIP-48 rather than older disappearing BIP-45 but want to also offer older P2SH address type.

[murchandamus]

Hi @Fonta1n3, could you take a look at this? At first glance, it seems to me that P2SH was covered in BIP-67, so I am not sure this addition makes sense.

[TheTrunk]

Hi,

• This addition is useful for multi signature wallets that support many types of multi signature addresses. Moreover for multi signature wallets that also support many different cryptocurrencies, not just Bitcoin.
• This way we know wallet is using BIP48 and the m/48 path for the whole implementation of multisigs and is not mixing multiple paths. As recovering paths with mixed derivation is more tricky, requires lots of documentation and is even more exhausting for multi assets multi sig wallets. This way only BIP48 + SLIP44 can be followed as a guideline for multi asset multi sig wallets.
• Similarly I would suggest the BIP48 to be extended for Taproot with 3' used for the script type
• The implementation is already in used by SSP Wallet - which is real user dual signature wallet for multiple assets. Fully open sourced wallet at https://github.com/RunOnFlux/ssp-wallet https://sspwallet.io/

[murchandamus]

On second glance, my prior comment about BIP-67 was incorrect, it seems that it covers a separate aspect of the multisig setup than I anticipated.

@TheTrunk: Thanks for elaborating your motivation for this PR. Given that this BIP moved to the Proposed status over three years ago, it might well be meanwhile implemented in a number of wallets, and adopting this proposed change may well lead to a situation in which "Support for BIP-48" could become ambiguous. Unless @Fonta1n3 responds in the affirmative soon, it may be more fruitful to propose a new BIP that describes the extensions to BIP-48 you champion. That way, it would be clear what "Support for BIP-48" or your respective "Support for BIP-?" would mean.

[Fonta1n3]

I haven't looked closely yet, will have a look and get back asap. Thanks for tagging me!

[Fonta1n3]

@TheTrunk why not just use bip45? The only reason bip48 exists is bc bip45 did not include segwit multisig.

EDIT: Adding the taproot type makes sense. Do you want to submit a PR that includes it?

[TheTrunk]

Hi @Fonta1n3

The BIP45 is pretty limiting and serves just specific purpose. Does not have an option for various networks and uses a bit obsolete cosigner index - bip48 replaces cosigner index and instead of indexing uses sorting of keys which is more convenient.

BIP48 can thus nicely brings everything together into one BIP making it organised, standardised for any multi signature needs while also making it usable even for multi asset multi signature wallets.

Yes taproot will be amazing extension. I will modify this PR with script type 3' to also include taproot.

EDIT: P2TR derivation path added

[Fonta1n3]

Just pinging @craigraw to see if he has any objections? We should probably tag other wallets that support bip48 before merging.

@TheTrunk on second thought I believe BIP86 already meets the requirements for taproot...

[murchandamus]

Just pinging @craigraw to see if he has any objections? We should probably tag other wallets that support bip48 before merging.

@TheTrunk on second thought I believe BIP86 already meets the requirements for taproot...

The recent comments here further reinforce my impression that it might be better to specify the new derivation paths in another BIP rather than amending the specification of BIP-48 this late in the process. I would propose that at least feedback is gathered from the mailing list about this change before we consider merging it.

[craigraw]

Wrt P2SH: Although it appears convenient to have it here, I don't support adding it to this BIP. P2SH is at this stage a legacy script type, and in general should be used to recover existing wallets, not create new ones (or at least, create new ones only with existing legacy software). Given this, adding a new derivation path would serve to introduce more variables into the recovery process. Like it or not, BIP45 (m/45') is the standard.

Wrt P2TR: Are we talking about script-based multisig, or more generally? We don't have any derivation path standards here I'm aware of, but I agree with @murchandamus that feedback be gathered from mailing list before proceeding.

[TheTrunk]

Although P2SH is legacy and shall be discouraged to use on Bitcoin, it still remains a valid address type and an important one especially for forks of Bitcoin.

This BIP48 is not only setting derivation and standards for Bitcoin but also for its forks and entire crypto ecosystem, ecosystem of multi signature, multi asset wallets.
Furthermore this BIP48 encourages such additions to expand on it.

Current state is read all the bips, research 10+ bips, integrate 5+ bips into your wallet. That is very difficult to follow and if you add the bip32 parameters its version bytes on top of that, it is uber difficult to get it right and have some proper standards. bip380 is a good step but different discussion..

I believe it is important to have one centralized place, derivation summarized just in one BIP, simple standard that can be followed.

[murchandamus]

Recapping this discussion so far:

• The Champion of BIP-48 has so far not endorsed this change
• BIP-48 is broadly implemented. Changing the specification in BIP-48 at this stage in the BIP process would ambiguate the meaning of existing implementation’s "BIP-48 support"
• This repository serves the Bitcoin community. Given the obsolescence of P2SH in Bitcoin, further standardization of P2SH does not seem to be of interest for the Bitcoin community at this time.

I would recommend pursuing one of the following two avenues:

• Discuss the idea of additional derivation paths on the Bitcoin developer mailing list; if this topic garners reasonable interest, either revisit this PR, or better, draft a new BIP that incorporates the specification of BIP-48 and extends it with your proposal. This proposal may be given a new name, allowing implementers to correspondingly signal support for BIP-48 or your new BIP.
• Alternatively, document your extended use of BIP-48 in the context of your implementation or another standards body.

I’m closing this PR now, but it can be reopened if the Champion requests it, or a discussion on the mailing list indicates broader interest in this amendment.