SIP-012: Burn height selection for network-upgrade to introduce new cost-limits

[diwakergupta]

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.

[kantai]

Interesting. Do we have the distribution of contract-call / stx-transfer, on this last 3500 blocks? Would a pre-dominant number of stx-transfer (non impacted by the new costs) be dilluting the estimated gains?

We can obtain that distribution, but it wouldn't impact the results above. Native stx-transfer operations don't count towards the execution limit of the block: they only count towards the block's size limit.

One thing that makes me suspect the above is an under estimate is that the large reduction in runtime usage will make it much easier for miners to "pack" blocks. The current packing is very inefficient -- the roughly 1500 blocks worth of execution was packed into 3500 blocks. The read count of transactions is much more normal of a distribution than the current runtime cost, so miners would be able to pack better, meaning that in practice, miners are likely to get closer to full blocks.

[Zk2u]

this is really interesting, @kantai

in the future, would we possibly look into expanding the read/write count limits? how does it affect performance/hardware requirements compared to something like the runtime costs?

[jcnelson]

EDIT: the original text has been updated to reflect a bug in my script -- I hadn't been counting votes from smart contracts. I see that SP2C2YFP12AJZB4MABJBAJ55XECVS7E4PMMZ89YZR.arkadiko-stacker-v1-1 Stacked 12622260119595 uSTX. The number is still off; I've updated my tally below.

@aulneau I'm getting a significantly different tally from sip012.xyz -- I'm seeing ~55,106,338.740645~ 67,728,598.860240 votes for "yes".

Here are my methods.

First, I'm seeing 23 "yes" votes for SIP 012, just as sip012.xyz reports. Because SIP 012 permits Stackers to vote with either their PoX address or their STX address keys, we'll compute both addresses from the first scriptSig of each vote transaction:

btc	stx
34tAUWPXnde8tWC8DYrF9BVhybdkv4y6fo	SMHG85TDP5THD0Y1SBWJ0GY3N4XSKJ31PA7SYP1E
32f2jrLCkngfqaLjg2xXJ6uWQH9YV2ULZB	SM59FYC7V0T3M4M06FDXCT7E8E62ZHQ7A3RNEGWX
1EsgJoqwcfbWsSyz6VHCYBvnh1iGrWB7dY	SP2C2YFP12AJZB4MABJBAJ55XECVS7E4PMMZ89YZR
3MuLXCkM3CfU8hNjsAXLvdMjH3L5UtDW8g	SM3EVE20X43VSYX8ZBZRDVTMGP59QG50K343BR3WT
3HASeAxLLZQJTbGDTSyfxbJXLtnUF8K1Dw	SM2MVKG24XVY6JVH2R827EJJV1AJX11EAV3QSQ4M7
3LPFQKGN8BqoDDY5v7btYMZPDmQwEjLaWr	SM36GW9VNJG3Y0A0J210AMT39AA6CZ5Z8T0SHWFG0
31zf6GfD3KhYXFazCyxk8HR5UcwbvQgL4Q	SM1NC67EJ6B2DGER409TFBQSZ340Q2J7Y7V4XY1J
3D1hZjvBhrj69WGnA948Z8RZaeiVH67aJS	SM1Y33XHVMWZ8G83G41TPW3PRF72ANMBJC8D5QFTB
14bceNWXPCBg9n7TFqL3q9qe6nQReCpFJd	SPKQ8HJ1ED0Y7YGGH72YJAVX9J73C0D0D6QVCJ8T
3MgMp97aWxDsFBsEyZEdYmGGd2ba7rcQWk	SM3DM5CZ5A5ZBKY7N1MYH1RV8S5PMYGJS8C2WDRBS
1MrkzVfowEatLhz5tDwh9ttZzZ5f1v6iL9	SP3JCQ7NG4M6DHSFPFZ3T0M02H3JWZZVGQEK7TNEP
1PSnCwZ7hhmEin5dHHjjz4JPGEXGsLkaqW	SP3V35SQSTADZP1XWH54CMVGDT29NHW03NJH9M5E0
34tAUWPXnde8tWC8DYrF9BVhybdkv4y6fo	SMHG85TDP5THD0Y1SBWJ0GY3N4XSKJ31PA7SYP1E
3D5YpoZbJJyz3mD3WyUYD89g5PkwcsCEg6	SM1YERN34T7K145PDC8JM5XATC6H9SW45JXXZ645C
1LBWWyekgg3xQGWToooGxTQgxQYL2Jr163	SP396EC2XGYP6P7H8DRCEVNKAEVFANH1KWJPGH0TD
19q3GXTW1d7NjopMGEdsNHmWwHbkJod6ur	SP1GDDQCAHQJ9F7WV3953CH4KXS7KMKSSMT0M20AG
3CwCtYJEBTZU3qhL1HJytRSYEhTyds6KXm	SM1XNGQ2FQ2R6P571Y55ZFAKJRRXQE1MAP3JBNPQC
3A8XC3tLLWi2rNF47zDsJ9gR7iRTjnZh1s	SM1E97NH38KA81FZRZ4YMPBF03J5M2H22WTQZ9FFY
1KFgZrozEzEchyzMfRZ5hi2XeweBD42HRM	SP343J7DNE122AVCSC4HEK4MF871PW470ZSXJ5K66
3KitFxbHAp9CQQsxjPB3YyVwGvRXwi13WS	SM32WSCM915ZN56C0XTHQBAXNSM12MPNVTFYV7TTQ
38qw6mfpw7cRgL9nWakha9ZzTNZRADQXTL	SM177H67RTHC5JAPYC2CYWMM92BE60CWS194214CH
3A8n8rwMnHnt2BqnjW4R73eZCMcUDTpYvv	SM1EA0KYW19PJYKHZCZ7YQ5Z472XP51VJBY21JG99
3H4YX3yfH645keL1KFxa3sEh6ynEEpWmL6	SM2M9RAAE9B1G9J44KPZDFVDJVAYC5N7ZNSDBAHBZ

However, only ~12~ 13 of these addresses seem to have voted. I'm hoping you can help me discover where the discrepancy is.

---

Per SIP 019, your vote counts if you Stacked in either of the two preceding full reward cycles. These are reward cycles 19 and 20 (for the record, 20 is the current reward cycle, and will be the last full reward cycle before the vote tally block height). If you Stacked in both, then the later one is the one that counts. So for tabulation purposes, we'd only count your STX in reward cycle 20 even if you Stacked in both 19 and 20.

Looking at my node's log file, I've counted ~4,118~ 4,119 STX addresses Stacking in reward cycle 20, and 4,479 STX addresses Stacking in reward cycle 19. There are only 361 STX addresses Stacking in reward cycle 19 but not in 20.

What I did next was for each STX address, I looked up both its PoX address and the number of uSTX it locked (via get-stacker-info in .pox). I then checked the PoX address and then the STX address against the btc and stx representations of each vote transaction's scriptSig, and if the address was present, I recorded the uSTX for that Stacker as having voted (if both addresses were present, then no vote was calculated). I counted votes from PoX addresses first in order to mark all associated STX addresses as having voted; I then considered votes from STX addresses that had not been marked as voted. I finally summed up the number of uSTX that each PoX address represents.

In reward cycle 20, the votes come from ~8~ 9 distinct PoX addresses that represent the following uSTX:

PoX address	uSTX
3MuLXCkM3CfU8hNjsAXLvdMjH3L5UtDW8g	9940000000000
3HASeAxLLZQJTbGDTSyfxbJXLtnUF8K1Dw	1166632000000
3MgMp97aWxDsFBsEyZEdYmGGd2ba7rcQWk	9940000000000
1MrkzVfowEatLhz5tDwh9ttZzZ5f1v6iL9	941004000000
3CwCtYJEBTZU3qhL1HJytRSYEhTyds6KXm	9940000000000
3KitFxbHAp9CQQsxjPB3YyVwGvRXwi13WS	1600000000000
3A8n8rwMnHnt2BqnjW4R73eZCMcUDTpYvv	144777132418
3H4YX3yfH645keL1KFxa3sEh6ynEEpWmL6	11240000000000
1EsgJoqwcfbWsSyz6VHCYBvnh1iGrWB7dY	12622260119595

For STX addresses exclusively Stacking in reward cycle 19, there are 4 distinct PoX addresses which represent the following uSTX:

PoX address	uSTX
32f2jrLCkngfqaLjg2xXJ6uWQH9YV2ULZB	110697000000
19q3GXTW1d7NjopMGEdsNHmWwHbkJod6ur	110330000000
3A8XC3tLLWi2rNF47zDsJ9gR7iRTjnZh1s	9940000000000
3A8n8rwMnHnt2BqnjW4R73eZCMcUDTpYvv	32898608227

