BIP 352: Silent Payments #1458

86+
87+Bob must include the same ''outpoint_hash'' when scanning.
88+
89+''' Using all inputs '''
90+
91+In our simplified example we have been referring to Alice’s transactions as having only one input ''A'', but in reality a Bitcoin transaction can have many inputs. Instead of requiring Alice to pick a particular input and requiring Bob to check each input separately, we can instead require Alice to perform the tweak with the sum of the input public keys<ref name="other_inputs">'''What about inputs without public keys?''' Inputs without public keys can still be spent in the transaction but are simply ignored in the ''Silent Payments'' protocol.</ref>. This significantly reduces Bob's scanning requirement, makes light client support more feasible<ref name="using_all_inputs">'''How does using all inputs help light clients?''' If Alice uses a random input for the tweak, Bob necessarily has to have access to and check all transaction inputs, which requires performing an ECC multiplication per input. If instead Alice performs the tweak with the sum of the input public keys, Bob only needs the summed 32 byte public key per transaction and only does one ECC multiplication per transaction. Bob can then use BIP158 block filters to determine if any of the outputs exist in a block and thus avoids downloading transactions which don't belong to him.</ref>, and protects Alice's privacy in collaborative transaction protocols such as CoinJoin<ref name=""all_inputs_and_coinjoin">'''Why does using all inputs matter for CoinJoin?''' If Alice uses a random input to create the output for Bob, this necessarily reveals to Bob which input Alice has control of. If Alice is paying Bob as part of a CoinJoin, this would reveal which input belongs to her, degrading the anonymity set of the CoinJoin and giving Bob more information about Alice. If instead all inputs are used, Bob has no way of knowing which input(s) belong to Alice. This comes at the cost of increased complexity as the CoinJoin participants now need to coordinate to create the silent payment output and would need to use [https://gist.github.com/RubenSomsen/be7a4760dd4596d06963d67baf140406 Blind-Diffie-Hellman] to prevent the other participants from learning who Alice is paying</ref>.

187+
188+Inputs with conditional branches or multiple public keys (e.g ''CHECKMULTISIG'') are not included as this introduces malleability and would allow a sender to re-sign with a different set of public keys after the silent payment output has been derived. This is not a concern when the sender controls all of the inputs, but is an issue for CoinJoins and other collaborative protocols, where a malicious participant can participate in deriving the silent payment address with one set of keys and then re-broadcast the transaction with signatures for a different set of public keys. P2TR can have hidden conditional branches (script path), but we work around that as described below.
189+
190+''' P2TR (key path spends)'''
191+
192+The sender MUST use the tweaked private key corresponding to the taproot output key (i.e. the tweaked private key for a key path spend). If the taproot output key is not available, the output cannot be used for sending a silent payment. The receiver always uses the taproot output key when scanning, regardless of whether the taproot output is being used in a key path spend or a script path spend<ref name="why_always_output_pubkey">''' Why not skip all taproot script path spends? ''' This causes malleability issues for CoinJoins. If the silent payments protocol skipped taproot script path spends, this would allow an attacker to join a CoinJoin round, participate in deriving the silent payment address using the tweaked private key for a key path spend, and then broadcast their own version of the transaction using the script path spend. If the receiver were to only consider key path spends, they would skip the attacker's script path spend input when deriving the shared secret and not be able to find the funds.</ref>.

216+==== Selecting inputs ====
217+
218+The sending wallet performs coin selection as usual with the following restrictions:
219+
220+* At least one input MUST be from the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' list
221+* Exclude ''P2TR'' script path spends, unless ''H'' is used as the internal public key

189+
190+''' P2TR (key path spends)'''
191+
192+The sender MUST use the tweaked private key corresponding to the taproot output key (i.e. the tweaked private key for a key path spend). If the taproot output key is not available, the output cannot be used for sending a silent payment. The receiver always uses the taproot output key when scanning, regardless of whether the taproot output is being used in a key path spend or a script path spend<ref name="why_always_output_pubkey">''' Why not skip all taproot script path spends? ''' This causes malleability issues for CoinJoins. If the silent payments protocol skipped taproot script path spends, this would allow an attacker to join a CoinJoin round, participate in deriving the silent payment address using the tweaked private key for a key path spend, and then broadcast their own version of the transaction using the script path spend. If the receiver were to only consider key path spends, they would skip the attacker's script path spend input when deriving the shared secret and not be able to find the funds.</ref>.
193+
194+The one exception is script path spends that use NUMS point ''H'' as their internal key (as defined in [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#constructing-and-spending-taproot-outputs BIP341: Constructing and spending Taproot outputs]), in which case the output will be skipped for the purposes of shared secret derivation<ref name="why_ignore_h">'''Why skip outputs with H as the internal taproot key?''' If use cases get popularized where the taproot key path cannot be used, these outputs can still be included without getting in the way of making a silent payment, provided they specifically use H as their internal taproot key.</ref>.

171+=== Outpoints hash ===
172+
173+The sender and receiver MUST calculate an outpoints hash for the transaction in the following manner:
174+
175+* Collect each ''outpoint'' used as an input to the transaction
176+* Let ''outpoints = outpoint<sub>0</sub> || … || outpoint<sub>n</sub>'', sorted by txid and vout, ascending order

207+
208+
209+    scriptSig: <Signature> <Public Key>
210+
211+
212+The receiver obtains the public key from the ''scriptSig''. The receiver MUST parse the ''scriptSig'' for the public key, even if the ''scriptSig'' is non-standard (e.g. <code><dummy> OP_DROP <Signature> <Public Key></code>). This is to address the [https://en.bitcoin.it/wiki/Transaction_malleability third-party malleability of ''P2PKH'' ''scriptSigs''].

263+** Let ''outputs_to_check = all unspent taproot outputs in the transaction''
264+** Starting with ''n = 0'':
265+*** Let ''t<sub>n</sub> = sha256(ecdh_shared_secret || ser<sub>32</sub>(n))''
266+*** Compute ''P<sub>n</sub> = t<sub>n</sub>·G + B<sub>spend</sub>''
267+**** If ''P<sub>n</sub>'' is in ''outputs_to_check'', add it to the wallet and continue with ''n++''
268+**** If ''P<sub>n</sub>'' is not found and the wallet has precomputed labels<ref name="precompute_labels">''' Why precompute labels?''' Naively, a wallet could some max integer ''M'' which indicates the total number of labels it has used. When checking a transaction, the wallet would need to add all possible labels to each output. This ends up being ''n·m'' additions, where ''n'' is the number of outputs in the transaction and ''m'' is the number of labels in the wallet</ref>:

114+Alice performs the tweak as before using one of the published ''(B<sub>scan</sub>, B<sub>m</sub>)'' pairs. Bob detects the labeled payment in the following manner:
115+
116+* Let ''P<sub>0</sub> = hash(outpoints_hash·b<sub>scan</sub>·A || 0)·G + B<sub>spend</sub>''
117+* Subtract ''P<sub>0</sub>'' from each of the transaction outputs and check if the remainder matches any of the labels (''1·G, 2·G ..'') that the wallet has previously used
118+
119+It is important to note that an outside observer can easily deduce that each published ''(B<sub>scan</sub>, B<sub>m</sub>)'' pair is owned by the same entity as each published address will have ''B<sub>scan</sub>'' in common. As such, labels are not meant as a way for Bob to manage separate identities, but rather a way for Bob to determine the source of an incoming payment.

187+
188+Inputs with conditional branches or multiple public keys (e.g. ''CHECKMULTISIG'') are not included as this introduces malleability and would allow a sender to re-sign with a different set of public keys after the silent payment output has been derived. This is not a concern when the sender controls all of the inputs, but is an issue for CoinJoins and other collaborative protocols, where a malicious participant can participate in deriving the silent payment address with one set of keys and then re-broadcast the transaction with signatures for a different set of public keys. P2TR can have hidden conditional branches (script path), but we work around that as described below.
189+
190+''' P2TR (key path spends)'''
191+
192+The sender MUST use the tweaked private key corresponding to the taproot output key (i.e. the tweaked private key for a key path spend). If the taproot output key is not available, the output cannot be used for sending a silent payment. The receiver always uses the taproot output key when scanning, regardless of whether the taproot output is being used in a key path spend or a script path spend<ref name="why_always_output_pubkey">''' Why not skip all taproot script path spends? ''' This causes malleability issues for CoinJoins. If the silent payments protocol skipped taproot script path spends, this would allow an attacker to join a CoinJoin round, participate in deriving the silent payment address using the tweaked private key for a key path spend, and then broadcast their own version of the transaction using the script path spend. If the receiver were to only consider key path spends, they would skip the attacker's script path spend input when deriving the shared secret and not be able to find the funds.</ref>.

146+
147+* Receiver addresses are always [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341] taproot outputs<ref name="why_taproot">'''Why only taproot outputs?''' Providing too much optionality for the protocol makes it difficult to implement and can be at odds with the goal of providing the best privacy. Limiting to taproot outputs helps simplify the implementation significantly while also putting users in the best eventual anonymity set.</ref>
148+* The sender should sign with one of the sighash flags ''ALL, SINGLE, NONE'' (''ANYONECANPAY'' is unsafe). It is strongly recommended implementations only use ''SIGHASH_ALL'' for silent payments<ref name="why_sighash_all">'''Why recommend ''SIGHASH_ALL''?''' Since the output address for the receiver is derived from from the sum of the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' public keys, the inputs must not change once the sender has signed the transaction. If the inputs are allowed to change after the fact, the receiver will not be able to calculate the shared secret needed to find and spend the output. It is currently an open question on how a future version of silent payments could be made to work with new sighash flags such as ''SIGHASH_GROUP'' and ''SIGHASH_ANYPREVOUT''.</ref>
149+* Inputs used to derive the shared secret are from the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' list
150+
151+A transaction is not a ''Silent Payments v0'' transaction and should be skipped entirely<ref name="why_skip_transactions">'''Why skip transactions that spend unknown output scripts?''' Skipping transactions that spend unknown output scripts allows us to have a clean upgrade path for Silent Payments by avoiding the need to scan the same transaction multiple times with different rule sets. If a fancy new output type is added in the future and Silent Payments v1 is released with support, we would want to avoid having to first scan the transaction with the silent payment v0 rules and then again with the silent payment v1 rules.</ref> when scanning if any of the following are true:

161+* Let ''B<sub>scan</sub>, b<sub>scan</sub> = Receiver's [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki BIP340] scan public key and corresponding private key''
162+* Let ''B<sub>spend</sub>, b<sub>spend</sub> = Receiver's [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki BIP340] spend public key and corresponding private key''
163+* Let ''B<sub>m</sub> = B<sub>spend</sub> + m·G'', where ''m'' an optional integer tweak for labeling
164+** In the case of ''m'' = 0, no label is applied and ''B<sub>m</sub> = B<sub>spend</sub>''
165+* The final address is a [https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki Bech32m] encoding of:
166+** The human-readable part "sp" for mainnet, "tsp" for testnets (e.g.  signet, testnet, regtest)

164+** In the case of ''m'' = 0, no label is applied and ''B<sub>m</sub> = B<sub>spend</sub>''
165+* The final address is a [https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki Bech32m] encoding of:
166+** The human-readable part "sp" for mainnet, "tsp" for testnets (e.g.  signet, testnet, regtest)
167+** The data-part values:
168+*** The character "q", to represent a silent payment address of version 0
169+*** The 64 byte concatenation of the receiver's public keys, ''B<sub>scan</sub> || B<sub>m</sub>''

187+
188+Inputs with conditional branches or multiple public keys (e.g. ''CHECKMULTISIG'') are not included as this introduces malleability and would allow a sender to re-sign with a different set of public keys after the silent payment output has been derived. This is not a concern when the sender controls all of the inputs, but is an issue for CoinJoins and other collaborative protocols, where a malicious participant can participate in deriving the silent payment address with one set of keys and then re-broadcast the transaction with signatures for a different set of public keys. P2TR can have hidden conditional branches (script path), but we work around that as described below.
189+
190+''' P2TR (key path)'''
191+
192+The sender MUST use the private key corresponding to the taproot output key (i.e. the tweaked private key for a key path spend). This can be a single private key or an aggregate key (e.g. taproot outputs using Musig2 or FROST)<ref name="musig_frost_support">'''Are key aggregation techniques like FROST and Musig2 supported?''' Any taproot output able to do a key path spend is supported. While a full specification of how to do this securely is outside the scope of this BIP, in theory any offline key aggregation technique can be used, such as FROST or Musig2. This would require participants to perform the ECDH step collaboratively e.g ''ECDH = a<sub>0</sub>·B<sub>scan</sub> + a<sub>1</sub>·B<sub>scan</sub> + ... + a<sub>t</sub>·B<sub>scan</sub>'' and ''P = hash(outpoints_hash·ECDH || 0)·G + B<sub>spend</sub>''. Additionally, it may be necessary for the participants to provide a DLEQ proof to ensure they are not acting maliciously.</ref>. If this key is not available, the output cannot be used for sending a silent payment. The receiver always uses the taproot output key when scanning, regardless of whether the taproot output is being used in a key path spend or a script path spend<ref name="why_always_output_pubkey">''' Why not skip all taproot script path spends? ''' This causes malleability issues for CoinJoins. If the silent payments protocol skipped taproot script path spends, this would allow an attacker to join a CoinJoin round, participate in deriving the silent payment address using the tweaked private key for a key path spend, and then broadcast their own version of the transaction using the script path spend. If the receiver were to only consider key path spends, they would skip the attacker's script path spend input when deriving the shared secret and not be able to find the funds. Additionally, there may be scenarios where a sender has access to the key path private key but spends the output using the script path.</ref>.

216+==== Selecting inputs ====
217+
218+The sending wallet performs coin selection as usual with the following restrictions:
219+
220+* At least one input MUST be from the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' list
221+* The sending wallet MUST have access to the taproot output key, unless ''H'' is used as the internal public key

234+*** Let ''P<sub>mn</sub> = t<sub>n</sub>·G + B<sub>m</sub>''
235+*** Encode ''P<sub>mn</sub>'' as a [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341] taproot output
236+*** Optionally, repeat with n++ to create additional outputs for the current ''B<sub>m</sub>''
237+*** If no additional outputs are required, continue to the next ''B<sub>m</sub>'' with ''n++''
238+
239+The sender should check to ensure that no two outputs in the final transaction have the same ''t<sub>n</sub>'' as this could result in a loss of privacy for the receiver<ref name="why_not_the_same_tn">''' Why can't two outputs have the same ''t<sub>n</sub>''?''' If paying the same entity but to two separate labeled addresses in the same transaction without incrementing ''n'', the two outputs would be ''t<sub>n</sub>·G + B<sub>spend</sub> + i·G'' and ''t<sub>n</sub>·G + B<sub>spend</sub> + j·G''. The attacker could subtract the two values and observe that the distance between i and j is small. This would allow them to deduce that this transaction is a silent payment transaction and that a single entity received two outputs, but won't tell them who the entity is.</ref>.

