bip376: unify Silent Payment protocol mentions in document

Author: nymius

bip-0376.mediawiki

@@ -18,15 +18,15 @@
 
 === Abstract ===
 
-This document proposes additional per input fields for BIP 370 PSBTv2 that allows BIP 352 silent payment tweaks to be included in a PSBT of version 2. These fields will be relevant to Silent Payment outputs spending.
+This document proposes additional per input fields for BIP 370 PSBTv2 that allows BIP 352 Silent Payment tweaks to be included in a PSBT of version 2. These fields will be relevant to Silent Payment outputs spending.
 
 === Motivation ===
 
-BIP 352 specify the silent payments protocol, which provides a new way to create P2TR outputs and spend them.
+BIP 352 specify the Silent Payment protocol, which provides a new way to create P2TR outputs and spend them.
 
-The existing PSBT fields are unable to support silent payments without changes, due to the new method by which outputs are created.
+The existing PSBT fields are unable to support Silent Payment without changes, due to the new method by which outputs are created.
 
-BIP 375 and complementary BIP 374 specify how to create outputs locked with silent payment keys using PSBTs. But they don't specify how to unlock these outputs in a transaction.<ref name="why_not_adding_this_field_in_bip_375">''' Why not including this new field in BIP 375?''' Historically, Silent Payments have been categorized by the perspective of the user of the protocol: receiver or sender. BIP 375 has followed this convention, and its stated on its title: Sending Silent Payments with PSBTs. Given that spending belongs to the sphere of the receiver, and considering this convention, this specification should be a different BIP.</ref>
+BIP 375 and complementary BIP 374 specify how to create outputs locked with Silent Payment keys using PSBTs. But they don't specify how to unlock these outputs in a transaction.<ref name="why_not_adding_this_field_in_bip_375">''' Why not including this new field in BIP 375?''' Historically, Silent Payment has been categorized by the perspective of the user of the protocol: receiver or sender. BIP 375 has followed this convention, and its stated on its title: Sending Silent Payments with PSBTs. Given that spending belongs to the sphere of the receiver, and considering this convention, this specification should be a different BIP.</ref>
 
 Therefore new fields must be defined to allow PSBTs to carry the information necessary for tweaking taproot keys without following the BIP 341 tagging scheme.
 
@@ -81,15 +81,15 @@ where ''hash<sub>BIP0352/Label</sub>(ser<sub>256</sub>(b<sub>scan</sub>) || ser<
 
 == Rationale ==
 
-On PSBTs, when spending non silent payment outputs, one can rely on the <tt>PSBT_IN_BIP32_DERIVATION</tt> or any of the allowed <tt>PSBT_IN_TAP_*</tt> combinations available to get the right private keys to sign for each input.
+On PSBTs, when spending non Silent Payment outputs, one can rely on the <tt>PSBT_IN_BIP32_DERIVATION</tt> or any of the allowed <tt>PSBT_IN_TAP_*</tt> combinations available to get the right private keys to sign for each input.
 
-To spend silent payment outputs you have to combine the private key with the tweak obtained from the transaction corpus.
+To spend Silent Payment outputs you have to combine the private key with the tweak obtained from the transaction corpus.
 
 Passing the prevouts together with the PSBT to allow the computation of the tweaks, forces more computation on the signer side.
 
-Once a silent payment UTXO is scanned, is easier to store the output together with the tweak that generated it.
+Once a Silent Payment UTXO is scanned, is easier to store the output together with the tweak that generated it.
 
-To avoid the burden on the signer it would be better to pass this data into the PSBT together with the input spending the silent payment. Currently, there is no field prescribed for this. 
+To avoid the burden on the signer it would be better to pass this data into the PSBT together with the input spending the Silent Payment output. Currently, there is no field prescribed for this.
 
 The use of proprietary fields is possible but brittle, as one may end up having to perform extra lookups for keys that are not unified across implementations.