This totals to 67728598860240 uSTX, or 67,728,598.860240 STX.

What am I missing?

[hstove]

@jcnelson I haven't dug into the discrepancies yet, but here's the raw data that the app is showing:

https://sip12.halo.ms/votedata

The JS code to fetch this data is in hstove/sip-12-js. The logic is roughly:

1. Get all BTC vote txs
2. Get the (stx, btc) address for each vote (c32 and b58)
3. For each vote: a. do get-stacker-info with the stx address b. fetch the cumulative stacked amount from https://api.stacking-club.com/api/stacker-data?variables=${btcAddress}____20
4. The "STX amount" for each vote is the get-stacker-info amount, otherwise it's the Stacking Club amount

Again, I haven't really dubugged this yet, but that's the logic if others want to look into it.

Also, I just fixed an error that was thrown by the recent Segwit vote, because it wasn't converted to c32. That vote is now skipped. @aulneau @0xAsteria this was just published in v0.2.3. Also, I'm realizing that the BTC transactions fetcher doesn't have auto-pagination, and now we need that.

[aulneau]

@jcnelson thank you for your detailed analysis. I have a couple ideas of what could cause the differences in results.

Currently, the code that @hstove linked to above is only querying the stacking amount for a given pox address for cycle 20. It's not including values for cycle 19.

I've done a bit of work querying the database that powers stacking.club and I found that there is a slight difference in results for the total STX stacked this cycle when comparing against the v2/pox endpoint. stacking.club's tally is missing 773292170056 uSTX, or 773,292.170056 STX. This is still not nearly enough to account for a ~5 million STX difference. I wonder if it's possible that your code is counting some STX more than once?

There is one set of STX that I know is currently missing from stacking.club, and that is anything to do with boomboxes. There is a manual step for ingesting data where if contracts are doing the stacking, or there is a new contract that implements stacking, I need to pay attention to those transactions. It's possible that there are other contracts I might be missing, too. I will work to add that set of data tomorrow, with the hopes of getting the total sum that stacking.club displays to mirror the v2/pox endpoint. Additionally I will work to cross check each address with what I have and compare it to your values.

[Zk2u]

hey @hstove, the worker on Halo's API was having errors because of the segwit address. i upgraded to 0.2.3 and it's still having the same error.

[aulneau]

Okay, an update here. I've made a new API endpoint on stacking.club's api that gets the aggregate value for a given btc/stx address combination, for both cycles that are valid. See this PR in the sip-12-js repo.

I've deployed a new instance of the sip12 site with an output of data for cross-checking. You can see the associated PR here and the updated deployment here

The new total seems to be around 86 million STX, with at least 1 new vote that came in today for around 14 million STX.

I've cross checked your table above @jcnelson:

PoX address	uSTX
3MuLXCkM3CfU8hNjsAXLvdMjH3L5UtDW8g	9940000000000 ✅
3HASeAxLLZQJTbGDTSyfxbJXLtnUF8K1Dw	1166632000000 ✅
3MgMp97aWxDsFBsEyZEdYmGGd2ba7rcQWk	9940000000000 ✅
1MrkzVfowEatLhz5tDwh9ttZzZ5f1v6iL9	941004000000 ✅
3CwCtYJEBTZU3qhL1HJytRSYEhTyds6KXm	9940000000000 ✅
3KitFxbHAp9CQQsxjPB3YyVwGvRXwi13WS	1600000000000 ❌
3A8n8rwMnHnt2BqnjW4R73eZCMcUDTpYvv	144777132418 🤔
3H4YX3yfH645keL1KFxa3sEh6ynEEpWmL6	11240000000000 ✅
1EsgJoqwcfbWsSyz6VHCYBvnh1iGrWB7dY	12622260119595 ✅

✅: same results ❌: not returned from sip-12-js at all 🤔: different results: 4947709034005 is what I get

PoX address	uSTX
32f2jrLCkngfqaLjg2xXJ6uWQH9YV2ULZB	110697000000 ✅
19q3GXTW1d7NjopMGEdsNHmWwHbkJod6ur	110330000000 🤔
3A8XC3tLLWi2rNF47zDsJ9gR7iRTjnZh1s	9940000000000 ✅
3A8n8rwMnHnt2BqnjW4R73eZCMcUDTpYvv*	32898608227*

