-
Notifications
You must be signed in to change notification settings - Fork 201
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 via cryptographic commitments and proofs #102
Draft
HalosGhost
wants to merge
40
commits into
mit-dci:trunk
Choose a base branch
from
HalosGhost:tamper-detection/crypto
base: trunk
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
HalosGhost
force-pushed
the
tamper-detection/crypto
branch
3 times, most recently
from
May 20, 2022 22:40
176bb29
to
820cbde
Compare
HalosGhost
force-pushed
the
tamper-detection/crypto
branch
from
June 6, 2022 16:23
820cbde
to
ea6735a
Compare
HalosGhost
force-pushed
the
tamper-detection/crypto
branch
2 times, most recently
from
June 30, 2022 20:11
6eb1669
to
b38f027
Compare
HalosGhost
force-pushed
the
tamper-detection/crypto
branch
2 times, most recently
from
July 11, 2022 20:33
3d82bd3
to
06f4716
Compare
HalosGhost
force-pushed
the
tamper-detection/crypto
branch
2 times, most recently
from
September 29, 2022 21:45
39496ff
to
b533068
Compare
HalosGhost
force-pushed
the
tamper-detection/crypto
branch
from
October 24, 2022 18:14
f75149b
to
3c6a4c3
Compare
Switching to a fork allows us to leverage bulletproofs Signed-off-by: Sam Stuewe <[email protected]>
Includes creating commitments directly as well as a facility for automatically creating an “xonly” Pedersen Commitment. xonly Pedersen Commitments are a work-around to avoid a larger code- delta for this solution. In particular, it will allow us to avoid changing the size of a UHS ID. Signed-off-by: Sam Stuewe <[email protected]>
These data structures will be integrated into transactions and leveraged to implement confidential transactions. Signed-off-by: Sam Stuewe <[email protected]>
This implementation is mostly cribbed from what we already have for std::unordered_map and is added only because it will be easier for us to leverage in some places. Signed-off-by: Sam Stuewe <[email protected]>
This is separated only so it doesn't muddy review of the other, more substantial commits. Signed-off-by: Sam Stuewe <[email protected]>
Signed-off-by: Sam Stuewe <[email protected]>
This method allows for the easy creation of valid blinding factors (and the associated auxiliary Pedersen Commitments) for new outputs to be created in a transaction. Using this helper ensures that the auxiliary commitments in a non-minting transaction will sum to 0, and those in a minting- transaction will equal G^{minted_value}. Signed-off-by: Sam Stuewe <[email protected]>
Only one is exposed as its easiest to use in most circumstances, but the others can be exposed in the future if-needed (exposing them for use shouldn't have any negative side-effects). Signed-off-by: Sam Stuewe <[email protected]>
This is the largest commit in the series by-far; however, it's not immediately clear to me how it could be broken down further and leave the code functional (passing all tests) at each commit. Included in this commit: * Redefine `input`s and `output`s to contain all the proofs * Modify `full_tx` and `compact_tx` to include the necessary proofs * Add routines for creating and verifying all proof criteria * Store the proofs in the UHS (both architectures) * Modify clients and sentinels to actually prove and verify * Update all tests for the new structures * Remove a few tests which are now not possible cases * Add tests for basic round-tripping of storage through the UHS Signed-off-by: Sam Stuewe <[email protected]>
Co-authored-by: Sam Stuewe <[email protected]> Signed-off-by: davidmag854 <[email protected]> Signed-off-by: Sam Stuewe <[email protected]>
Signed-off-by: Sam Stuewe <[email protected]>
Signed-off-by: Sam Stuewe <[email protected]>
Rather than try to use a pedersen commitment as a UHS ID, prefer a nested hash (almost identical to the values-in-UHS solution). This simplifies a lot of the prove/verify procedures, reduces the amount of code we need overall and makes the security argument much simpler (because the transaction format is now largely unchanged). Signed-off-by: Sam Stuewe <[email protected]>
Signed-off-by: James Lovejoy <[email protected]>
…atomizer integration tests Signed-off-by: James Lovejoy <[email protected]> Signed-off-by: Sam Stuewe <[email protected]>
Signed-off-by: Sam Stuewe <[email protected]>
Includes: * Pull in newest secp-zkp changes * Fix a doxygen doc-comment problem * remove a potentially-problematic header include Signed-off-by: Sam Stuewe <[email protected]>
Signed-off-by: Sam Stuewe <[email protected]>
Signed-off-by: Sam Stuewe <[email protected]>
Signed-off-by: Sam Stuewe <[email protected]>
Signed-off-by: Sam Stuewe <[email protected]>
In the atomizer load-generator, several timestamps were not initialized; their first use was with `operator+=`. This simply initializes them to 0 making that first use valid. Signed-off-by: Sam Stuewe <[email protected]>
Includes * fixing all tests (locally, at least) * correctly checking transaction balancing Signed-off-by: Sam Stuewe <[email protected]>
Signed-off-by: Sam Stuewe <[email protected]>
Signed-off-by: Alexander Jung <[email protected]>
Signed-off-by: Alexander Jung <[email protected]>
…eeded_transaction Signed-off-by: Alexander Jung <[email protected]>
Signed-off-by: Alexander Jung <[email protected]>
Signed-off-by: Alexander Jung <[email protected]>
Signed-off-by: Alexander Jung <[email protected]>
… changes Signed-off-by: Alexander Jung <[email protected]> Set dummy rangeproof for outputs for unit tests where needed Signed-off-by: Alexander Jung <[email protected]>
Signed-off-by: Alexander Jung <[email protected]>
Signed-off-by: Sam Stuewe <[email protected]>
Also includes modifying twophase mode's transaction-creation to reuse pedersen-commitments/range-proofs Signed-off-by: Sam Stuewe <[email protected]>
Signed-off-by: Sam Stuewe <[email protected]>
HalosGhost
force-pushed
the
tamper-detection/crypto
branch
from
July 6, 2023 18:48
3c6a4c3
to
c3ea8e1
Compare
Signed-off-by: Sam Stuewe <[email protected]>
Signed-off-by: Sam Stuewe <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the initial run of implementing minimal tamper detection via cryptographic commitments. There is still more work to-do (hence the draft status), but it's in a place where people can probably start digging in and offering some feedback.
No benchmarking has been done yet, but the most likely potential cause of slow-down comes from the size of the data that now needs to be transmitted. In particular, each output has an “uncompressed” rangeproof (around 4KiB). There's already a path available to reduce that size dramatically (seems like it should be possible to get the rangeproofs down to <1k total for effectively all transactions), but I haven't yet looked into tackling that problem.
Closes #101