Payment disclosures were never implemented in Sapling by ZEC, only in Sprout as an experimental feature. They may be useful for various reasons in Sapling zaddrs.
This issue will track how Hush may implement Sapling payment disclosures.
Payment disclosures were never implemented in Sapling by ZEC, only in Sprout as an experimental feature. They may be useful for various reasons in Sapling zaddrs.
This issue will track how Hush may implement Sapling payment disclosures.
https://github.com/bitcartel/zips/blob/9d0ff728d900d8dbb1c7e36cfcda72e411a98c80/drafts/bitcartel-payment-disclosure/draft.rst
https://github.com/zcash/zips/pull/119/files
https://github.com/zcash/zcash/blob/master/doc/payment-disclosure.md
Sprout zaddrs had many many design flaws which made payment disclosures leak metadata and have various "bad features". Since Sapling fixed these things, those problems will not affect Sapling PDs.
Both plaintext outputs of a Sprout JoinSplit are currently encrypted with symmetric keys derived from the same ephemeral secret key - this was fixed in Sapling.
When sending from a transparent address to shielded addresses, each shielded address will occupy one output of a JoinSplit. Thus a payment address to a different recipient could be revealed. - this will not happen in Sapling PDs
When sending involves chained JoinSplits, for each JoinSplit, one output is for payment to a recipient's address, while the other output is used as change back to the sender. Thus the change address will be revealed, which is the sender's own shielded address. - this will not happen in Sapling PDs
Sprout zaddrs had many many design flaws which made payment disclosures leak metadata and have various "bad features". Since Sapling fixed these things, those problems will not affect Sapling PDs.
`Both plaintext outputs of a Sprout JoinSplit are currently encrypted with symmetric keys derived from the same ephemeral secret key` - this was fixed in Sapling.
`When sending from a transparent address to shielded addresses, each shielded address will occupy one output of a JoinSplit. Thus a payment address to a different recipient could be revealed.` - this will not happen in Sapling PDs
`When sending involves chained JoinSplits, for each JoinSplit, one output is for payment to a recipient's address, while the other output is used as change back to the sender. Thus the change address will be revealed, which is the sender's own shielded address.` - this will not happen in Sapling PDs
Payment disclosures were never implemented in Sapling by ZEC, only in Sprout as an experimental feature. They may be useful for various reasons in Sapling zaddrs.
This issue will track how Hush may implement Sapling payment disclosures.
9d0ff728d9/drafts/bitcartel-payment-disclosure/draft.rsthttps://github.com/zcash/zips/pull/119/files
https://github.com/zcash/zcash/blob/master/doc/payment-disclosure.md
Sprout zaddrs had many many design flaws which made payment disclosures leak metadata and have various "bad features". Since Sapling fixed these things, those problems will not affect Sapling PDs.
Both plaintext outputs of a Sprout JoinSplit are currently encrypted with symmetric keys derived from the same ephemeral secret key- this was fixed in Sapling.When sending from a transparent address to shielded addresses, each shielded address will occupy one output of a JoinSplit. Thus a payment address to a different recipient could be revealed.- this will not happen in Sapling PDsWhen sending involves chained JoinSplits, for each JoinSplit, one output is for payment to a recipient's address, while the other output is used as change back to the sender. Thus the change address will be revealed, which is the sender's own shielded address.- this will not happen in Sapling PDs