Skip to content
This repository was archived by the owner on Dec 4, 2024. It is now read-only.

Conversation

setzeus
Copy link

@setzeus setzeus commented Aug 13, 2023

Below are notes for the upcoming PoX-4 updates & all the user-types & life-cycles involved with the changes.

Specifically this PR includes a detailed overlook into which users call which functions during the five following windows:

  1. Disbursement
  2. Registration
  3. Vote
  4. Transfer
  5. Penalty

A tiny amount of details are undefined / up for change as this is what we currently believe will fold into PoX-4, we've yet to finalize & sign-off on that design.

@setzeus setzeus linked an issue Aug 13, 2023 that may be closed by this pull request
@CLAassistant
Copy link

CLAassistant commented Aug 13, 2023

CLA assistant check
All committers have signed the CLA.

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.

Sorry to butcher this review. I think we're learning how much we don't know about Nakamoto PoX. I suggest that we're brushing up these docs and moving them as a sub-section of the 0.1 release docs instead of here as part of the final release. We can then collaborate more closely to document how the 1.0 contracts will look.

The PoX contract, PoX-4, is the crux of stacking & therefore the general consensus between Bitcoin & Stacks. Miners on Bitcoin mine STX blocks by sending Bitcoin to a weighted lottery every block; on the Stacks side, users can "stack" their STX, every two weeks, for receive a part of the Bitcoin mining rewards.

TODO: [#9](https://github.com/stacks-network/sbtc-docs/issues/9)
The fourth version of this, PoX-4, introduces the logic necessary for a decentralized two-way Bitcoin-peg (sBTC). Specifically, it introduces the mechanics necessary for stackers to now evolve into signers: instead of stacking & passively receiving mining rewards, signers are now incentivized to help process (by signing) peg-ins(deposits), peg-outs(withdraws) & peg-transfers (handoffs).
Copy link
Contributor

Choose a reason for hiding this comment

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

The fourth version of this, PoX-4, introduces the logic necessary for a decentralized two-way Bitcoin-peg (sBTC).

This feels a bit detached from the rest of the docs. We have already introduced sBTC here. I'd suggest something in the spirit of: "sBTC introduced the the forth version of PoX. In PoX-4 we introduce mechanics necessary for...".

Comment on lines +29 to +30
**Disbursement [x]**
The disbursement window is the first window yet also acts as the final window of the **previous** cycle. This is when the PoX rewards from the *previous* cycle are disbursed to the previous signers. Since these rewards are disbursed in Bitcoin, someone [either Observer or any of the Signer user types] needs to verify the disbursements on Stacks.
Copy link
Contributor

Choose a reason for hiding this comment

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

I believe we won't have a disbursement window in Nakamoto, as opposed to the developer release. Instead, PoX rewards are on a consensus level distributed to the signers directly as part of the block production operations.

Comment on lines +32 to +33
Observer -> (penalty-pox-reward-disbursement ...)
Observer -> (prove-rewards-were-disbursed ...)
Copy link
Contributor

Choose a reason for hiding this comment

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

Could this be a mermaid chart?

Observer -> (prove-rewards-were-disbursed ...)

**Registration [1600 - x blocks]**
Once disbursement has been proven on Stacks, the registration window opens (it's worth noting that this is the only window with a dynamic start height). This is the window when either pre-registered signers or current signers register to be a signer for the next cycle.
Copy link
Contributor

Choose a reason for hiding this comment

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

We need to figure out how registration connects with the Nakamoto consensus rules. I assume this is also different in 1.0 as opposed to 0.1.

Comment on lines +1 to +5
# The sBTC Token
The sBTC Token is defined as a [SIP-010 fungible token contract](https://github.com/stacksgov/sips/blob/main/sips/sip-010/sip-010-fungible-token-standard.md).

Content for this page:
- Tokenomics: How many tokens can be minted? Who can mint and burn the token?
Copy link
Contributor

Choose a reason for hiding this comment

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

We can save this page as a follow-up, alternatively reformulate it. We need to work this in with the rest of the documentation.

@friedger
Copy link
Contributor

Is this still valid? This PR feels stale.

@friedger friedger changed the base branch from master to main October 27, 2023 20:48
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Document the sBTC PoX Contract

4 participants