Closed diwakergupta closed 2 years ago
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.
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?
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?
@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:
(stx, btc)
address for each vote (c32 and b58)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
get-stacker-info
amount, otherwise it's the Stacking Club amountAgain, 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.
@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.
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.
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.
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
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.
@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.
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
@314159265359879 I suggested #711975, but have had no answer (https://github.com/blockstack/stacks-blockchain/issues/2878#issuecomment-956405980)
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 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
GG
Just had the public blockchain engineering meeting, and there were no objections. 713,000 it is.
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 Foundation announcement: https://groups.google.com/u/1/a/stacks.org/g/announce/c/RhDz0hj-XjI
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.