Spend transaction claims

[AaronFeickert]

This PR is an initial draft of a design for spend transaction claims.

A claim is a proof against an existing spend transaction that asserts the prover knew the spend key used to authorize the transaction. It also binds an arbitrary message into the proof, which can be useful to avoid replay. It has the same structure as a ChaumProof, which is how it is internally represented (but it uses domain separation to ensure it can't be replayed for transaction authorization).

How this should be structured in the codebase is up for debate. Because a claim is structured like a Chaum authorizing proof, it uses the same ChaumProof data structure and serialization. It is generated and verified using the static SpendTransaction::proveClaim and SpendTransaction::verifyClaim functions.

The prover must provide the spend transaction, the (secret) input coin data representing the coins that were consumed in the spend transaction, its full view and spend keys, an arbitrary message, and an identifier that the verifier can use to obtain its own view of the spend transaction.

The verifier must provide the proof, spend transaction, arbitrary message, and identifier. It is very important that the verifier use its own view of the spend transaction! Otherwise, the prover could lie about its contents.

Once the prover produces the ChaumProof data structure representing the claim, it should be sent to the verifier in a serialized package containing:

• the ChaumProof
• the spend transaction identifier
• the arbitrary message

The verifier then uses its view of the ledger to look up the spend transaction using the identifier. It checks that the message is as expected. Then, it verifies the claim by checking the ChaumProof while binding in the identifier and message.

Summary by CodeRabbit

• New Features
  • Expanded the libspark library to include functionality for creating, proving, and verifying claims in cryptographic protocols.
  • Introduced new capabilities in spend transactions to generate and verify claims, enhancing security and control over transaction claims.

[AaronFeickert]

It's likely a better idea to create a ClaimProof class that handles the (de)serialization.

[levonpetrosyan93]

Looks good to me,
Please add unittests too.

[AaronFeickert]

Added basic tests.

[reubenyap]

@coderabbitai review

[coderabbitai]

Important

Auto Review Skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Walkthrough

The recent updates introduce a new Claim class within the libspark library, enhancing its cryptographic protocol capabilities. This class is pivotal for creating, proving, and verifying claims, particularly in the context of spend transactions. It encapsulates the necessary functionality for handling claims, including challenge generation, claim proof creation, and proof verification. These changes are spread across the Makefile, libspark, and test files, indicating a comprehensive integration of the new claim processing features.

Changes

Files	Change Summaries
src/Makefile.am	Added claim.h and claim.cpp to libspark sources.
src/libspark/claim.cpp, claim.h	Introduced Claim class for creating, proving, and verifying claims.
src/libspark/spend_transaction.cpp, spend_transaction.h	Added proveClaim and verifyClaim methods to SpendTransaction class for claim processing.
src/libspark/test/spend_transaction_test.cpp	Enhanced testing for claim generation and verification in spend transactions.
src/libspark/util.h	Added LABEL_TRANSCRIPT_CLAIM constant.

🐰✨
In the realm of code, where the bits align,
A new class emerges, its design so fine.
With claims to prove, and proofs to verify,
The libspark library, now soaring high.
Through tests and transactions, it weaves its tale,
A cryptographic journey, where none shall fail.
🌟🐾

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share

• X
• Mastodon
• Reddit
• LinkedIn

Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai generate interesting stats about this repository and render them as a table.
  • @coderabbitai show all the console.log statements in this repository.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

Review Status

Actionable comments generated: 2

Configuration used: CodeRabbit UI

Commits

Files that changed from the base of the PR and between 0f9d27d and c716d69.

Files selected for processing (7)

• src/Makefile.am (1 hunks)
• src/libspark/claim.cpp (1 hunks)
• src/libspark/claim.h (1 hunks)
• src/libspark/spend_transaction.cpp (1 hunks)
• src/libspark/spend_transaction.h (2 hunks)
• src/libspark/test/spend_transaction_test.cpp (1 hunks)
• src/libspark/util.h (1 hunks)

Files skipped from review due to trivial changes (1)

• src/libspark/util.h

Additional comments: 16

src/libspark/claim.h (4)

• 4-5: Including secp256k1/include/MultiExponent.h directly might not be the best practice, especially if it's part of an external library. Consider whether this include is necessary in the header file or if it could be moved to the implementation file (claim.cpp) to reduce coupling and improve compilation times.
• 9-48: The Claim class is well-structured and encapsulates the functionality related to spend transaction claims. However, it's important to ensure that the documentation is thorough, especially for public methods like prove and verify. These methods perform critical operations, and detailed comments explaining the parameters, the process, and any side effects or requirements would greatly enhance maintainability and clarity.
• 25-31: The verify method's signature is cleaner than prove, but it still takes multiple parameters. Consistency in how data is passed (e.g., using structs for grouped data) between prove and verify could improve the API's usability. Additionally, ensure that the method's purpose and the significance of each parameter are well-documented.
• 34-43: The challenge method is private and serves as a utility function for generating challenges based on various inputs. It's good practice to keep such utility functions private to encapsulate the class's internal logic. However, ensure that there's sufficient internal documentation explaining the challenge generation process, as it's a critical part of the cryptographic operations.

src/libspark/spend_transaction.h (3)

• 10-10: Including claim.h in spend_transaction.h is necessary for the new claim-related functionality. Ensure that any dependencies introduced by this inclusion are managed appropriately, and consider forward declarations if the full class definition is not needed in all cases where spend_transaction.h is included.
• 64-65: The proveClaim and verifyClaim methods are static, which is appropriate given their utility nature and the fact that they don't need to modify any instance state. However, ensure that the decision to make these methods static is consistent with the overall design philosophy of the SpendTransaction class and doesn't limit future extensibility.
• 64-65: The method signatures for proveClaim and verifyClaim are clear and concise. However, given the complexity of the operations they perform, detailed documentation explaining each parameter, the method's purpose, and any side effects or requirements would be beneficial for maintainability and clarity.

src/libspark/test/spend_transaction_test.cpp (1)

• 133-175: The test case generate_verify effectively demonstrates the process of generating and verifying claims, including negative test scenarios where verification should fail. This is crucial for ensuring the robustness of the claim functionality. However, consider adding more detailed comments explaining each step of the process and the expected outcomes, especially for the negative test scenarios. This will improve the readability and maintainability of the test code.

src/libspark/claim.cpp (2)

• 57-88: The implementation of the prove method demonstrates a thorough approach to generating the proof. However, the use of randomization within this method introduces unpredictability that should be carefully managed, especially in a cryptographic context. Ensure that the source of randomness is secure and appropriate for the cryptographic operations being performed.
• 91-182: The verify method's implementation is complex, involving multiple steps and calculations. While the method appears to be correctly implemented, consider adding more internal documentation to explain the verification process in detail, including the purpose of each calculation and how it contributes to the overall verification. This will greatly aid in understanding and maintaining the code.

src/libspark/spend_transaction.cpp (5)

• 483-495: The input validation in proveClaim method ensures that the input coin data corresponds to the prover statement data from the spend transaction. This is crucial for the integrity of the claim generation process. However, consider adding more detailed error messages to distinguish between different types of input data mismatches. This can improve the debugging experience and make it easier for developers to identify the exact cause of an error.
• 507-519: In the proveClaim method, the binding hash computation is a critical step that ensures the claim is securely bound to the spend transaction's data. The method correctly computes the binding hash by incorporating various elements of the transaction. However, it's important to ensure that all elements involved in the hash computation are immutable and correctly represent the transaction's state to prevent any potential vulnerabilities.
• 522-538: The claim production step in the proveClaim method correctly utilizes the Claim class to generate the claim. It's important to ensure that the Claim class is thoroughly tested, especially the prove method, to guarantee the security and correctness of the claim generation process. Consider adding more comprehensive tests covering various edge cases and potential error conditions.
• 556-568: The binding hash computation in the verifyClaim method is consistent with the proveClaim method, ensuring that the verification process matches the claim generation process. This consistency is crucial for the security and integrity of the claim verification. Ensure that any changes to the hash computation in proveClaim are mirrored in verifyClaim to maintain this consistency.
• 571-583: The claim verification step in the verifyClaim method correctly utilizes the Claim class to verify the claim against the spend transaction's data. It's important to ensure that the Claim class's verify method is robust and secure, as it plays a critical role in the claim verification process. Consider reviewing the implementation of the Claim class and its verify method for potential improvements in security and efficiency.

src/Makefile.am (1)

• 679-680: The addition of claim.h and claim.cpp to the libspark sources is correctly implemented. This ensures that the new functionality related to spend transaction claims will be compiled and linked as part of the libspark library. It's important to verify that these files are located in the correct directory (libspark) and that any dependencies they have are also included in the build process if necessary.

[coderabbitai]

The prove method takes a significant number of parameters, which might indicate that the method is doing too much or that some of these parameters could be encapsulated into a higher-level object. Consider whether some of these parameters are related closely enough to be grouped into a struct or class to simplify the method signature and improve code readability.

[coderabbitai]

The prove method includes checks for the validity of the statement being proven. This is a good practice for ensuring the integrity of the input data. However, consider extracting these checks into a separate method to improve code readability and maintainability. Additionally, ensure that error messages provided in exceptions are descriptive enough to help diagnose issues.