Setting bip32derivs to false with walletprocesspsbt includes bip32_derivs for outputs. #30294

1. 
   Fonta1n3 commented at 10:03 am on June 17, 2024: none

   Please describe the feature you’d like to see added.

   I’d like an option to remove the bip32derivs from outputs as well as inputs when calling walletprocesspsbt.

   Is your feature related to a problem, if so please describe it.

   I am using Bitcoin Core to create psbt’s which are meant to be passed around to multiple users for collaborative transactions. I want to leak as little data as possible. When I set bip32derivs to false with walletprocesspsbt it does not remove the bip32derivs for outputs.

   Describe the solution you’d like

   I would like to be able to specify whether or not bip32derivs are included in outputs with walletprocesspsbt.

   Describe any alternatives you’ve considered

   No response

   Please leave any additional context

   No response

2. Fonta1n3 added the label Feature on Jun 17, 2024
3. willcl-ark added the label Wallet on Jun 24, 2024
4. willcl-ark added the label RPC/REST/ZMQ on Jun 24, 2024
5. 
   willcl-ark commented at 7:43 pm on June 25, 2024: member

   Hi @Fonta1n3

   I’ve taken a look at this , but in making a few changes one thing I wasn’t sure of from a design perspective, was whether it would be more (or less) deisrable to have the bip32derivs bool always toggle both input and output derivations, or might be preferable to have an option for doing each independently?

   I think having them both effected by the same option probably makes more sense (in terms of what a user would “expect”), and I think it would actually still be possible to add them to inputs or outputs even with this new behaviour (by calling walletprocesspsbt individually for inputs and outputs with the flag inverted).

   But I was wondering if you might be able to elaborate more on your use-case/workflow that you have in mind?

6. 
   Fonta1n3 commented at 9:10 pm on June 25, 2024: none

   I think it should remove all bip32derivs.

   My flow is like this:

   Create a psbt with bip32derivs included, pass psbt to offline signer which signs inputs.

   Pass signed psbt to walletprocesspsbt with bip32derivs set to false so that I can share the resulting psbt with other parties to create collaborative transactions, currently they would see my seed fingerprint and derivation paths for outputs which is not ideal.

7. 
   willcl-ark commented at 11:02 am on June 26, 2024: member

   Ok I see, what you are actually after is an active “eraser”, so that you can perform the signing (perhaps on an HWW) with derivation paths included, but then not have them present when passing on to another party. I think this works better for the Combiner role, personally.

   Your workflow would then work something more like this:

   Create a psbt with bip32derivs included, pass psbt to offline signer which signs inputs.

   Pass signed psbt to combinepsbt with some flag set to false so that I can share the resulting psbt with other parties to create collaborative transactions…

   I opened a draft PR #30341 to try and get some feedback on my current approach to this.

8. 
   Fonta1n3 commented at 4:11 am on June 27, 2024: none

   Hmm not sure I understand why combinepsbt would be involved in stripping the data or if I’m misreading.

   In Payjoin transactions for example you need to send a psbt to your counterparty, stripping that psbt of any bip32derivs which the counter party needn’t sign for or outputs they don’t need to verify would be beneficial for privacy.

   In short, you’d need to strip the bip32derivs before using combinepsbt or joinpsbts.

9. 
   Fonta1n3 commented at 4:12 am on June 27, 2024: none

   Thank you for opening a PR I will keep an eye on it and add any input I can there. Thanks!

Contributors
Fonta1n3 willcl-ark

Labels
Feature Wallet RPC/REST/ZMQ