-
Notifications
You must be signed in to change notification settings - Fork 219
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
feat: add more burn details to burn command #5169
feat: add more burn details to burn command #5169
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code itself looks fine, but I have some questions regarding the use case of the ownership proof for burned UTXOs.
I do not know the exact use case details of the ownership proof, so in lieu thereof:
- If the "static" ownership proof (a
CommitmentSignature
) is leaked anyone can claim ownership afterwards, even the challenging party. - An ownership proof produced on the fly will be much more convincing. The challenging party can send a public nonce
Rc
they generated, and the owner can produce theCommitmentSignature
including the challengee = Hash(C || Rc)
.
This looks good, but I agree with @hansieodendaal, here. For the proofs to be convincing we need to either make them interactive, or we need Fiat–Shamir heuristic that's derived from the context you are using it. For example in the context of the second layer, we need to include in the challenge the shard of the second layer funds that was created from the burn tx. As it stands here anyone can reuse this proof and claim ownership. |
I thought about what goes into the challenge on the second layer. At the time of burn, if it is something that ties it to the time of claiming on the second layer, it will not be possible to create the signature. The other option is to return the private key to the commitment, to allow the second layer claimant to create the signature themselves. It felt a bit weird to return the private key, but I suppose we could encrypt it somehow |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good. Please see the comment below.
Co-authored-by: Hansie Odendaal <39146854+hansieodendaal@users.noreply.github.com>
# Conflicts: # base_layer/wallet/src/lib.rs # base_layer/wallet/src/transaction_service/service.rs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - can merge after minor compile errors and clippys are fixed
* development: Docker fix - provenance (tari-project#5190)
⚠ BREAKING CHANGES * add key commitment to database main key AEAD (5188) Features * add key commitment to database main key AEAD ([5188](#5188)) ([95bc795](95bc795)) * add more burn details to burn command ([5169](#5169)) ([e417e57](e417e57)) * print out warning if wallet grpc connections fails ([5195](#5195)) ([4e1cb38](4e1cb38)) Bug Fixes * add missing consensus constants to get_constants grpc ([5183](#5183)) ([9900d5d](9900d5d))
Description
Add burn fields to the GRPC method of burning
Motivation and Context
When claiming funds on the second layer, you will need a few proofs to claim them. This allows the wallet to provide them
How Has This Been Tested?
CI