Nakamoto SIP: Economic CAB Review Summary

Hey Stackers, I am a core developer and the writer of the Nakamoto SIP who took the draft Nakamoto SIP into the final iterations that are being voted on. This post will summarize several conversations driven by the Economic CAB’s review.

I want to thank each member of the CAB for their thorough review and productive discourse, we were able to sort out their concerns and add some further clarity to the SIP that benefits everyone. Fundamentally, there are no major design changes recommended, but I’ve outlined some important tweaks and clarifications that are being added to the SIP.

These are the initial concerns raised by the Economics CAB around the Nakamoto SIP:

  • Bitcoin Finality
    • Concern: Finality isn’t reached after two Stacks blocks.
    • Resolution: Finality is actually reached after two tenure changes, corresponding to two Bitcoin blocks. The design accounts for this, no changes needed.
  • Orphaning on Bitcoin Hurts Finality
    • Concern: Orphaning on the Bitcoin blockchain prevents Nakamoto from achieving Bitcoin level finality.
    • Resolution: The finality of Stacks transactions after the Nakamoto release have the same finality as transactions on the Bitcoin Blockchain. As expected, reorganizing in the Bitcoin blockchain has the same impact on the Stacks blockchain. The design accounts for this, no changes needed.
  • Miner transaction replay
    • Concern: Transaction replay from orphaned tenures is required for the Nakamoto fast blocks to be useful.
    • Resolution: Interactions with the community suggest that this isn’t the case, but replay behavior on the miner side isn’t a consensus level change. Replay is an open feature that can be shipped without a SIP, and therefore shouldn’t be included in SIP-021. No changes needed. A Github issue was created to track the effort of including the replay. This is a feature that we expect to be shipped soon after the initial release of Nakamoto. stacks-core#4313
  • Signer liveness enforcement
    • Concern: The SIP should actively enforce Signers to remain live via stacked STX slashing.
    • Resolution: The SIP already includes a mechanism for halting PoX payouts for Signers that don’t remain live. Instead of increasing the penalty, the SIP is changed to have a more stringent threshold for maintaining PoX payouts; the Stacker must have signed for at least n of the last m blocks to continue receiving PoX payouts, where determining n and m are part of the activation criteria of the SIP.

Next up: These clarifications are being added to the SIP, after which the Economics CAB has said they are comfortable approving it. You can see those updates in the draft SIP here: https://github.com/stacksgov/sips/pull/155

Again, many thanks to the Economics CAB for their review, the more community feedback the better!

Thanks,
Ashton

7 Likes

Thanks for your leadership on this, Ashton! I’m glad to see the CAB’s resolutions added to the SIP.

2 Likes

Thank you for openly sharing this concise summary. It’s greatly appreciated.

1 Like

Thanks for the update Ashton. I’m sure the rest of Stacks ecosystem really appreciate it as well. And thanks to Economic CAB’s input.
Once all 3 CABs have made their approval I will do a summary blog/post from governance & SIP process perspective to summarize it all for the community. <3

1 Like