From bc34dc088aa5b55be006b221a58c1c169adfff41 Mon Sep 17 00:00:00 2001 From: Aaron Blankstein <235161024+aaronb-stacks@users.noreply.github.com> Date: Wed, 15 Oct 2025 20:18:07 +0000 Subject: [PATCH 1/9] initial sip-033 rider --- sips/sip-033a/sip-033a.md | 86 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 86 insertions(+) create mode 100644 sips/sip-033a/sip-033a.md diff --git a/sips/sip-033a/sip-033a.md b/sips/sip-033a/sip-033a.md new file mode 100644 index 000000000..b8c11f015 --- /dev/null +++ b/sips/sip-033a/sip-033a.md @@ -0,0 +1,86 @@ +# Preamble + +SIP Number: 033-a + +Title: Dimension specific tenure extend variants + +Author(s): + +- Aaron Blankstein + +Status: Draft + +Consideration: Technical + +Type: Consensus + +Layer: Consensus (hard fork) + +Created: 2025-10-15 + +License: CC0-1.0 + +# Abstract + +This SIP details a rider to SIP-033, including a new variant of the tenure change +control transaction. This variant allows the tenure change to specify a specific +dimension of the block budget to reset. + +# Copyright + +This SIP is made available under the terms of the CC0 (Creative Commons Zero) +license, available at https://opensource.org/licenses/CC0-1.0. This SIP’s +copyright is held by the Stacks Open Internet Foundation. + +# Introduction + +The Stacks network controls total runtime and I/O expenditure during nakamoto tenures +via a total tenure budget. Costs are tracked using worst-case estimates of the actual +runtime or I/O expended to evaluate a given Clarity operation. In Nakamoto rules, +signers and miners may coordinate to include a tenure change payload which extends +the current tenure and resets the block limits for the tenure. + +This mechanism allows the tenure budget to be reset if, e.g., there has been a long +delay between bitcoin blocks. However, if the assessed Clarity costs are much higher +than the actual runtime or I/O characteristics of the executed blocks (i.e., the actual +block runtime is much faster than the worst-case scenario around which costs are modeled), +signers and miners have limited ability to address this. This is because a mismatch in one +dimension (e.g., read-count) should not result in another dimension being reset (e.g., write-count). +Resetting all dimensions of the block budget when only one was misaligned would open the +network up to denial of service (unintentional or otherwise). + +To address these concerns, this SIP proposes to add a new variant to tenure change payloads which +allows them to specify **which** dimension should be reset (or all of them). + +# Protocol Specification + +The serialization of the TenureChangePayload will be a backwards-compatible extension of +the existing SIP-021 serialization: + +``` +tenure consensus hash: 20 bytes +previous tenure consensus hash: 20 bytes +burn view consensus hash: 20 bytes +previous tenure end: 32 bytes +previous tenure blocks: 4 bytes, big-endian +cause: 1 byte +pubkey hash 20 bytes +``` + +The cause field serializes the new variant in a backwards compatible scheme: + +``` +0x00 indicates NewBlockFound whole budget is reset +0x01 indicates Extend whole budget is reset. +0x02 indicates Extend read-count budget is reset. +0x03 indicates Extend runtime budget is reset. +0x04 indicates Extend read-length budget is reset. +0x05 indicates Extend write-count budget is reset. +0x06 indicates Extend write-length budget is reset. +``` + +# Activation + +This is intended as a rider SIP to SIP-033. If voting on this SIP is +approved *and* voting on SIP-033 is approved, this SIP will activate with +SIP-033. From 88656f15da66163e7c073950e213170cc0590597 Mon Sep 17 00:00:00 2001 From: Jude Nelson Date: Wed, 15 Oct 2025 21:39:29 -0400 Subject: [PATCH 2/9] chore: add Related Work and some formatting --- sips/sip-033a/sip-033a.md | 86 ------------------------ sips/sip-034/sip-034.md | 138 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 138 insertions(+), 86 deletions(-) delete mode 100644 sips/sip-033a/sip-033a.md create mode 100644 sips/sip-034/sip-034.md diff --git a/sips/sip-033a/sip-033a.md b/sips/sip-033a/sip-033a.md deleted file mode 100644 index b8c11f015..000000000 --- a/sips/sip-033a/sip-033a.md +++ /dev/null @@ -1,86 +0,0 @@ -# Preamble - -SIP Number: 033-a - -Title: Dimension specific tenure extend variants - -Author(s): - -- Aaron Blankstein - -Status: Draft - -Consideration: Technical - -Type: Consensus - -Layer: Consensus (hard fork) - -Created: 2025-10-15 - -License: CC0-1.0 - -# Abstract - -This SIP details a rider to SIP-033, including a new variant of the tenure change -control transaction. This variant allows the tenure change to specify a specific -dimension of the block budget to reset. - -# Copyright - -This SIP is made available under the terms of the CC0 (Creative Commons Zero) -license, available at https://opensource.org/licenses/CC0-1.0. This SIP’s -copyright is held by the Stacks Open Internet Foundation. - -# Introduction - -The Stacks network controls total runtime and I/O expenditure during nakamoto tenures -via a total tenure budget. Costs are tracked using worst-case estimates of the actual -runtime or I/O expended to evaluate a given Clarity operation. In Nakamoto rules, -signers and miners may coordinate to include a tenure change payload which extends -the current tenure and resets the block limits for the tenure. - -This mechanism allows the tenure budget to be reset if, e.g., there has been a long -delay between bitcoin blocks. However, if the assessed Clarity costs are much higher -than the actual runtime or I/O characteristics of the executed blocks (i.e., the actual -block runtime is much faster than the worst-case scenario around which costs are modeled), -signers and miners have limited ability to address this. This is because a mismatch in one -dimension (e.g., read-count) should not result in another dimension being reset (e.g., write-count). -Resetting all dimensions of the block budget when only one was misaligned would open the -network up to denial of service (unintentional or otherwise). - -To address these concerns, this SIP proposes to add a new variant to tenure change payloads which -allows them to specify **which** dimension should be reset (or all of them). - -# Protocol Specification - -The serialization of the TenureChangePayload will be a backwards-compatible extension of -the existing SIP-021 serialization: - -``` -tenure consensus hash: 20 bytes -previous tenure consensus hash: 20 bytes -burn view consensus hash: 20 bytes -previous tenure end: 32 bytes -previous tenure blocks: 4 bytes, big-endian -cause: 1 byte -pubkey hash 20 bytes -``` - -The cause field serializes the new variant in a backwards compatible scheme: - -``` -0x00 indicates NewBlockFound whole budget is reset -0x01 indicates Extend whole budget is reset. -0x02 indicates Extend read-count budget is reset. -0x03 indicates Extend runtime budget is reset. -0x04 indicates Extend read-length budget is reset. -0x05 indicates Extend write-count budget is reset. -0x06 indicates Extend write-length budget is reset. -``` - -# Activation - -This is intended as a rider SIP to SIP-033. If voting on this SIP is -approved *and* voting on SIP-033 is approved, this SIP will activate with -SIP-033. diff --git a/sips/sip-034/sip-034.md b/sips/sip-034/sip-034.md new file mode 100644 index 000000000..e311cfc99 --- /dev/null +++ b/sips/sip-034/sip-034.md @@ -0,0 +1,138 @@ +# Preamble + +SIP Number: 034 + +Title: Dimension specific tenure extend variants + +Author(s): + +- Aaron Blankstein +- Jude Nelson + +Status: Draft + +Consideration: Technical + +Type: Consensus + +Layer: Consensus (hard fork) + +Created: 2025-10-15 + +License: CC0-1.0 + +# Abstract + +This SIP details a rider to SIP-033, including a new variant of the tenure change +control transaction. This variant allows the tenure change to specify a specific +dimension of the block budget to reset. + +# Copyright + +This SIP is made available under the terms of the CC0 (Creative Commons Zero) +license, available at https://opensource.org/licenses/CC0-1.0. This SIP’s +copyright is held by the Stacks Open Internet Foundation. + +# Introduction + +The Stacks network controls total runtime and I/O expenditure during Nakamoto tenures +via a total tenure budget. Costs are tracked using worst-case estimates of the actual +runtime or I/O expended to evaluate a given Clarity operation. In Nakamoto rules, +signers and miners may coordinate to include a `TenureChange` transaction in the miner's +next block which extends the current tenure by resetting the counters for its ongoing +runtime and I/O costs. + +This mechanism allows the tenure's overall budget to grow, for example, there has been a long +delay between Bitcoin blocks. However, if the assessed Clarity costs are much higher +than the actual runtime or I/O characteristics of the executed blocks (i.e., the actual +block runtime is much faster than the worst-case scenario around which costs are modeled), +signers and miners have limited ability to address this. This is because a mismatch in one +dimension (e.g., read-count) should not result in another dimension being reset (e.g., write-count). +Resetting all dimensions of the block budget when only one was misaligned would open the +network up to denial of service (unintentional or otherwise). + +To address these concerns, this SIP proposes to add a new variant to `TenureChange` transactions +which allows them to specify **which** cost dimension should be reset (or all of them). + +# Specification + +The serialization of the `TenureChangePayload` will be a backwards-compatible extension of +the existing SIP-021 serialization: + +``` +tenure consensus hash: 20 bytes +previous tenure consensus hash: 20 bytes +burn view consensus hash: 20 bytes +previous tenure end: 32 bytes +previous tenure blocks: 4 bytes, big-endian +cause: 1 byte +pubkey hash 20 bytes +``` + +The `cause` field serializes the new variant in a backwards compatible scheme: + +``` +0x00 indicates NewBlockFound whole budget is reset +0x01 indicates Extend whole budget is reset. +0x02 indicates Extend read-count budget is reset. +0x03 indicates Extend runtime budget is reset. +0x04 indicates Extend read-length budget is reset. +0x05 indicates Extend write-count budget is reset. +0x06 indicates Extend write-length budget is reset. +``` + +# Related Work + +The Stacks blockchain measures a transaction's resource expenditures along five +dimensions: the number or indexed reads ("read count"), the number of bytes +read ("read length"), the number of indexed writes ("write count"), the number +of bytes written ("write length"), and the amount of CPU used ("runtime"). Each +miner is granted a budget of each measured resource to consume over the duration +of their tenure. Each Clarity operation consumes one or more of these +resources. A Nakamoto block is only valid if the additional resources its +transactions consume do not exceed the tenure's limits on each of these +resources. + +The cost measurements for each Clarity operation were chosen to +ensure that a Stacks node would be able to reprocess the tenure much more +quickly than it is produced. If this were not the case, then Stacks nodes would +be unable to catch up to the chain tip. This is particularly dangerous for +Stacks signers, which may go offline for mundane reasons; signers must be able +to quickly catch up to the rest of the signer network. + +An alternative approach considered to this SIP was to produce a more accurate +measurement of how much of each resource each Clarity operation consumes. The +current model is pessimistic, and assumes a worst-case resource consumption. It +also does not consider the size of the _value_ of the data being processed; it +instead consideres the _worst-case size_ allowed by the data's _type_. +We believe that the approach in this SIP is superior building a more accurate +model (but does not negate a new model's usefulness) because it allows +signers to determine whether or not to allocate more resources to an ongoing +tenure based on their real-world observation of resource consumption when +evaluating block proposals. As long as the signers observe that resource +consumption in each dimension is below an acceptable threshold, such that a +crashed signer could quickly catch back up, then the signers can safely extend +individual resource budgets regardless of the current model's pessimism +This in turn allows signers to grow the chain's tenure budgets in response +to acquiring better harder, or running upgraded nodes with better +block-processing algorithms. + +A future SIP may increase the granularity of tenure extensions. For example, +the signers may be able to choose the amount of each resource to extend. +This SIP does not call for this in order to speed its implementation. +Furthermore, signers have the option to enforce a more granular resource +consumption rate without a hard fork -- they announce to miners their target +resource consumption rates, and reject miner blocks that consume resources at +higher rate than their target rate. + +# Backwards Compatibility + +Per the Specification section above, the wire formats for `TenureChange` +transactions are backwards compatible with the existing wire format. All that +has been added are new values to represent the kind of tenure extension +requested. + +# Activation + +This is intended as a rider SIP to SIP-033. If SIP-033 is ratified, then this +SIP will also be ratified. From dd5997d159e778c021f5728f64bd74e60efe74ad Mon Sep 17 00:00:00 2001 From: Jude Nelson Date: Wed, 15 Oct 2025 21:45:45 -0400 Subject: [PATCH 3/9] chore: formatting --- sips/sip-034/sip-034.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-034/sip-034.md b/sips/sip-034/sip-034.md index e311cfc99..dc3565cca 100644 --- a/sips/sip-034/sip-034.md +++ b/sips/sip-034/sip-034.md @@ -2,7 +2,7 @@ SIP Number: 034 -Title: Dimension specific tenure extend variants +Title: Dimension-Specific Tenure Extend Variants Author(s): From 4177324808148221fe36a24626d76d1df2adab87 Mon Sep 17 00:00:00 2001 From: Jude Nelson Date: Wed, 15 Oct 2025 21:49:03 -0400 Subject: [PATCH 4/9] chore: add governance consideration --- sips/sip-034/sip-034.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sips/sip-034/sip-034.md b/sips/sip-034/sip-034.md index dc3565cca..d73408fa2 100644 --- a/sips/sip-034/sip-034.md +++ b/sips/sip-034/sip-034.md @@ -11,7 +11,7 @@ Author(s): Status: Draft -Consideration: Technical +Consideration: Technical, Governance Type: Consensus From 97719e1f54d3c2190185fee90dba9ac176c4ba87 Mon Sep 17 00:00:00 2001 From: Jude Nelson Date: Fri, 17 Oct 2025 01:09:27 -0400 Subject: [PATCH 5/9] chore: address SIP feedback --- sips/sip-034/sip-034.md | 48 ++++++++++++++++++++++++++++++++++++++--- 1 file changed, 45 insertions(+), 3 deletions(-) diff --git a/sips/sip-034/sip-034.md b/sips/sip-034/sip-034.md index d73408fa2..434080084 100644 --- a/sips/sip-034/sip-034.md +++ b/sips/sip-034/sip-034.md @@ -21,6 +21,10 @@ Created: 2025-10-15 License: CC0-1.0 +Discussions-To: +* SIP pull request: https://github.com/stacksgov/sips/pull/236 +* SIP reference implementation: https://github.com/stacks-network/stacks-core/pull/6609 + # Abstract This SIP details a rider to SIP-033, including a new variant of the tenure change @@ -56,6 +60,8 @@ which allows them to specify **which** cost dimension should be reset (or all of # Specification +## Wire Formats + The serialization of the `TenureChangePayload` will be a backwards-compatible extension of the existing SIP-021 serialization: @@ -72,15 +78,51 @@ pubkey hash 20 bytes The `cause` field serializes the new variant in a backwards compatible scheme: ``` -0x00 indicates NewBlockFound whole budget is reset +0x00 indicates NewBlockFound whole budget is reset. 0x01 indicates Extend whole budget is reset. 0x02 indicates Extend read-count budget is reset. -0x03 indicates Extend runtime budget is reset. -0x04 indicates Extend read-length budget is reset. +0x03 indicates Extend read-length budget is reset. +0x04 indicates Extend runtime budget is reset. 0x05 indicates Extend write-count budget is reset. 0x06 indicates Extend write-length budget is reset. ``` +Values `0x00` and `0x01` are used today to indicate whether or not the +`TenureChangePayload` represents a change to a new tenure or the extension +of the ongoing tenure. No other values are accepted today. +This SIP proposes accepting values `0x02` through `0x06` for `cause`, and taking +the above actions to reset a specific cost dimension's budget. + +## Coordination Between Miners and Signers + +This SIP only requires Stacks nodes to accept dimension-specific tenure budget +resets via these new `TenureChangePayload` transaction payloads. It does +not mandate a strategy for coordinating with miners to determine when +dimension-specific resets might be granted. However, a brief description of how +this might be achieved is provided here, for informational purposes. + +In the reference implementation today, signers determine how often a miner can +submit a tenure-extension transaction based on how much "idle time" each signer has +observed in its node. This is the amount of time the node spends doing work +besides processing block proposals. Signers individually choose an amount of +idle time that must pass on their node before they will approve a tenure +extension. By choosing larger idle times, signers ensure that the chain does +not grow so quickly that it prevents miners and signers from catching up to and +staying at the chain tip. Signers advertize the earliest UNIX epoch time at +which they will accept a tenure extension as part of their block proposal +acknowledgements to the miner. + +This behavior is not consensus-critical, and is outside the scope of this SIP, +but is worth mentioning because it informs how future coordination between miners +and signers could work. Signers may adopt similar notions of idle time for each +budget dimension in order to determine when they will accept a +dimension-specific tenure budget reset. For example, a signer may measure +the amount of time the node spends _not_ performing read I/O on the chainstate database +("read I/O idle time") to determine when they will issue a read-count reset. + +This SIP does not require a coordination strategy to be implemented before its +activation. + # Related Work The Stacks blockchain measures a transaction's resource expenditures along five From cb1b7aaac42a102d6a5baa1c291cdc500a04ef97 Mon Sep 17 00:00:00 2001 From: Brice Dobry Date: Fri, 17 Oct 2025 15:56:30 -0400 Subject: [PATCH 6/9] Technical CAB approval for SIP-034 --- .../technical-cab/2025-10-17-sip-034.md | 57 +++++++++++++++++++ sips/sip-034/sip-034.md | 3 + 2 files changed, 60 insertions(+) create mode 100644 considerations/minutes/technical-cab/2025-10-17-sip-034.md diff --git a/considerations/minutes/technical-cab/2025-10-17-sip-034.md b/considerations/minutes/technical-cab/2025-10-17-sip-034.md new file mode 100644 index 000000000..7baa43da9 --- /dev/null +++ b/considerations/minutes/technical-cab/2025-10-17-sip-034.md @@ -0,0 +1,57 @@ +# Technical CAB Minutes + +## Meeting Information + +**Location:** Discord (async) + +**Recorded:** No + +**Date:** + +- Oct 17th, 2025 + +**Time:** n/a + +**Attendees:** + +- Aaron Blankstein +- Brice Dobry +- j2p2 +- Friedger +- Radu +- Setzeus + +**Topic(s):** + +- [SIP-034: Dimension-Specific Tenure Extend Variants](https://github.com/stacksgov/sips/pull/236) + +**Materials**: + +- [SIP-034: Dimension-Specific Tenure Extend Variants](https://github.com/stacksgov/sips/pull/236) +- [Reference implementation](https://github.com/stacks-network/stacks-core/pull/6609) + +## 2025-10-15 Meeting Notes + +Note: This vote was urgently needed to ensure it can proceed together with +SIP-033. The current chair, Jesse Wiley, is unavailable for this vote, so Brice +Dobry is acting chair for this vote. + +The Technical CAB reviewed SIP-034 and the supporting materials, and concluded +that this change is necessary to support the ecosystem. + +## Vote Outcome(s) + +| Name | Vote | +| ---------------- | ------- | +| Aaron Blankstein | abstain | +| Brice Dobry | yes | +| Friedger | yes | +| j2p2 | yes | +| Setzeus | yes | +| Radu | yes | + +_Note_ Aaron Blankstein is the author of SIP-034, as such he abstained from +voting. + +The Technical CAB approves SIP-034 with 5 yes votes and 1 abstention by the +author. diff --git a/sips/sip-034/sip-034.md b/sips/sip-034/sip-034.md index 434080084..c0676628d 100644 --- a/sips/sip-034/sip-034.md +++ b/sips/sip-034/sip-034.md @@ -21,6 +21,9 @@ Created: 2025-10-15 License: CC0-1.0 +Sign-off: +- Brice Dobry , Acting Chair, Technical CAB + Discussions-To: * SIP pull request: https://github.com/stacksgov/sips/pull/236 * SIP reference implementation: https://github.com/stacks-network/stacks-core/pull/6609 From 991ef2a963082610990a09c5313d993a93a7930a Mon Sep 17 00:00:00 2001 From: Jason Schrader Date: Fri, 17 Oct 2025 22:42:00 -0700 Subject: [PATCH 7/9] docs: add gov cab sign-off to sip-034 --- sips/sip-034/sip-034.md | 1 + 1 file changed, 1 insertion(+) diff --git a/sips/sip-034/sip-034.md b/sips/sip-034/sip-034.md index c0676628d..61f7a4e80 100644 --- a/sips/sip-034/sip-034.md +++ b/sips/sip-034/sip-034.md @@ -23,6 +23,7 @@ License: CC0-1.0 Sign-off: - Brice Dobry , Acting Chair, Technical CAB +- Jason Schrader , Chairperson, Governance CAB Discussions-To: * SIP pull request: https://github.com/stacksgov/sips/pull/236 From 6ae99ba2dacf01861081878283aa3cd4c041f30f Mon Sep 17 00:00:00 2001 From: Jude Nelson Date: Tue, 21 Oct 2025 13:02:32 -0400 Subject: [PATCH 8/9] chore: add sign-offs and advance to actiation-in-progress --- sips/sip-034/sip-034.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/sips/sip-034/sip-034.md b/sips/sip-034/sip-034.md index 434080084..5c24949d4 100644 --- a/sips/sip-034/sip-034.md +++ b/sips/sip-034/sip-034.md @@ -9,7 +9,7 @@ Author(s): - Aaron Blankstein - Jude Nelson -Status: Draft +Status: Activation-in-Progress Consideration: Technical, Governance @@ -25,6 +25,10 @@ Discussions-To: * SIP pull request: https://github.com/stacksgov/sips/pull/236 * SIP reference implementation: https://github.com/stacks-network/stacks-core/pull/6609 +Sign-offs: +* Technical CAB: https://github.com/stacksgov/sips/blob/feat/sip034/considerations/minutes/technical-cab/2025-10-17-sip-034.md +* Governance CAB: https://github.com/stacksgov/sips/blob/main/considerations/minutes/governance-cab/2025-10-17-sip-034.md + # Abstract This SIP details a rider to SIP-033, including a new variant of the tenure change From 8821768123ae92864604314f1a44e83019b20c6f Mon Sep 17 00:00:00 2001 From: Jude Nelson Date: Fri, 24 Oct 2025 11:03:27 -0400 Subject: [PATCH 9/9] chore: address SIP editor feedback --- sips/sip-034/sip-034.md | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/sips/sip-034/sip-034.md b/sips/sip-034/sip-034.md index f25bf0ddb..0edce818a 100644 --- a/sips/sip-034/sip-034.md +++ b/sips/sip-034/sip-034.md @@ -36,7 +36,7 @@ Sign-offs: # Abstract This SIP details a rider to SIP-033, including a new variant of the tenure change -control transaction. This variant allows the tenure change to specify a specific +control transaction. This variant allows the tenure change to specify which dimension of the block budget to reset. # Copyright @@ -48,7 +48,7 @@ copyright is held by the Stacks Open Internet Foundation. # Introduction The Stacks network controls total runtime and I/O expenditure during Nakamoto tenures -via a total tenure budget. Costs are tracked using worst-case estimates of the actual +via a total tenure budget [1]. Costs are tracked using worst-case estimates of the actual runtime or I/O expended to evaluate a given Clarity operation. In Nakamoto rules, signers and miners may coordinate to include a `TenureChange` transaction in the miner's next block which extends the current tenure by resetting the counters for its ongoing @@ -71,7 +71,7 @@ which allows them to specify **which** cost dimension should be reset (or all of ## Wire Formats The serialization of the `TenureChangePayload` will be a backwards-compatible extension of -the existing SIP-021 serialization: +the existing SIP-021 serialization [2]: ``` tenure consensus hash: 20 bytes @@ -154,7 +154,7 @@ An alternative approach considered to this SIP was to produce a more accurate measurement of how much of each resource each Clarity operation consumes. The current model is pessimistic, and assumes a worst-case resource consumption. It also does not consider the size of the _value_ of the data being processed; it -instead consideres the _worst-case size_ allowed by the data's _type_. +instead considers the _worst-case size_ allowed by the data's _type_. We believe that the approach in this SIP is superior building a more accurate model (but does not negate a new model's usefulness) because it allows signers to determine whether or not to allocate more resources to an ongoing @@ -184,5 +184,16 @@ requested. # Activation -This is intended as a rider SIP to SIP-033. If SIP-033 is ratified, then this -SIP will also be ratified. +This is intended as a rider SIP to SIP-033 [3]. If SIP-033 is ratified, then this +SIP will also be ratified. Similarly, if SIP-033 is not ratified, then this SIP +will not be ratified. No further criteria are needed for this SIP. + +# Reference Implementation + +This SIP's implementation is written in Rust, and is available here: https://github.com/stacks-network/stacks-core/pull/6609 + +# References + +[1] https://github.com/stacksgov/sips/blob/main/sips/sip-021/sip-021-nakamoto.md#nakamoto-terminology +[2] https://github.com/stacksgov/sips/blob/main/sips/sip-021/sip-021-nakamoto.md#block-structure +[3] https://github.com/obycode/sips/blob/feat/clarity-4/sips/sip-033/sip-033-clarity4.md