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

Add consensus-level support for commit-reveal #73

Open
netrome opened this issue Aug 16, 2023 · 6 comments
Open

Add consensus-level support for commit-reveal #73

netrome opened this issue Aug 16, 2023 · 6 comments
Assignees
Labels

Comments

@netrome
Copy link
Contributor

netrome commented Aug 16, 2023

Context

The current design supports commit-reveal operations as an alternative method of constructing sBTC operations. To use commit-reveal, a user or application is dependent on a trusted entity to act as a revealer - which is the entity consuming the commit transaction and constructing the reveal transaction visible to the sBTC system (and anyone else observing the chain).

While anyone can act as a revealer, we anticipate that there will be low interest in community-provided revealers. Therefore, we'd like to add consensus-level support for commit-reveal, to ensure that sBTC comes with a solution for applications to leverage the commit-reveal protocol.

Definition of done

The sBTC consensus rules are updated to ensure there's always a reliable revealer available.

@netrome netrome added the draft label Aug 16, 2023
@FriendsFerdinand
Copy link
Contributor

@netrome I would like to know what the added complexity for doing this would be.

@netrome
Copy link
Contributor Author

netrome commented Aug 22, 2023

The added complexity for supporting commit-reveal on a consensus level is pretty big. The main challenge is defining exactly how the revealer API should be integrated in the stacks nodes (or PoX contract) and integrate the reveal functionality with the signers. Beyond this, we need to figure out how to enforce revealing on a consensus level, which is somewhat tricky since any ignored commit output will just look like an arbitrary p2tr output.

@FriendsFerdinand
Copy link
Contributor

So, for reference, RSK uses the first input in the peg-in transaction to generate the address on RSK that will receive the rBTC.

For sBTC, I was thinking of having a Stacks smart contract that stores the P2TR outputs that have the sBTC format. The Stacks contract call required to store this information can be done by anyone. Then, when it's time to rotate the wallet, signers can claim this UTXO with all the other peg-in UTXOs

@netrome
Copy link
Contributor Author

netrome commented Aug 23, 2023

Yeah using smart contract calls for submitting reveal data makes sense. I don't see any other way to later enforce it at a consensus level.

@netrome
Copy link
Contributor Author

netrome commented Aug 31, 2023

@MarvinJanssen is looking into commit-reveal from a Clarity perspective right now. Hopefully we can figure out a good initial design, document it and include it in the sBTC DR 0.2 targeting end of October - depending on the complexity of the resulting design.

@netrome netrome removed the draft label Aug 31, 2023
Copy link

stale bot commented Mar 17, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Mar 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants