Allow use external public keys in walletPolicy

[generalAO]

Hi, i want to register a wallet polixy with 2 xpub keys (from Ledgers) and 1 external public key (i can't get an extended public key for third key). From docs i understand that ability is not implemented yet. When this will be implemented or maybe there is another way to use such signing strategy with Ledger?

[bigspider]

Hi @generalAO, as for issue #153, I think the answer might not be in extending wallet policies, but rather allowing certain signing behaviors outside of wallet policies.

Wallet policies represents series of addresses that logically represent an account as commonly used in software wallets today (generally, a series of receiving addresses, and a series of change addresses).

I'm interested in finding ways of generalizing the signing behavior to cover (families of) UTXOs that don't fit in the wallet policies model. Can you describe your use case in more detail? For example:

• Are you trying to sign for one specific UTXO, or potentially a family of them that are logically part of the same account? - Is there a change address that the device should identify (and therefore hide in the UX), or are are all the inputs spent entirely?
• If spending multiple inputs: do they all have the same "template" in some sense? What does the descriptor (and the key paths) look like?

[generalAO]

@bigspider let's imagine the case when i use signing strategy 3 of 3. And i have 2 ledgers and third key pair will be external - i mean i will have only private key and public key. Third sign will be done with some software. I want to generate a multisig adress (p2wsh+p2ms) with these keys, receive funds to it and then spend funds partially. Descriptor for example will be like wsh(multi(2,@0/,@1/,@2/**)) Paths for ledgers will be like [{ledgerFingerprint}/49'/1'/0']${LedgerXPubkey}, but lets say third key will be constant pubkey.

[bigspider]

Having some keys with a /* and some other with a raw pubkey means that all the addresses can be trivially linked together when they are spent for an external observer (as all their scripts contains the same pubkey); that's an antipattern that wallet policies want to explicitly prevent, and wallet developers in general should avoid. That's almost as bad as re-using a single address every time in terms of privacy.

[generalAO]

I see, i can get a new raw pubkey for every incoming transaction. But i can't get an xpub. This is a restriction.

[pcfun19]

I am developing for blockchain that produces public keys. They can sign transactions for those keys. However they don't give an xpub. Also sharing xpubs is dangerous. As a consequence I build script wallets using the key produced by the blockchain. The raw public key is part of the P2WSH wallet and ledger needs to recreate it. But without the xpub I can't do it under current Ledger restrictions that requires xpubs.

I understand allowing /* and raw keys referenced could lead to programmers misusing and could be an antipattern or create reuse of addresses but i don't see risks involved in terms of spending, it will be in their abilities to derive keys properly if they have xpubs and check before they submit anything to the device for signing.

I would say it would do more good than bad to allow raw keys in the miniscript for third party keys. Also avoiding all risks involved with sharing with anyone at all any xpub key of yours.

I am voting up this feature if you guys can change it.

[fess-v]

Voting for the same change! it is important for us as a multisig project to integrate different wallets, on most of them we can only get just public keys with addresses, so we can only add that in the policy

[fess-v]

@bigspider adding to the points above - Xverse, Leather, Unisat - extension wallets for bitcoin, while connecting all of them do not have xpub returned, only normal public keys with addresses So if we wanna make an interface - we would make it separate for ledger devices and for other wallets, which is not really usable IMHO this feature should be optional even if it links together the addresses, so it opens possibilities to make mixed wallet integrations on Bitcoin ecosystem

Just describing our usage: We have Multisig wallets that use Taproot scripts, some have an internal public key, and some use MuSig to make it instead of allowing one key to spend from the multisig. Any wallet can be a signer, each transaction has taproot inputs and outputs, mostly use leaf scripts for normal use cases. Multisig script stays always the same for a group of addresses.

[bigspider]

Centralizing the discussion for this and other issues in #210.