How Many Blocks and Total Rewards for a Steem Witness in the Past 24 Hours?

in #witness-category4 years ago

The blockchain is a public database, this shouldn't be hard to find out. In this post we know how to call the Steem API to find out the witness that procduce each block and the reward (in VESTS) he/she collects for generating the block (mining).

Let's create a database in SQLite - with the schema:

sqlite> .schema
CREATE TABLE witnessblocks (
witness text,
number integer,
vests real,
time text,
block integer,
constraint pkey primary key (block)
);
CREATE INDEX index_block on witnessblocks(block);
CREATE INDEX index_witness on witnessblocks(witness);
CREATE INDEX index_time on witnessblocks(time);
CREATE INDEX index_vests on witnessblocks(vests);
CREATE INDEX index_number on witnessblocks(number);

Then, we can run a SQL to find out the number of blocks and total rewards for each witness. Results are sorted by total rewards in SP (which can be computed by simply roughly divided by 1943 SP) - see this number at: https://steemyy.com

Query:

sqlite> select witness,count(1), sum(vests/1943.761) as total from witnessblocks where time >= date('now', '-24 hour')  group by witness order by total desc limit 30;

Result (a bit surprising, more than expected, different than what the steemworld says @steemchiller): I double check the data and everything seems correct. My understanding is that a lot of misses are re-scheduled and that is why the TOP witnesses get more turns to produce blocks.

justyy|2326|578.82025257632
steemchiller|2324|578.325146664636
hinomaru-jp|2324|578.322147174472
hivei0|2323|578.073978002953
scissor.sisters|2322|577.826185736312
dlike|2321|577.5771644482
steem-supporter|2320|577.328037061142
inwi|2319|577.082116292075
beargame|2319|577.079035895361
smt-wherein|2318|576.832034089068
steem-dragon|2318|576.831055014993
roundblocknew|2318|576.828982039459
rnt1|2317|576.583037687762
hoasen|2317|576.582024700568
symbionts|2317|576.578049543128
steem-agora|2316|576.338157853255
maiyude|2316|576.336006269803
future.witness|2313|575.584969334193
protoss20|2309|574.593023568226
dev.supporters|2305|573.596812309745
matreshka|193|240.560583586665
parse|192|239.309574386974
cryptoking777|191|238.066390513031
menacamel|191|238.066344493484
juddsmith079|190|236.823358969544
enjoylondon|190|236.815291552305
rlawlstn123|187|233.082098971016
leverfile|186|231.834906382009
upeross|185|230.587764003393
roadofrich|30|37.3927565415707

Once this data is verified, I'll add it to the witness ranking table


Every little helps! I hope this helps!

Steem On!~
Reposted to Computing & Technology


If you like my work, please consider voting for me, thanks!
https://steemit.com/~witnesses type in justyy and click VOTE



Alternatively, you could proxy to me if you are too lazy to vote!

Also: you can vote me at the tool I made: https://steemyy.com/witness-voting/?witness=justyy

Visit me at: https://steemyy.com

Sort:  

Also the sums on SteemWorld are built by adding the vests of all received producer_reward operations in that time period. When I multiply the daily amount from SteemWorld (~342.18 SP) by 30 (days), I come to the correct monthly rewards.

Maybe it's related to the time in your WHERE clause time >= date('now', '-24 hour'). Can it be that your script begins to count from start of the previous day? If the field 'time' in your table is a date (without time) or the date() method returns a date instead of a datetime, I think this likely is the case.

For time fields I always use integers and store the unix time. I think this makes it easier to work with time ranges.

Einen weiteren Verbesserungsvorschlag für das Copy-Vote-Tool hätte ich: Ich werde oft in beide Richtungen überrascht, wie viel bzw. wenig meiner VP verbraucht wird, da ich immer "Copy voted weight" aktiviere. Wieviel % gegeben wurden, kann ich nur aufwändig einzeln feststellen über das Popup mit der Votes-Statistik. Und dann müsste ich auch noch die % zusammenzählen, um feststellen zu können, wieviel % ich ungefähr verbraten werde.

