SIP-012: Burn height selection for network-upgrade to introduce new cost-limits #41
Conversation
Add specifics for bitcoin vote op, proposed changes
|
Also cc/ @xanbots |
|
Looking awesome. Do we reckon we can get it from 3 weeks down to 2 weeks? |
|
@diwakergupta is there any particular reason to increase cost of |
|
Big fan of this SIP! Question about static vs. dynamic costs. |
|
|
||
| ### Changes to Static vs. Dynamic Tabulation of Costs | ||
|
|
||
| The cost assessment in Clarity for most data-handling functions (e.g., |
There was a problem hiding this comment.
"Most", or "all"? If it's "most," then please list them all. Also, "data-handling functions" is not the text we've used to label these; we'd call these "functions that interact with the contract's data space."
There was a problem hiding this comment.
Does this also apply to NFTs?
There was a problem hiding this comment.
Per @kantai, this also applies to NFTs and will be done in the next-costs branch of stacks-blockchain.
… the case when a pool uses its pox address to vote for its pool participants
…nd delegating.json
…nto draft/sip-012
|
On the community telegram users are asking when 2.05 will go live. What is the (expected) 'activation block height' for sip012? I think this text will be updated with the 'activation block height' once it is settled, right? |
|
@314159265359879 I suggested #711975, but have had no answer (stacks-network/stacks-core#2878 (comment)) |
|
2.05 not yet and I should see the "tabulation date": ctrl+f (searching for) "tabulation date": 0 mentions. Maybe someone else knows where to find it. |
|
Was referring to this: https://github.com/stacksgov/sips/pull/41/files#diff-30158688704ec09920309bbc5a856f6b5b2fa55cc91f59191c5b517406c61b20R151-R156. The text calls it the "vote deadline block." |
|
Okay folks, I spoke again with the authors, and now that the implementation of this SIP is nearly finished, they've proposed activating this officially at Bitcoin block 713,000. The rationale is as follows:
In a similar vein, the vote deadline block will be the height of the first Bitcoin block mined after 12:00pm EST on November 23. The SIP text will be updated to reflect this block height once it is known. Sounds good? The final decision will be made at the public blockchain meeting this coming Monday (November 15) at 11am EST. If you'd like to debate this further, please come to this meeting or leave feedback here over the weekend (so we can discuss it at the meeting if you're unable to attend). |
|
Sounds good!
On Fri, Nov 12, 2021 at 6:39 PM Jude Nelson ***@***.***> wrote:
Okay folks, I spoke again with the authors, and now that the
implementation of this SIP is nearly finished, they've proposed activating
this officially at *Bitcoin block 713,000*. The rationale is as follows:
- It's in the *middle* of a reward cycle (so the upgrade won't mess
with PoX if it breaks).
- It's early in the work week -- likely Tuesday, December 7 (so the
folks who need to be on-call to fix it if it breaks will be available).
- It gives ample time to verify that the testnet can undergo this hard
fork without breaking the network or any downstream services.
- It's the earliest such block height with these properties that is
later than November 29, which was the targeted deadline. November 29 is
approximately when cycle 22's prepare phase begins; December 7 is in the
middle of cycle 22.
In a similar vein, the *vote deadline block* will be the height of the
first Bitcoin block mined after *12:00pm EST on November 23*. The SIP
text will be updated to reflect this block height once it is known.
Sounds good? The final decision will be made at the public blockchain
meeting this coming Monday (November 15) at 11am EST.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#41 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABUXGBDQ3QFWAPTBRP6Z7ILULWQRXANCNFSM5F73MMJQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
--
Sent from my iPhone
|
|
GG |
|
Just had the public blockchain engineering meeting, and there were no objections. 713,000 it is. |
Update cost constants
…vation block height, advance to Recommended status
|
All right, folks -- it's vote ratification day! Bitcoin block 710,001 was the first block mined after 12pm EST, so we're gonna go with the votes that got in before it was mined. My totals from the scripts in this PR are as follows:
I realize that these do not match sip012.xyz, and I'm happy to discuss it more, but that doesn't matter too much because the activation threshold has been cleared. SIP 012 will officially transition to activation-in-progress. In the mean time, a release candidate of the Stacks 2.05 node can be found here: https://github.com/blockstack/stacks-blockchain/releases/tag/2.05.0.0.0-rc1. It is backwards-compatible with Stacks 2.0 chainstate, so if you want to download and run it to try it out, please feel free to do so. See you all on the other side of Bitcoin block 713,000! |
|
Alright folks, release 2.05.0.0.0 is out! Release: https://github.com/blockstack/stacks-blockchain/releases/tag/2.05.0.0.0 |
| num_locked = $7 | ||
| until = $16 |
There was a problem hiding this comment.
The success of this function appears to be tied directly to the token quantity and ordering found inside debug log output, which looks brittle and a source of future bugs – if/when someone edits the upstream debug message, not realizing the downstream implications here. So, add some sanity checks before proceeding to use "num_locked" and "until" values?
There was a problem hiding this comment.
All of the stacking records for the vote have been extracted and stored as supplementary materials to this SIP, so there's not much of a concern here. This script is meant mainly to explain how the votes were extracted at the time they were extracted.
Highly subject to change, but is required for some notification channels
Adding an estimated block production time
|
SIP 012 has officially activated! Congratulations everyone! Merging this in. |
The current Clarity cost limits were set very conservatively in Stacks 2.0: transactions with contract-calls frequently exceed these limits, which negatively affects transaction throughput. This SIP proposes an update to these cost-limits via a network upgrade and further, that the network upgrade be executed at a block height chosen by an off-chain process described in this SIP.