Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature]: way to specify change_script_key when calling FundVirtualPSBT #1167

Open
habibitcoin opened this issue Oct 31, 2024 · 0 comments
Open
Labels
enhancement New feature or request

Comments

@habibitcoin
Copy link
Contributor

Is your feature request related to a problem? Please describe.
In the example of a pocket universe operator, where the virtual UTXOs have script_keys derived from pocket universe users, and BTC UTXOs have internal_keys derived from the operator, when calling the FundVirtualPSBT method, it would be nice to have a way to specify that any change should go to a script_key still controlled by the pocket universe user.

Currently FundVirtualPSBT always makes the assumption that any change should go to a new key derived from the operator, which does not easily support the usecase where an operator would like to prepare a virtual PSBT for a pocket universe user. See here: 660b369#diff-cbf26471d15b003b96c1d951b907a5271183126b15e4d8379788ebf96bad3ce1L692

Describe the solution you'd like
I'm not sure to be honest. I've considered 2 solutions, but each has its drawbacks:

  1. Perform a check if the input's script_key is spendable by the operator. If not, we should assume that the virtual UTXO is not ours so we should not derive a script_key that we control. Perhaps this check should be implemented regardless, but then the question is what to do from here.
  2. We could either re-use the script_key from the input if the input script key is not spendable by the operator. But this has privacy drawbacks since we'd be reusing virtual addresses.
  3. We could add an optional change_script_key optional field in the payload. I think perhaps this is the cleanest solution, and would not result in any implicit behaviors being performed by the daemon that the operator or user is not explicitly aware of.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: 🆕 New
Development

No branches or pull requests

1 participant