In der Liste wäre Platz für die Darstellung des Voteweights und einer Summe dazu. Daraus lässt sich zwar der genaue VP-Verbrauch nicht ermitteln, aber in hinreichender Näherung. Die resultierende ungefähre Wiederaufladezeit liesse sich wiederum daraus leicht errechnen und auch darstellen.

Ja, das halte ich für eine sehr gute Idee, die sich auch recht schnell umsetzen lässt. Vielleicht kann ich das sogar noch heute Abend reinbringen ;)

Das Vote-Weight ist jetzt schon mal mit in der Liste ;)

Super, herzlichen Dank! Du bist der Beste! Ich habe es schon angewandt, musste aber die Prozente im Kopf zusammenzählen und auf die Anzahl Hundertprozenter umrechnen um dann meinen ungefähren VP-Verbrauch zu ermitteln. Vielleicht kannst ja irgendwann noch diese Infos dazutun. Aber es ist schon mal eine wertvolle Hilfe.

Und ich habe gleich noch eine Frage: Bedeutet Ignore Self-Votes, dass solche des Kurators ignoriert werden oder solche, die sich ergäben, wenn ich durch die Gefolgschaft mich selbst voten würde? Ich habe gelernt, dass Kommentar- und Antwort-Selbst-Votes nicht gern gesehen sind und mache das daher nur in begründeten Ausnahmefällen.

Ja, das mit dem VP-Verbrauch muss ich auf später verschieben. Eventuell könnte man ein neues Feld 'Minimum VP' in dem Formular bereitstellen, wodurch der Batch dann bei Unterschreitung automatisch abbrechen würde.

'Ignore Self-Votes' ist aktuell nur auf den Kurator bezogen. Wenn ich jetzt so darüber nachdenke, macht es eigentlich Sinn den eigenen Account damit auch zu prüfen... Ja, ich denke, das kann ich morgen noch erledigen.

Das mit Minimum VP halte ich für eine sehr gute Idee, das wäre wohl das einfachste! Dann könnte man einfach so lang weitervoten, bis es abbricht. Und es würde direkt auf der realen VP beruhen statt auf einem angenäherten, berechneten Wert.

Jetzt habe ich gleich noch was bezüglich Crossposts und Appics-Posts:

  1. Bei beiden wird in der Posts-Liste kein Bild angezeigt. Bei Crossposts ist der Platz weiß und bei Appics schwarz. Das mit Appics habe ich dir letztes Jahr schon mal gemeldet und auch, dass es erscheint, wenn ich die von Appics übergebenen Bild-Links kürze, was etwas tricky ist. Aber das mache ich sowieso neben weiteren Edits, um die Darstellung in Steem zu optimieren.
  2. Bei Appics ist die Reward-Aufteilung nach wie vor 75/25, in der SW wird aber 50/50 dargestellt. Hier ein gerade gemachter Screenshot:
    IMG_20200720_194431.jpg
    Es steht allerdings nicht dabei, ob es nur für die APX-Token gilt oder auch für STEEM. Ich vermute mal ersteres, da ich mir nicht vorstellen kann, dass Appics auf der Steem-Blockchain eine extra 75/25-Regel haben kann. Das sollten die dann aber auch entsprechend darstellen.

Yes, you are right. I should use datetime('now', '-24 hour') instead of date('now', '-24 hour')

Hello Justyy, thank you for all the great work you are doing for the Steem blockchain! Would it be possible to create a list of the Most Downvoted Accounts??? The Top Muted Accounts feature was really helpful for my Troll Hunters Community, and I thought it would be great to add to that the most Downvoted accounts, as a way of discovering abusive users. Thanks again!

Thank you. Interesting idea! I'll definitely think about it

That's excellent! Thank you for considering it, I really appreciate it!

interesting that 20th and 21th are that much different.

Thank you for your service, as usual.

Thanks.. yes, the TOP 20 gets most slices of the cake. 😅

Coin Marketplace

STEEM 0.19
TRX 0.15
JST 0.029
BTC 64432.28
ETH 2648.26
USDT 1.00
SBD 2.78