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

feat: consensus level changes #56

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

soju-drinker
Copy link
Contributor

Closes #26

Copy link
Contributor

@netrome netrome left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great stuff. I just have a few comments. In addition to these I'd also like to see either a few paragraphs or placeholders linked to follow-up tickets for sBTC recovery mode, which is a consensus level change, and the liveness ratio (it's part of consensus right?).


If 2/3rd of the Stackers agree that the block is valid, they sign off on this block, at which point this block is added to the blockchain and becomes the new tip. All blocks have to build on top of it. Thus, unless the network is compromised, Stacks guarantees a single block (soft) finality from the *Nakamoto* release. This makes sBTC fulfillment a much more dependable and reliable process for users of the protocol.

Moreover, because Stacks no longer forks, sBTC can be treated like any other SIP-10 token and mined and used quickly on Stacks without the need to wait for Bitcoin confirmations.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is still possible even in the presence of forks, although the absence of forks makes withdrawals much faster because we can fulfill withdrawals directly.


Moreover, because Stacks no longer forks, sBTC can be treated like any other SIP-10 token and mined and used quickly on Stacks without the need to wait for Bitcoin confirmations.

sBTC is also not really affected by short lived Bitcoin forks as the protocol already ensures that there are sufficient number of Bitcoin block confirmations before being fulfilled that it is almost guaranteed that they will never be orphaned by the time they are picked up by a block producer set. As such, sBTC is not speculatively instantiated or destroyed and can only materialize or dematerialize once its deposit and withdraw transactions are sufficiently confirmed, and is completely independent of Stacks recovery mechanism from soft Bitcoin forks.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not really true afaik. Stacks forks with bitcoin as I understand it, so any sBTC operation in a short lived fork on Bitcoin would materialize on the equivalent Stacks fork. Therefore, Stacks doesn't even have to wait for many block confirmations to materialize an sBTC deposit. As soon as it's mined on Bitcoin, the sBTC can (and will) be minted on Stacks. And as soon as sBTC is burned on Stacks it is safe to initiate a withdrawal fulfillment on Bitcoin.

@friedger
Copy link
Collaborator

@soju-drinker Do you plan to update thie PR?

@friedger friedger changed the base branch from master to main October 27, 2023 20:47
@CLAassistant
Copy link

CLAassistant commented Nov 16, 2023

CLA assistant check
All committers have signed the CLA.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Document sBTC Consensus updates
4 participants