246+
247+A scan and spend key pair using BIP32 derivation are defined (taking inspiration from [https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki BIP44]) in the following manner:
248+
249+
250+    Spend private key: m / purpose' / coin_type' / account' / silent_payment_version' / 0' / 0
251+     Scan private key: m / purpose' / coin_type' / account' / silent_payment_version' / 1' / 0

166+** The human-readable part "sp" for mainnet, "tsp" for testnets (e.g.  signet, testnet)
167+** The data-part values:
168+*** The character "q", to represent a silent payment address of version 0
169+*** The 64 byte concatenation of the receiver's public keys, ''B<sub>scan</sub> || B<sub>m</sub>''
170+
171+Note: [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki BIP173] imposes a 90 character for bech32 strings, whereas a silent payment address requires 115 characters.

230+* Group receiver silent payment addresses by ''B<sub>scan</sub>'' (e.g. each group consists of one ''B<sub>scan</sub>'' and one or more ''B<sub>m</sub>'')
231+* For each group:
232+** Let ''ecdh_shared_secret = outpoints_hash·a·B<sub>scan</sub>'', where ''ecdh_shared_secret'' is a compressed public key
233+** Let ''n = 0''
234+** For each ''B<sub>m</sub>'' in the group:
235+*** Let ''t<sub>n</sub> = sha256(ecdh_shared_secret || ser<sub>32</sub>(n))''

255+==== Scanning ====
256+
257+For each transaction the receiving wallet suspects might be a silent payment to themselves, it must:
258+
259+* Generate the ''outpoints_hash'', using the method described above
260+* Let ''A = A<sub>0</sub> + A<sub>1</sub> + … A<sub>n</sub>'', where each ''A<sub>i</sub>'' is the public key of an input from the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' list

134+== Specification ==
135+
136+We use the following functions and conventions:
137+
138+* ''outpoint'' (36 bytes): the <code>COutPoint</code> of an input (32-byte hash + 4-byte little-endian)
139+* ser<sub>32</sub>(i): serializes a 32-bit unsigned integer ''i'' as a 4-byte little-endian

162+
163+A silent payment address is constructed in the following manner:
164+
165+* Let ''B<sub>scan</sub>, b<sub>scan</sub> = Receiver's [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki BIP340] scan public key and corresponding private key''
166+* Let ''B<sub>spend</sub>, b<sub>spend</sub> = Receiver's [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki BIP340] spend public key and corresponding private key''
167+* Let ''B<sub>m</sub> = B<sub>spend</sub> + m·G'', where ''m'' an optional integer tweak for labeling

86+
87+Bob must include the same ''outpoint_hash'' when scanning.
88+
89+''' Using all inputs '''
90+
91+In our simplified example we have been referring to Alice's transactions as having only one input ''A'', but in reality a Bitcoin transaction can have many inputs. Instead of requiring Alice to pick a particular input and requiring Bob to check each input separately, we can instead require Alice to perform the tweak with the sum of the input public keys<ref name="other_inputs">'''What about inputs without public keys?''' Inputs without public keys can still be spent in the transaction but are simply ignored in the ''Silent Payments'' protocol.</ref>. This significantly reduces Bob's scanning requirement, makes light client support more feasible<ref name="using_all_inputs">'''How does using all inputs help light clients?''' If Alice uses a random input for the tweak, Bob necessarily has to have access to and check all transaction inputs, which requires performing an ECC multiplication per input. If instead Alice performs the tweak with the sum of the input public keys, Bob only needs the summed 32 byte public key per transaction and only does one ECC multiplication per transaction. Bob can then use BIP158 block filters to determine if any of the outputs exist in a block and thus avoids downloading transactions which don't belong to him. It is still an open question as to how Bob can source the 32 bytes per transaction in a trustless manner, see [[#appendix-a-light-client-support|Appendix A: Light Client Support]] for more details.</ref>, and protects Alice's privacy in collaborative transaction protocols such as CoinJoin<ref name=""all_inputs_and_coinjoin">'''Why does using all inputs matter for CoinJoin?''' If Alice uses a random input to create the output for Bob, this necessarily reveals to Bob which input Alice has control of. If Alice is paying Bob as part of a CoinJoin, this would reveal which input belongs to her, degrading the anonymity set of the CoinJoin and giving Bob more information about Alice. If instead all inputs are used, Bob has no way of knowing which input(s) belong to Alice. This comes at the cost of increased complexity as the CoinJoin participants now need to coordinate to create the silent payment output and would need to use [https://gist.github.com/RubenSomsen/be7a4760dd4596d06963d67baf140406 Blind-Diffie-Hellman] to prevent the other participants from learning who Alice is paying.</ref>.

112+* Publish ''(B<sub>scan</sub>, B<sub>0</sub>)'', ''(B<sub>scan</sub>, B<sub>1</sub>) …''
113+
114+Alice performs the tweak as before using one of the published ''(B<sub>scan</sub>, B<sub>m</sub>)'' pairs. Bob detects the labeled payment in the following manner:
115+
116+* Let ''P<sub>0</sub> = B<sub>spend</sub> + hash(outpoints_hash·b<sub>scan</sub>·A || 0)·G''
117+* Subtract ''P<sub>0</sub>'' from each of the transaction outputs and check if the remainder matches any of the labels (''1·G, 2·G ..'') that the wallet has previously used

175+|}
176+
177+''v31'' (l) is reserved for a backwards incompatible change, if needed. For ''Silent Payments v0'':
178+
179+* If the receiver's silent payment address version is:
180+** ''v0'': check that the data part is exactly 66-bytes. Otherwise, fail

186+
187+A transaction is not a ''Silent Payments v0'' transaction and should be skipped entirely when scanning if any of the following are true:
188+
189+* The transaction does not contain any BIP341 taproot outputs
190+* The transaction does not have at least one input from the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' list
191+* The transaction inputs contain a new, undefined output type (e.g. SegWit versions > 1)<ref name="skip_txs_with_unknown_prevouts">'''Why skip transactions that spend unknown output scripts?''' Skipping transactions that spend unknown output scripts allows us to have a clean upgrade path for Silent Payments by avoiding the need to scan the same transaction multiple times with different rule sets. If a fancy new output type is added in the future and Silent Payments v1 is released with support, we would want to avoid having to first scan the transaction with the silent payment v0 rules and then again with the silent payment v1 rules.</ref>

227+
228+''' P2TR '''
229+
230+The sender MUST use the private key corresponding to the taproot output key (i.e. the tweaked private key for a key path spend). This can be a single private key or an aggregate key (e.g. taproot outputs using MuSig2 or FROST)<ref name="musig_frost_support">'''Are key aggregation techniques like FROST and MuSig2 supported?''' Any taproot output able to do a key path spend is supported. While a full specification of how to do this securely is outside the scope of this BIP, in theory any offline key aggregation technique can be used, such as FROST or MuSig2. This would require participants to perform the ECDH step collaboratively e.g. ''ECDH = a<sub>0</sub>·B<sub>scan</sub> + a<sub>1</sub>·B<sub>scan</sub> + ... + a<sub>t</sub>·B<sub>scan</sub>'' and ''P = B<sub>spend</sub> + hash(outpoints_hash·ECDH || 0)·G''. Additionally, it may be necessary for the participants to provide a DLEQ proof to ensure they are not acting maliciously.</ref>. If this key is not available, the output cannot be included as an input to the transaction. The receiver always uses the taproot output key when scanning, regardless of whether the taproot output is using a key path spend or a script path spend<ref name="why_always_output_pubkey">''' Why not skip all taproot script path spends? ''' This causes malleability issues for CoinJoins. If the silent payments protocol skipped taproot script path spends, this would allow an attacker to join a CoinJoin round, participate in deriving the silent payment address using the tweaked private key for a key path spend, and then broadcast their own version of the transaction using the script path spend. If the receiver were to only consider key path spends, they would skip the attacker's script path spend input when deriving the shared secret and not be able to find the funds. Additionally, there may be scenarios where a sender has access to the key path private key but spends the output using the script path.</ref>.
231+
232+The one exception is script path spends that use NUMS point ''H'' as their internal key (as defined in [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#constructing-and-spending-taproot-outputs BIP341: Constructing and spending Taproot outputs]), in which case the output will be skipped for the purposes of shared secret derivation<ref name="why_ignore_h">'''Why skip outputs with H as the internal taproot key?''' If use cases get popularized where the taproot key path cannot be used, these outputs can still be included without getting in the way of making a silent payment, provided they specifically use H as their internal taproot key.</ref>.

253+
254+==== Selecting inputs ====
255+
256+The sending wallet performs coin selection as usual with the following restrictions:
257+
258+* At least one input MUST be from the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' list

300+
301+Wallet software MUST use hardened derivation to ensure the master key is not exposed in the event the scan private key is compromised. Purpose is a constant set to ''352'' following the BIP43 recommendation. Refer to [https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki BIP43] and [https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki BIP44] for more details.
302+
303+==== Scanning ====
304+
305+For each transaction the receiving wallet suspects might be a silent payment to themselves, it must:

314+*** Compute ''P<sub>n</sub> = B<sub>spend</sub> + t<sub>n</sub>·G''
315+*** For each ''output'' in ''outputs_to_check'':
316+**** If ''P<sub>n</sub>'' equals ''output'':
317+***** Add ''P<sub>n</sub>'' to the wallet
318+***** Remove ''output'' from ''outputs_to_check'' and rescan ''outputs_to_check'' with ''n++''
319+**** Else, if the wallet has precomputed labels (including the change label, if used)<ref name="precompute_labels">''' Why precompute labels?''' Naively, a wallet could store some max integer ''M'' which indicates the total number of labels it has used. When checking a transaction, the wallet would need to add all possible labels to each output. This ends up being ''n·m'' additions, where ''n'' is the number of outputs in the transaction and ''m'' is the number of labels in the wallet. By precomputing the labels, the wallet only needs to compute ''m·G'' once per label and can determine if a label was used via a lookup, rather than adding each label to each output.</ref>:

388+
389+Below is a list of functional tests which should be included in sending and receiving implementations.
390+
391+==== Sending ====
392+
393+* Ensure taproot outputs are excluded during coin selection if the sender does not have access to the key path private key (unless using ''H'' as the taproot internal key)

182+** ''v31'': fail
183+* Receiver addresses are always [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341] taproot outputs<ref name="why_taproot">'''Why only taproot outputs?''' Providing too much optionality for the protocol makes it difficult to implement and can be at odds with the goal of providing the best privacy. Limiting to taproot outputs helps simplify the implementation significantly while also putting users in the best eventual anonymity set.</ref>
184+* The sender should sign with one of the sighash flags ''ALL, SINGLE, NONE'' (''ANYONECANPAY'' is unsafe). It is strongly recommended implementations only use ''SIGHASH_ALL'' for silent payments<ref name="why_sighash_all">'''Why recommend ''SIGHASH_ALL''?''' Since the output address for the receiver is derived from from the sum of the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' public keys, the inputs must not change once the sender has signed the transaction. If the inputs are allowed to change after the fact, the receiver will not be able to calculate the shared secret needed to find and spend the output. It is currently an open question on how a future version of silent payments could be made to work with new sighash flags such as ''SIGHASH_GROUP'' and ''SIGHASH_ANYPREVOUT''.</ref>
185+* Inputs used to derive the shared secret are from the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' list
186+
187+A transaction is not a ''Silent Payments v0'' transaction and should be skipped entirely when scanning if any of the following are true:

302@@ -303,6 +303,70 @@ If using a seed phrase only style backup, the user can recover the wallet's unsp
303 
304 Silent payments introduces a new address format and protocol for sending and as such is not compatible with older wallet software or wallets which have not implemented the silent payments protocol.
305 
306+== Test Vectors ==
307+
308+A [[bip-0340/test-vectors.csv|collection of test vectors in JSON format]] are provided, along with a [[bip-0340/reference.py|python reference implementation]]. Each test vector consists of a sending test case and corresponding receiving test case. This is to allow sending and receiving to be implemented separately. Test cases use the following schema:

207+** The human-readable part "sp" for mainnet, "tsp" for testnets (e.g.  signet, testnet)
208+** The data-part values:
209+*** The character "q", to represent a silent payment address of version 0
210+*** The 66 byte concatenation of the receiver's public keys, ''ser<sub>P</sub>(B<sub>scan</sub>) || ser<sub>P</sub>(B<sub>m</sub>)''
211+
212+Note: [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki BIP173] imposes a 90 character limit for Bech32 strings, whereas a silent payment address requires 117 characters.

199+
200+A silent payment address is constructed in the following manner:
201+
202+* Let ''B<sub>scan</sub>, b<sub>scan</sub> = Receiver's scan public key and corresponding private key''
203+* Let ''B<sub>spend</sub>, b<sub>spend</sub> = Receiver's spend public key and corresponding private key''
204+* Let ''B<sub>m</sub> = B<sub>spend</sub> + m·G'', where ''m'' an optional integer tweak for labeling

279+** For each ''B<sub>m</sub>'' in the group:
280+*** Let ''t<sub>n</sub> = sha256(ser<sub>P</sub>(ecdh_shared_secret) || ser<sub>32</sub>(n))''
281+*** Let ''P<sub>mn</sub> = B<sub>m</sub> + t<sub>n</sub>·G''
282+*** Encode ''P<sub>mn</sub>'' as a [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341] taproot output
283+*** Optionally, repeat with n++ to create additional outputs for the current ''B<sub>m</sub>''
284+*** If no additional outputs are required, continue to the next ''B<sub>m</sub>'' with ''n++''<ref name="why_not_the_same_tn">''' Why not re-use ''t<sub>n</sub>''? when paying different labels to the same receiver?''' If paying the same entity but to two separate labeled addresses in the same transaction without incrementing ''n'', the two outputs would be ''B<sub>spend</sub> + t<sub>n</sub>·G + i·G'' and ''B<sub>spend</sub> + t<sub>n</sub>·G + j·G''. The attacker could subtract the two values and observe that the distance between i and j is small. This would allow them to deduce that this transaction is a silent payment transaction and that a single entity received two outputs, but won't tell them who the entity is.</ref>

270+
271+* Collect the private keys for each input from the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' list
272+* For each private key ''a<sub>i</sub>'' corresponding to a [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341] taproot output, check that the private key produces a point with an even y-value and negate the private key if not<ref name="why_negate_taproot_private_keys">'''Why do taproot private keys need to be checked?''' Recall from [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki BIP340] that each x-only public key has two corresponding private keys, ''d'' and ''n - d''. To maintain parity between sender and receiver, it is necessary to use the private key corresponding to the even y-value when performing the ECDH step since the receiver will assume the even y-value when summing the taproot x-only public keys.</ref>
273+* Let ''a = a<sub>0</sub> + a<sub>1</sub> + … a<sub>n</sub>'', where each ''a<sub>i</sub>'' has been negated if necessary
274+* Generate the ''outpoints_hash'', using the method described above
275+* Group receiver silent payment addresses by ''B<sub>scan</sub>'' (e.g. each group consists of one ''B<sub>scan</sub>'' and one or more ''B<sub>m</sub>'')

180+* If the receiver's silent payment address version is:
181+** ''v0'': check that the data part is exactly 66-bytes. Otherwise, fail
182+** ''v1'' through ''v30'': read the first 66-bytes of the data part and discard the remaining bytes (if any)
183+** ''v31'': fail
184+* Receiver addresses are always [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341] taproot outputs<ref name="why_taproot">'''Why only taproot outputs?''' Providing too much optionality for the protocol makes it difficult to implement and can be at odds with the goal of providing the best privacy. Limiting to taproot outputs helps simplify the implementation significantly while also putting users in the best eventual anonymity set.</ref>
185+* The sender should sign with one of the sighash flags ''ALL, SINGLE, NONE'' (''ANYONECANPAY'' is unsafe). It is strongly recommended implementations only use ''SIGHASH_ALL'' for silent payments<ref name="why_sighash_all">'''Why recommend ''SIGHASH_ALL''?''' Since the output address for the receiver is derived from from the sum of the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' public keys, the inputs must not change once the sender has signed the transaction. If the inputs are allowed to change after the fact, the receiver will not be able to calculate the shared secret needed to find and spend the output. It is currently an open question on how a future version of silent payments could be made to work with new sighash flags such as ''SIGHASH_GROUP'' and ''SIGHASH_ANYPREVOUT''.</ref>

189+
190+A transaction is a ''Silent Payments v0'' transaction and MUST be scanned if and only if all of the following are true:
191+
192+* The transaction contains at least one BIP341 taproot output
193+* The transaction has at least one input from the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' list
194+* The transaction does not contain a new, undefined output type (e.g. SegWit versions > 1)<ref name="skip_txs_with_unknown_prevouts">'''Why skip transactions that spend unknown output scripts?''' Skipping transactions that spend unknown output scripts allows us to have a clean upgrade path for Silent Payments by avoiding the need to scan the same transaction multiple times with different rule sets. If a fancy new output type is added in the future and Silent Payments v1 is released with support, we would want to avoid having to first scan the transaction with the silent payment v0 rules and then again with the silent payment v1 rules.</ref>

281+*** Let ''t<sub>n</sub> = sha256(ser<sub>P</sub>(ecdh_shared_secret) || ser<sub>32</sub>(n))''
282+*** Let ''P<sub>mn</sub> = B<sub>m</sub> + t<sub>n</sub>·G''
283+*** Encode ''P<sub>mn</sub>'' as a [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341] taproot output
284+*** Optionally, repeat with n++ to create additional outputs for the current ''B<sub>m</sub>''
285+*** If no additional outputs are required, continue to the next ''B<sub>m</sub>'' with ''n++''<ref name="why_not_the_same_tn">''' Why not re-use ''t<sub>n</sub>''? when paying different labels to the same receiver?''' If paying the same entity but to two separate labeled addresses in the same transaction without incrementing ''n'', the two outputs would be ''B<sub>spend</sub> + t<sub>n</sub>·G + i·G'' and ''B<sub>spend</sub> + t<sub>n</sub>·G + j·G''. The attacker could subtract the two values and observe that the distance between i and j is small. This would allow them to deduce that this transaction is a silent payment transaction and that a single entity received two outputs, but won't tell them who the entity is.</ref>
286+** Optionally, if the sending wallet implements receiving silent payments, it can create change outputs in the following manner:

23+
24+=== Motivation ===
25+
26+Using a new address for each Bitcoin transaction is a crucial aspect of maintaining privacy. This often requires a secure interaction between sender and receiver so that the receiver can hand out a fresh address, a batch of fresh addresses, or a method for the sender to generate addresses on-demand, such as an xpub.
27+
28+However, interaction is often infeasible and in many cases undesirable. To solve for this, various protocols have been proposed which use a static payment address and notifications sent via the blockchain <ref name="out_of_band_notifications">'''Why not use out-of-band notifications''' Out of band notifications (e.g. using something other than the Bitcoin blockchain) have been proposed as a way of addressing the privacy and cost concerns of using the Bitcoin blockchain as a messaging layer. This, however, simply moves the privacy and cost concerns somewhere else and increases the risk of losing money due to a notification not being reliably delivered, or even censored, and makes this notification data critical for backup to recover funds.</ref>. These protocols eliminate the need for interaction, but at the expense of increased costs for one-time payments and a noticeable footprint in the blockchain, potentially revealing metadata about the sender and receiver. Notification schemes also allow the receiver to link all payments from the same sender, compromising sender privacy.

55+Bob publishes a public key ''B'' as a silent payment address. Alice discovers Bob's silent payment address, selects a UTXO with private key ''a'', public key ''A'' and creates a destination output ''P'' for Bob in the following manner:
56+
57+* Let ''P = B + hash(a·B)·G''
58+* Encode ''P'' as a [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341] taproot output
59+
60+Since ''a·B == b·A'' ([https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman Elliptic Curve Diffie-Hellman]), Bob scans with his private key ''b'' by collecting the input public keys for each transaction with at least one unspent taproot output and performing the ECDH calculation until ''P'' is found (e.g. calculating ''P = B + hash(b·A)·G'' and seeing that ''P'' is present in the transaction outputs).

59+
60+Since ''a·B == b·A'' ([https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman Elliptic Curve Diffie-Hellman]), Bob scans with his private key ''b'' by collecting the input public keys for each transaction with at least one unspent taproot output and performing the ECDH calculation until ''P'' is found (e.g. calculating ''P = B + hash(b·A)·G'' and seeing that ''P'' is present in the transaction outputs).
61+
62+''' Creating more than one output '''
63+
64+In order to allow Alice to create more than one output for Bob<ref name="why_more_than_one_output">'''Why allow for more than one output?''' Allowing Alice to break her payment to Bob into multiple amounts opens up a number of privacy improving techniques for Alice, making the transaction look like a CoinJoin or better hiding the change amount by splitting both the payment and change outputs into multiple amounts. It also allows for Alice and Carol to both have their own unique output paying Bob in the event they are in a collaborative transaction and both paying Bob's silent payment address.</ref>, we included an integer in the following manner:

86+
87+Bob must include the same ''outpoint_hash'' when scanning.
88+
89+''' Using all inputs '''
90+
91+In our simplified example we have been referring to Alice's transactions as having only one input ''A'', but in reality a Bitcoin transaction can have many inputs. Instead of requiring Alice to pick a particular input and requiring Bob to check each input separately, we can instead require Alice to perform the tweak with the sum of the input public keys<ref name="other_inputs">'''What about inputs without public keys?''' Inputs without public keys can still be spent in the transaction but are simply ignored in the ''Silent Payments'' protocol.</ref>. This significantly reduces Bob's scanning requirement, makes light client support more feasible<ref name="using_all_inputs">'''How does using all inputs help light clients?''' If Alice uses a random input for the tweak, Bob necessarily has to have access to and check all transaction inputs, which requires performing an ECC multiplication per input. If instead Alice performs the tweak with the sum of the input public keys, Bob only needs the summed 33 byte public key per transaction and only does one ECC multiplication per transaction. Bob can then use BIP158 block filters to determine if any of the outputs exist in a block and thus avoids downloading transactions which don't belong to him. It is still an open question as to how Bob can source the 32 bytes per transaction in a trustless manner, see [[#appendix-a-light-client-support|Appendix A: Light Client Support]] for more details.</ref>, and protects Alice's privacy in collaborative transaction protocols such as CoinJoin<ref name=""all_inputs_and_coinjoin">'''Why does using all inputs matter for CoinJoin?''' If Alice uses a random input to create the output for Bob, this necessarily reveals to Bob which input Alice has control of. If Alice is paying Bob as part of a CoinJoin, this would reveal which input belongs to her, degrading the anonymity set of the CoinJoin and giving Bob more information about Alice. If instead all inputs are used, Bob has no way of knowing which input(s) belong to Alice. This comes at the cost of increased complexity as the CoinJoin participants now need to coordinate to create the silent payment output and would need to use [https://gist.github.com/RubenSomsen/be7a4760dd4596d06963d67baf140406 Blind-Diffie-Hellman] to prevent the other participants from learning who Alice is paying.</ref>.

 96+* Let ''a = a<sub>0</sub> + a<sub>1</sub> … + a<sub>n</sub>''
 97+* Let ''P<sub>0</sub> = B + hash(outpoints_hash·a·B || 0)·G''
 98+
 99+''' Spend and Scan Key '''
100+
101+Since Bob needs his private key ''b'' to check for incoming payments, this requires ''b'' to be exposed to an online device. To minimize the risks involved, Bob can instead publish an address of the form ''(B<sub>scan</sub>, B<sub>spend</sub>)''. This allows Bob to keep ''b<sub>spend</sub>'' in offline cold storage and perform the scanning with the public key ''B<sub>spend</sub>'' and private key ''b<sub>scan</sub>''. Alice performs the tweak using both of Bob's public keys in the following manner:

112+* Publish ''(B<sub>scan</sub>, B<sub>0</sub>)'', ''(B<sub>scan</sub>, B<sub>1</sub>) …''
113+
114+Alice performs the tweak as before using one of the published ''(B<sub>scan</sub>, B<sub>m</sub>)'' pairs. Bob detects the labeled payment in the following manner:
115+
116+* Let ''P<sub>0</sub> = B<sub>spend</sub> + hash(outpoints_hash·b<sub>scan</sub>·A || 0)·G''
117+* Subtract ''P<sub>0</sub>'' from each of the transaction outputs and check if the remainder matches any of the labels (''1·G, 2·G ..'') that the wallet has previously used

133+
134+== Specification ==
135+
136+We use the following functions and conventions:
137+
138+* ''outpoint'' (36 bytes): the <code>COutPoint</code> of an input (32-byte txid, least significant byte first || 4-byte vout, least significant byte first)<ref name="why_little_endian">'''Why are outpoints little-endian?''' Despite using big endian throughout the rest of the BIP, outpoints are sorted and hashed matching their transaction serialization, which is little-endian. This allows a wallet to parse a serialized transaction for use in silent payments without needing to re-order the bytes when compute the outpoint hash. Note: despite outpoints being stored and serialized as little-endian, the transaction hash (txid) is always displayed as big-endian.</ref>

134+== Specification ==
135+
136+We use the following functions and conventions:
137+
138+* ''outpoint'' (36 bytes): the <code>COutPoint</code> of an input (32-byte txid, least significant byte first || 4-byte vout, least significant byte first)<ref name="why_little_endian">'''Why are outpoints little-endian?''' Despite using big endian throughout the rest of the BIP, outpoints are sorted and hashed matching their transaction serialization, which is little-endian. This allows a wallet to parse a serialized transaction for use in silent payments without needing to re-order the bytes when compute the outpoint hash. Note: despite outpoints being stored and serialized as little-endian, the transaction hash (txid) is always displayed as big-endian.</ref>
139+* sort<sub>outpoints</sub>(v): sorts a vector ''v'' of ''outpoints'' in ascending order by doing a byte by byte comparison lexicographically.

143+
144+For everything not defined above, we use the notation from [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#specification BIP340].
145+
146+=== Versions ===
147+
148+This document defines ''Silent Payments v0''. Version is communicated through the address in the same way as Segwit addresses. Future upgrades to silent payments will require a new version. As much as possible, future upgrades should support receiving from older wallets (e.g. a silent payments v0 wallet can send to both v0 and v1 addresses). Any changes that break compatibility with older silent payment versions should be a new BIP.

178+''v31'' (l) is reserved for a backwards incompatible change, if needed. For ''Silent Payments v0'':
179+
180+* If the receiver's silent payment address version is:
181+** ''v0'': check that the data part is exactly 66-bytes. Otherwise, fail
182+** ''v1'' through ''v30'': read the first 66-bytes of the data part and discard the remaining bytes (if any)
183+** ''v31'': fail

180+* If the receiver's silent payment address version is:
181+** ''v0'': check that the data part is exactly 66-bytes. Otherwise, fail
182+** ''v1'' through ''v30'': read the first 66-bytes of the data part and discard the remaining bytes (if any)
183+** ''v31'': fail
184+* Receiver addresses are always [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341] taproot outputs<ref name="why_taproot">'''Why only taproot outputs?''' Providing too much optionality for the protocol makes it difficult to implement and can be at odds with the goal of providing the best privacy. Limiting to taproot outputs helps simplify the implementation significantly while also putting users in the best eventual anonymity set.</ref>
185+* The sender should sign with one of the sighash flags ''DEFAULT, ALL, SINGLE, NONE'' (''ANYONECANPAY'' is unsafe). It is strongly recommended implementations use ''SIGHASH_DEFAULT'' when applicable, or ''SIGHASH_ALL''<ref name="why_sighash_default_or_all">'''Why recommend ''SIGHASH_[DEFAULT|ALL]''?''' Since the output address for the receiver is derived from from the sum of the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' public keys, the inputs must not change once the sender has signed the transaction. If the inputs are allowed to change after the fact, the receiver will not be able to calculate the shared secret needed to find and spend the output. It is currently an open question on how a future version of silent payments could be made to work with new sighash flags such as ''SIGHASH_GROUP'' and ''SIGHASH_ANYPREVOUT''.</ref>

224+=== Outpoints hash ===
225+
226+The sender and receiver MUST calculate an outpoints hash for the transaction in the following manner:
227+
228+* Collect each ''outpoint'' used as an input to the transaction
229+* Sort the outpoints with ''sort<sub>outpoints</sub>(outpoints)''<ref name="why_sort_outpoints">'''Why are outpoints sorted before hashing?''' This way the silent payment otuput does not need to be recalculated if the wallet changes the order of inputs, e.g. at signing time or during an RBF bump.</ref>

237+* ''P2TR''
238+* ''P2WPKH''
239+* ''P2SH-P2WPKH''
240+* ''P2PKH''
241+
242+Inputs with conditional branches or multiple public keys (e.g. ''CHECKMULTISIG'') are not included as this introduces malleability and would allow a sender to re-sign with a different set of public keys after the silent payment output has been derived. This is not a concern when the sender controls all of the inputs, but is an issue for CoinJoins and other collaborative protocols, where a malicious participant can participate in deriving the silent payment address with one set of keys and then re-broadcast the transaction with signatures for a different set of public keys. P2TR can have hidden conditional branches (script path), but we work around this as described below.

290+** For each ''B<sub>m</sub>'' in the group:
291+*** Let ''t<sub>n</sub> = sha256(ser<sub>P</sub>(ecdh_shared_secret) || ser<sub>32</sub>(n))''
292+*** Let ''P<sub>mn</sub> = B<sub>m</sub> + t<sub>n</sub>·G''
293+*** Encode ''P<sub>mn</sub>'' as a [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341] taproot output
294+*** Optionally, repeat with n++ to create additional outputs for the current ''B<sub>m</sub>''
295+*** If no additional outputs are required, continue to the next ''B<sub>m</sub>'' with ''n++''<ref name="why_not_the_same_tn">''' Why not re-use ''t<sub>n</sub>''? when paying different labels to the same receiver?''' If paying the same entity but to two separate labeled addresses in the same transaction without incrementing ''n'', the two outputs would be ''B<sub>spend</sub> + t<sub>n</sub>·G + i·G'' and ''B<sub>spend</sub> + t<sub>n</sub>·G + j·G''. The attacker could subtract the two values and observe that the distance between i and j is small. This would allow them to deduce that this transaction is a silent payment transaction and that a single entity received two outputs, but won't tell them who the entity is.</ref>

323+
324+* Generate the ''outpoints_hash'', using the method described above
325+* Let ''A = A<sub>0</sub> + A<sub>1</sub> + … A<sub>n</sub>'', where each ''A<sub>i</sub>'' is the public key of an input from the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' list
326+* Let ''ecdh_shared_secret = outpoints_hash·b<sub>scan</sub>·A''
327+* Check for outputs:
328+** Let ''outputs_to_check = the taproot output key from each unspent taproot output in the transaction''

339+***** If a match is found:
340+****** Add the ''P<sub>n</sub> + m·G'' to the wallet
341+****** Remove ''output'' from ''outputs_to_check'' and rescan ''outputs_to_check'' with ''n++''
342+***** If the label is not found, negate ''output'' and check again
343+*** If no matches are found, stop
344+

189+
190+A transaction is a ''Silent Payments v0'' transaction and MUST be scanned if and only if all of the following are true:
191+
192+* The transaction contains at least one BIP341 taproot output
193+* The transaction has at least one input from the ''[[#inputs-for-shared-secret-derivation|Inputs For Shared Secret Derivation]]'' list
194+* The transaction does not spend a new, undefined output type (e.g. SegWit versions > 1)<ref name="skip_txs_with_unknown_prevouts">'''Why skip transactions that spend unknown output scripts?''' Skipping transactions that spend unknown output scripts allows us to have a clean upgrade path for Silent Payments by avoiding the need to scan the same transaction multiple times with different rule sets. If a fancy new output type is added in the future and Silent Payments v1 is released with support, we would want to avoid having to first scan the transaction with the silent payment v0 rules and then again with the silent payment v1 rules. Note: this restriction only applies to the inputs of a transaction.</ref>

177+
178+''v31'' (l) is reserved for a backwards incompatible change, if needed. For ''Silent Payments v0'':
179+
180+* If the receiver's silent payment address version is:
181+** ''v0'': check that the data part is exactly 66-bytes. Otherwise, fail
182+** ''v1'' through ''v30'': read the first 66-bytes of the data part and discard the remaining bytes (if any)

344+
345+==== Backup and Recovery ====
346+
347+Since each silent payment output address is derived independently, regular backups are recommended. When recovering from a backup, the wallet will need to scan since the last backup to detect new payments.
348+
349+If using a seed/seed phrase only style backup, the user can recover the wallet's unspent outputs from the UTXO set (i.e. only scanning transactions with at least one unspent taproot output) and can recover the full wallet history by scanning the blockchain starting from the wallet birthday. If a wallet uses labels or generates its change addresses using the change label, this information SHOULD be included in the backup. If the user does not know whether labels or the change label were used, it is strongly recommended they always check for the change label when recovering from backup and precompute a large number of labels (e.g. 100k labels) to use when re-scanning. This ensures that the wallet can recover all funds from only a seed/seed phrase backup.

371+            "outpoints": [<array of tuples, where each tuple represents an outpoint: (txid, vout)>],
372+            "input_priv_keys": [<array of tuples, where each tuple is a hex encoded private key and boolean for taproot: (priv_key, is_taproot)>],
373+            "recipients": [<array of tuples, where each tuple is a bech32m string representing a silent payment address and an float amount: (silent_payment_address, amount)>]
374+        },
375+        "expected": {
376+            "outputs": [<array of key, value objects, where the key is the hex encoding of 32-byte x-only public key and the value an integer amount: {taproot_x_only_key: amount}]

65+
66+* Let ''k = 0''
67+* Let ''P<sub>0</sub> = B + hash(a·B || n)·G''
68+* For additional outputs:
69+** Increment ''k'' by one (''k++'')
70+** Let ''P<sub>i</sub> = B + hash(a·B || n)·G''

82+If Alice were to use a different UTXO from the same public key ''A'' for a subsequent payment to Bob, she would end up deriving the same destination ''P''. To prevent this, Alice should include a hash of the outpoint in the following manner:
83+
84+* Let ''outpoint_hash = hash(txid || vout)''
85+* Let ''P<sub>0</sub> = B + hash(outpoint_hash·a·B || 0)·G''
86+
87+Bob must include the same ''outpoint_hash'' when scanning.

100+
101+Since Bob needs his private key ''b'' to check for incoming payments, this requires ''b'' to be exposed to an online device. To minimize the risks involved, Bob can instead publish an address of the form ''(B<sub>scan</sub>, B<sub>spend</sub>)''. This allows Bob to keep ''b<sub>spend</sub>'' in offline cold storage and perform the scanning with the public key ''B<sub>spend</sub>'' and private key ''b<sub>scan</sub>''. Alice performs the tweak using both of Bob's public keys in the following manner:
102+
103+* Let ''P<sub>0</sub> = B<sub>spend</sub> + hash(outpoints_hash·a·B<sub>scan</sub> || 0)·G''
104+
105+Bob detects this payment by calculating ''P<sub>0</sub> = B<sub>spend</sub> + hash(outpoints_hash·b<sub>scan</sub>·A)·G'' with his online device and can spend from his cold storage signing device using ''(b<sub>spend</sub> + hash(outpoints_hash·b<sub>scan</sub>·A)) mod p'' as the private key.

236+* ''P2TR''
237+* ''P2WPKH''
238+* ''P2SH-P2WPKH''
239+* ''P2PKH''
240+
241+Inputs with conditional branches or multiple public keys (e.g. ''CHECKMULTISIG'') are not included as this introduces malleability and would allow a sender to re-sign with a different set of public keys after the silent payment output has been derived. This is not a concern when the sender controls all of the inputs, but is an issue for CoinJoins and other collaborative protocols, where a malicious participant can participate in deriving the silent payment address with one set of keys and then re-broadcast the transaction with signatures for a different set of public keys. P2TR can have hidden conditional branches (script path), but we work around this by using only the output public key. Note that with the exception of P2TR, all of the above supports [https://bitcoin.stackexchange.com/questions/57855/c-secp256k1-what-do-prefixes-0x06-and-0x07-in-an-uncompressed-public-key-signif hybrid pubkeys].

420+
421+==== Receiving ====
422+
423+* Ensure the public key can be extracted from non-standard ''P2PKH'' scriptSigs
424+* Ensure taproot script path spends are included, using the taproot output key (unless ''H'' is used as the taproot internal key)
425+* Ensure the scanner can extract the public key from each of the input types supported (e.g. ''P2WPKH'', ''P2SH-P2WPKH'', etc)

225+
226+The sender and receiver MUST calculate an outpoints hash for the transaction in the following manner:
227+
228+* Collect each ''outpoint'' used as an input to the transaction
229+* Let ''outpoints = outpoint<sub>0</sub> || ... || outpoint<sub>n</sub>'', sorted lexicographically by txid and vout, ascending order<ref name="why_sort_outpoints">'''Why are outpoints sorted before hashing?''' This way the silent payment output does not need to be recalculated if the wallet changes the order of inputs, e.g. at signing time or during an RBF bump. Note that the silent payment output does need to be recalculated if inputs are added or removed.</ref>
230+* Let ''outpoints_hash = sha256(outpoints)''