🤔: different results: 110425000000 is what I get *: counted above

@hstove can you look into why 3KitFxbHAp9CQQsxjPB3YyVwGvRXwi13WS is not being returned with the sip-12-js lib? I see that it is currently being returned at https://sip12.halo.ms/votedata.

[hstove]

I just pushed 0.3.1 of sip-12-js with support for pagination of BTC transactions when fetching all data.

I think the discrepancy with 3KitFxbHAp9CQQsxjPB3YyVwGvRXwi13WS comes from the fact that two different STX addresses stacked to this address. See: https://stacking.club/reward-address/3KitFxbHAp9CQQsxjPB3YyVwGvRXwi13WS/20

[whoabuddy]

Hey @whoabuddy @joberding, and @HaroldDavis3, this is a governance-track SIP. We're gonna need the governance CAB's sign-off (or rejection) on this at your earliest convenience. It's sufficient to just reply here with a comment (or even an emoji vote); I can add the sign-off text to the SIP. Thanks!

@whoabuddy You'll want to record that the decision happened. It could be as simple as adding a markdown file to the governance CAB folder in this repo with the date, signatories, and SIP number.

The governance CAB met today and we approve / sign-off on the changes for SIP-012!

The meeting minutes can be found in this PR and will merge into the considerations/minutes directory of the sips repo.

[jcnelson]

@aulneau I worked through this a bit more on my end and found that my scripts weren't handling delegation correctly. I'm now seeing a total of 4947709034005 uSTX for 3A8n8rwMnHnt2BqnjW4R73eZCMcUDTpYvv (4914810425778 in cycle 20, 32898608227 exclusively in cycle 19). I'm also seeing 110425000000 for 19q3GXTW1d7NjopMGEdsNHmWwHbkJod6ur in cycle 19. That resolves the discrepancies you pointed out.

But, I'm only seeing 87,258,727.153600 total for "yes", whereas sip012.xyz shows 87,764,177.000000.

Specifically, I'm not seeing the following amounts counted in my total:

btc	stx	amount
1KFgZrozEzEchyzMfRZ5hi2XeweBD42HRM	SP343J7DNE122AVCSC4HEK4MF871PW470ZSXJ5K66	450.000000 *
1LBWWyekgg3xQGWToooGxTQgxQYL2Jr163	SP396EC2XGYP6P7H8DRCEVNKAEVFANH1KWJPGH0TD	285,000.000000 *
1PSnCwZ7hhmEin5dHHjjz4JPGEXGsLkaqW	SP3V35SQSTADZP1XWH54CMVGDT29NHW03NJH9M5E0	220,000.000000 **

* These addresses delegated their STX, so they do not have the right to cast a vote on their own.

** The SIP 012 data you linked shows that this address represents 220,000.000000 STX, but this address's STX balance is 0 on the explorer.

These inconsistencies account for the differences between our two tallies. When I add these missing totals to my total, I arrive at sip012.xyz's total of 87,764,177.153600.

[314159265359879]

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? https://github.com/hirosystems/sips/blob/draft/sip-012/sips/sip-012/sip-012-cost-limits-network-upgrade.md

[Zk2u]

@314159265359879 I suggested #711975, but have had no answer (https://github.com/blockstack/stacks-blockchain/issues/2878#issuecomment-956405980)

[314159265359879]

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.

[jcnelson]

Was referring to this: https://github.com/stacksgov/sips/pull/41/files#diff-30158688704ec09920309bbc5a856f6b5b2fa55cc91f59191c5b517406c61b20R151-R156. The text calls it the "vote deadline block."

[jcnelson]

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. 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).

[jasonklau]

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 https://github.com/stacksgov/sips/pull/41#issuecomment-967729293, 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

[laelymenyon]

GG

[jcnelson]

Just had the public blockchain engineering meeting, and there were no objections. 713,000 it is.

[jcnelson]

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:

• Yes: 129,615,879.836327
• No: 0

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!

[jcnelson]

Alright folks, release 2.05.0.0.0 is out!

Release: https://github.com/blockstack/stacks-blockchain/releases/tag/2.05.0.0.0 Foundation announcement: https://groups.google.com/u/1/a/stacks.org/g/announce/c/RhDz0hj-XjI

[jcnelson]

SIP 012 has officially activated! Congratulations everyone! Merging this in.