-
Notifications
You must be signed in to change notification settings - Fork 36.2k
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
wallet: Receive silent payment transactions #28453
Conversation
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
Add a method for retreiving a private key for a given scriptPubKey. If the scriptPubKey is a taproot output, tweak the private key with the merkle root or hash of the public key, if applicable.
Add a flag to the `CoinControl` object if silent payment destinations are provided. Before adding the flag, call a function which checks if: * The wallet has private keys * The wallet is unlocked Without both of the above being true, we cannot send to a silent payment address. During coin selection, if this flag is set, skip taproot inputs when script spend data is available. This is based on the assumption that if a user provides script spend data, they don't have access to the key path spend. As future improvement, we could instead check to see if we have access to the key path spend, and only exclude the output when we don't regardless of whether or not the user provides script spend data. Also skip UTXOs of type `WITNESS_UNKNOWN`, although it is very unlikely our wallet would ever try to spend a witness unknown output.
`CreateSilentPaymentsOutputs` gets the correct private keys, adds them together, groups the silent payment destinations and then generates the taproot script pubkeys. These are then passed back to CreateTransactionInternal, which uses these scriptPubKeys to update vecSend before adding them to the transaction outputs.
If sending to a silent payment destination, the change type should be taproot
In order to allow SilentPaymentsSPKMs to coexist with DescriptorSPKMs, we can no longer enforce that DescriptorSPKMs are the only kind of SPKM expected in a descriptor wallet.
LoadScriptPubKeyMan shouldn't enforce that a ScriptPubKeyMan cannot be active in multiple output types and internal-ness. This is instead moved to the RPC caller where active properties can be changed during import.
Optionally allow users to create a wallet that supports silent payments. This is signaled through an option in createwallet and a new wallet flag.
Call IsMineSilentPayment when sending to a SP address if our wallet has SPs enabled. In the next commit, we create a change output using silent payments. The presence of the change output will cause us to not fully check the transaction and thus never create the silent payment tweaks, which is why we check for self-transfers here. This feels a bit hacky, but works for now.
e036879
to
ed84b80
Compare
running on signet, |
Approach ACK. Will review soon. |
⌛ There hasn't been much activity lately and the patch still needs rebase. What is the status here?
|
Closing for now as up for grabs as I don't have time to work on this. With having a silent payments module in libsecp, and also the plan to change this to using a descriptor, a lot of this PR is also no longer relevant. |
This PR implements receiving silent payment transactions through the use of a new
ScriptPubKeyMan
type:SilentPaymentsSPKM
. This is a descriptor wallet only feature, although it does not use descriptors.This is an optional feature, so the only way to use it is to create a new wallet with
createwallet
withsilent_payments=true
. Such wallets will have a singleSilentPaymentsSPKM
that is used for both receiving and change. Since silent payments only have a single address, repeated calls togetnewaddress
andgetrawchangeaddress
always return the same address, however the receiving and change addresses are different, see the BIP for how the change is generated.Since silent payments requires the spent coins in order to extract public keys from them,
TransactionAddedToMempool
is modified to also provide that information. For scanning blocks, the wallet will retrieve that information from the undo data. Additionally, when rescanning, a silent payments wallet must use the slow rescan method.The labels feature has not been fully implemented yet and is left for a followup.
Based on #28122 and #28201
Alternative to #28202