Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable supply auditing by storing cryptographic commitments #101

Open
Tracked by #80
HalosGhost opened this issue May 11, 2022 · 0 comments · May be fixed by #262 or #102
Open
Tracked by #80

Enable supply auditing by storing cryptographic commitments #101

HalosGhost opened this issue May 11, 2022 · 0 comments · May be fixed by #262 or #102
Assignees

Comments

@HalosGhost
Copy link
Collaborator

HalosGhost commented May 11, 2022

UHS IDs, being opaque hashes, do not reveal enough information for the system to audit the amount of currency in-circulation.

Similar to #100, we could modify the underlying data structure of the UHS to be a map rather than a set, storing additional data on the value-side of each key-value pair. However, storing plaintext values both weakens privacy guarantees in the system (now core components are aware of the denominations of each note/coin), and makes the UHS far more valuable a target for analysis. To avoid such a negative outcome, we can store Pedersen commitments to each coin's value along with a bp++ range-proof guaranteeing that the value falls in some allowable range. By slightly modifying the UHS ID calculation (very similarly to #100), we make it possible for shards to verify that the UHS ID corresponds to its associated Pedersen commitment and range-proof without requiring the storage of the transaction graph.

Because the monetary supply only includes outstanding funds, and because a Pedersen commitment sum can only reveal whether or not a set of commitments have balanced values and blinding factors, the auditor (to complete an audit) must be able to craft a commitment to the total value (and blinding factor) expected to be in-circulation. Trivially, $value_{expected}$ must equal $value_{minted} - value_{redeemed}$, and so the transaction processor must track minted and redeemed values. Presumably, it could do the same with blinding factors of minted and redeemed coins, but if all minting operations set the blinding factor of their commitments to $0$, then no additional information must be tracked.1

One additional consideration must be accounted for: when creating a transaction, clients must ensure the blinding factors on the input and output side of the transaction are balanced (mirroring the auditing equivalence). To address this, all output blinding factors (save the last) should be rolled randomly, as normal. Then, the blinding factor of the final output should be set to the difference of the sum of all input blinding factors less the sum of all other output blinding factors:
$$r_n^{out} = \sum_{i=1}^{m} r_i^{in} - \sum_{i=1}^{n-1} r_i^{out}$$

Sentinels can now reuse the same audit routine as the auditor for transaction-balance verification (scoped to a single transaction, with no need to provide an additional commitment, as the transaction should specifically be balanced). So, we are free to remove the plaintext value from each output in a full transaction.

Not only does this design enable auditing of the monetary supply without revealing and storing additional sensitive data in the UHS, but it enables fully confidential transactions, reducing the amount of data revealed to the sentinels!

Footnotes

  1. there is potentially an additional benefit here in that receivers of minting transactions can open the values of other minted outputs (making minting a semi-public operation, enabling greater visibility and verifiability); but this is trivially avoidable by the system operator, if-desired, by only minting to internally-controlled wallets, and then spending them to the intended recipients.

@HalosGhost HalosGhost self-assigned this May 11, 2022
@HalosGhost HalosGhost changed the title Enable supply auditing by modifying UHS IDs to be cryptographic commitments to value Enable supply auditing by storing cryptographic commitments May 30, 2024
@HalosGhost HalosGhost linked a pull request May 30, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant