should we disable bip32derivs in PSBT workflow?

So I'm testing out the PSBT workflow with some testnet coins. I got my watch-only wallet set up and managed to transfer some funds. But I came across a suggestion that raised a flag for me: From what I've gathered, keeping bip32derivs enabled seems important: Basically, it gives some added reassurance since it ensures that the change address where any leftover funds go actually exists in both your watch-only and main wallets. It seems pretty basic, and honestly, it’s a bit scary to think you might lose funds without this check in place. But I’ve heard there’s a downside, like possible leakage or something. I’m not that technical, so I’d appreciate it if someone could break this down for me in simpler terms. As I understand it, bip32derivs lets the GUI show the "(own address)" label, confirming that you control that change address. This feature is super handy; otherwise, I’d need to manually verify that I own that address on my airgapped wallet. I think there’s a method to check ownership of an address that hasn’t been generated yet, but I’d rather avoid the risk and keep it enabled. If it’s on by default, there’s probably a good reason for it. Just trying to wrap my head around what risks come with the potential leakage when I upload the psbt file to my online node for signing.

bip32derivs provides the derivation path for a particular key. This is necessary for some signers, while for other signers it is not. It is up to the signing software or hardware that you use to interpret and use that field, if they do at all. The tradeoff is that if you share the PSBT with anyone else, that derivation path information will still be in the PSBT and the people you share the PSBT with can therefore see your derivation paths.

Im using Bitcoin Knots for the the node and wallet. So would you recommend disabling this? I mean, it is not shared with anyone, but it is put on an online machine to sign the transaction.

If this is the concern, then it's easily mitigated by simply visually double-checking the transaction before signing it. I remember mentioning it in your previous thread that there's a visible indicator in Knots/Core to know if an output is yours. IIRC, I tested that with and without bip32derivs in the PSBT. Quoting myself:

The way it was worded here I read it as if I would lose the "(change)" check on the GUI: If I want to disable it, I need to create a new watch-only wallet again? Do I need to use that command or is there a way to do it without RPC? I have RPC disabled. So the way I understand it now is that this is irrelevant if you use Bitcoin Core/Knots for the whole process (node+wallet) and this is only useful if you use other wallets or hardware wallets? If so, then I guess it's safe to disable it. I mean, that guy said that this was disabled by default until 0.22. Why was it changed? I guess to avoid loss of funds for those that use devices with Bitcoin Core/Knots as a node? If I disable it, then I just process as usual with the GUI with the usual workflow? 0) Enable the "Enable PSBT Controls" checkbox 1) Go on the watch-only wallet and with Coin Control pick addresses as needed. 2) Click on "Create unsigned" and save .psbt file 3) Get this file into the airgap laptop and sign with the "File->Load PSBT from file..." GUI menu by clicking on "Sign Tx" 4) Save this now signed psbt file and move it back into watch-only laptop wallet 5) Load the file with "File->Load PSBT from file..." and click on "Broadcast Tx" So assuming disabling this does not screw anything up, the "(change)" notice should be there. But just to triple check, how can I know that I own the change address on the airgap laptop given that that address was not generated yet? I remember there was a command for this I think. Btw, on a theoretical attack were someone steals your PSBT file, what is exactly leaked? Like what could they do with it? with and without the bip32 enabled, to see the difference. Like, they could bruteforce any keys on your wallet? or only the addresses involved on the PSBT transaction? etc.

It's pertaining to your xpub that's included to the PSBT with --bip32derivs enabled, So basically, they can derive all of the parent descriptor's addresses with it. That'll impact your privacy. Security wise, they may be able to compute all the private keys (not just one) of those addresses only if you've leaked at least one private key from that descriptor. If you haven't, it's mostly a privacy issue for now. But maybe in the near future, a fast enough quantum computer may be able to calculate the private keys from your public keys.