wallet: Receive silent payment transactions #28453
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
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. |
This was referenced Sep 11, 2023
Merged
Merged
This was referenced Sep 11, 2023
Merged
Closed
`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.
achow101
force-pushed
the
silent-payments-recv
branch
from
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. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR implements receiving silent payment transactions through the use of a new
ScriptPubKeyMantype: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
createwalletwithsilent_payments=true. Such wallets will have a singleSilentPaymentsSPKMthat is used for both receiving and change. Since silent payments only have a single address, repeated calls togetnewaddressandgetrawchangeaddressalways 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,
TransactionAddedToMempoolis 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