These flags can also be set as options in `hush.conf`.
All nodes that generate or validate payment disclosures must run with `txindex=1` enabled.
### Background
Payment Disclosure is an implementation of the work-in-progress Payment Disclosure upstream ZIP [1].
The ZIP describes a method of proving that a payment was sent to a shielded address. In the typical case, this means enabling a sender to present a proof that they transferred funds to a recipient's shielded address.
Alice the customer sends 10 HUSH to Bob the merchant at the shielded address shown on their website. However, Bob is not sure if he received the funds.
Alice's node is running with payment disclosure enabled, so Alice generates a payment disclosure and provides it to Bob, who verifies the payment was made.
If Bob is a bad merchant, Alice can present the payment disclosure to a third party to validate that payment was indeed made.
### Solution
A payment disclosure can be generated for any output of a JoinSplit using the RPC call:
An optional message can be supplied. This could be used for a refund address or some other reference, as currently it is not common practice to (ahead of time) include a refund address in the memo field when making a payment.
To validate a payment disclosure, the following RPC call can be used:
z_validatepaymentdisclosure hexdata
### Example
Generate a payment disclosure for the first joinsplit, second output (index starts from zero):
The `signatureVerified` field confirms that the payment disclosure was generated and signed with the joinSplitPrivKey, which should only be known by the node generating and sending the transaction 7918...652b in question.
### Where is the data stored?
For all nodes, payment disclosure does not touch `wallet.dat` in any way.
For nodes that only validate payment disclosures, no data is stored locally.
For nodes that generate payment disclosures, a LevelDB database is created in the node's datadir. For most users, this would be in the folder:
$HOME/.hush/paymentdisclosure
If you decide you don't want to use payment disclosure, it is safe to shut down your node and delete the database folder.
### Security Properties
Please consult the work-in-progress ZIP for details about the protocol, security properties and caveats.
### Reminder
Feedback is most welcome!
This is an experimental feature so there are no guarantees that the protocol, database format, RPC interface etc. will remain the same in the future.
### Notes
Currently there is no user friendly way to help senders identify which
joinsplit output index maps to a given payment they made. It is possible to
construct this from `debug.log`. Ideas and feedback are most welcome on how to