Viewing a response to: @mundharmonika/re-steemchiller-pt3k2c-20190616t121455219z
>Wie heisst es so schön: "Gut Ding braucht Weile." Ja, so ist es. An sich kann dabei nicht viel passieren und wie du sagst, finden solche Prüfungen ja zum Glück auch innerhalb der Nodes statt. Das ist jetzt auch noch kein Grund für mich mein Witness-Vote für die Plattform zu entfernen. Insgesamt haben sie ja in der kurzen Zeit mit sehr wenigen Leuten so einiges auf die Beine gestellt. Man kann nur immer hoffen, dass aus solchen Schnitzern keine Gewohnheit wird. Vor allem bei Spielen auf der Blockchain müssen Entwickler sehr vorsichtig sein, denn in `custom_json`-Operationen übertragene Kontostände/Punktzahlen werden natürlich nicht von der Blockchain geprüft. Da gab es ja vor Kurzem auch einen Fall, wo jemand durch Manipulation des Frontends eines Würfelspiels die Kasse ins Minus setzen konnte und dadurch selbst wieder im Plus war. Heutige (professionelle) Spielefirmen betreiben einen enormen Aufwand allein dafür sicherzustellen, dass jeder Teilnehmer eines Netzwerkspiels die exakt selbe Version verwendet. In einem Shooter z.B. muss serverseitig (oder in Verbindung aller Clients) geprüft werden, ob eine gestartete Rakete/Bullet wirklich so, wie sie ins Netzwerk übertragen wurde, stattgefunden haben kann. Es gibt viele Cracker, die sogar auf RAM-Ebene Spiele manipulieren, daher reicht es auch längst nicht mehr aus nur die Versionsnummer der Teilnehmer zu prüfen. Ich habe schon viel erlebt und aus Erfahrung kann ich sagen, dass so gut wie jede Lücke oder vergessene Prüfung eines Tages auf einen zurückkommt. So viel wollte ich eigentlich gar nicht schreiben, aber das ging mir gerade durch den Kopf :)
post_id | 76,487,259 |
---|---|
author | steemchiller |
permlink | pt793n |
category | deutsch |
json_metadata | {"tags":["deutsch"],"app":"steemit\/0.1"} |
created | 2019-06-16 16:14:12 |
last_update | 2019-06-27 17:31:42 |
depth | 3 |
children | 11 |
net_rshares | 1,729,771,782,569 |
last_payout | 2019-06-23 16:14:12 |
cashout_time | 1969-12-31 23:59:59 |
total_payout_value | 0.760 SBD |
curator_payout_value | 0.217 SBD |
pending_payout_value | 0.000 SBD |
promoted | 0.000 SBD |
body_length | 1,629 |
author_reputation | 278,255,940,220,712 |
root_title | "Das Upvoten – 8. Teil: Das mächtige Beneficiaries-Tool – a) Spät-Upvotes jetzt viel einfacher" |
beneficiaries | [] |
max_accepted_payout | 1,000,000.000 SBD |
percent_steem_dollars | 10,000 |
author_curate_reward | "" |
voter | weight | wgt% | rshares | pct | time |
---|---|---|---|---|---|
afrog | 0 | 190,587,376,518 | 100% | ||
elviento | 0 | 1,386,722,335 | 1.08% | ||
double-u | 0 | 812,868,360,654 | 100% | ||
mundharmonika | 0 | 6,553,342,244 | 100% | ||
chriddi | 0 | 226,030,212,655 | 60% | ||
condeas | 0 | 42,670,470,638 | 40% | ||
sbi4 | 0 | 317,698,834,939 | 22.09% | ||
tiblog | 0 | 18,529,651,962 | 100% | ||
ibc | 0 | 79,886,105,733 | 50% | ||
linuxbot | 0 | 13,058,744,992 | 39% | ||
pixelworld | 0 | 2,609,623,965 | 100% | ||
i-c-e | 0 | 21,184,503 | 4% | ||
steem-hilfe | 0 | 17,871,151,431 | 52% |
Sehr spät noch danke für die Infos, sehr interessant, was alles möglich ist und wie sehr man als Dev aufpassen muss und wieviel Sorgfalt man an den Tag legen muss! Ich nehme an, dass ein großer Batzen der Programmierzeit für sowas draufgeht. Und wie so oft machen wohl die meiste Arbeit die Dinge, die der User/Kunde/Laie nicht sieht und nicht mal ahnt und sich wohl oft auch gar nicht vorstellen kann.
post_id | 77,125,210 |
---|---|
author | mundharmonika |
permlink | re-steemchiller-pt793n-20190627t163535891z |
category | deutsch |
json_metadata | {"tags":["deutsch"],"app":"steempeak\/1.13.2"} |
created | 2019-06-27 16:35:39 |
last_update | 2019-06-27 16:35:39 |
depth | 4 |
children | 0 |
net_rshares | 219,724,386,476 |
last_payout | 2019-07-04 16:35:39 |
cashout_time | 1969-12-31 23:59:59 |
total_payout_value | 0.082 SBD |
curator_payout_value | 0.027 SBD |
pending_payout_value | 0.000 SBD |
promoted | 0.000 SBD |
body_length | 402 |
author_reputation | 27,471,912,141,256 |
root_title | "Das Upvoten – 8. Teil: Das mächtige Beneficiaries-Tool – a) Spät-Upvotes jetzt viel einfacher" |
beneficiaries | [] |
max_accepted_payout | 1,000,000.000 SBD |
percent_steem_dollars | 10,000 |
author_curate_reward | "" |
voter | weight | wgt% | rshares | pct | time |
---|---|---|---|---|---|
steemchiller | 0 | 219,724,386,476 | 75% |
#### SteemWorld- und Steempeak-Fehlermeldung Jetzt bin ich's gleich nochmal, @steemchiller, da mir ein deftiger Fehler aufgefallen ist, der neben deiner SteemWorld mindestens auch Steempeak betrifft: Ich habe diesen Beitrag hier editiert, wodurch der Autovoter von @ennosan nochmal ausgelöst hat wie schon vor 13 Tagen beim Veröffentlichen. Von diesem Problem wusste ich bereits. Aber: 1. In der SW wird hier (sehr wahrscheinlich) der Reward des ersten Upvotes ausgewiesen. 2. Es sind auch noch 2 verschiedene Beträge (0.01347 vs. 0.01320). 3. Der Gesamt-Reward ist hier 1.123, in Steempeak aber nur 0.993. 4. [nur Steempeak] Beim Upvote-Eintrag von ennosan wurde die ursprüngliche Zeit mit der neuen Zeit überschrieben, der Betrag ist sehr wahrscheinlich gleich geblieben. Schlußendlich ist das die gleiche Falschdarstellung wie in der SW. ![image.png](https://files.steempeak.com/file/steempeak/mundharmonika/YFFe0jCu-image.png) ![image.png](https://files.steempeak.com/file/steempeak/mundharmonika/uNeWJctv-image.png) ![image.png](https://files.steempeak.com/file/steempeak/mundharmonika/EJqkdtwl-image.png) Ich vermute, dass es ein reines Darstellungsproblem ist, indem der bereits zuvor vergebene Echt-Upvote quasi zeitlich verschoben wird und damit der Reward in einer reward-unmöglichen Zeit aufscheint.
post_id | 77,128,484 |
---|---|
author | mundharmonika |
permlink | re-steemchiller-pt793n-20190627t175935581z |
category | deutsch |
json_metadata | {"tags":["deutsch"],"app":"steempeak\/1.13.2"} |
created | 2019-06-27 17:59:39 |
last_update | 2019-06-27 18:01:21 |
depth | 4 |
children | 9 |
net_rshares | 450,827,629,133 |
last_payout | 2019-07-04 17:59:39 |
cashout_time | 1969-12-31 23:59:59 |
total_payout_value | 0.166 SBD |
curator_payout_value | 0.055 SBD |
pending_payout_value | 0.000 SBD |
promoted | 0.000 SBD |
body_length | 1,315 |
author_reputation | 27,471,912,141,256 |
root_title | "Das Upvoten – 8. Teil: Das mächtige Beneficiaries-Tool – a) Spät-Upvotes jetzt viel einfacher" |
beneficiaries | [] |
max_accepted_payout | 1,000,000.000 SBD |
percent_steem_dollars | 10,000 |
author_curate_reward | "" |
voter | weight | wgt% | rshares | pct | time |
---|---|---|---|---|---|
steemchiller | 0 | 282,926,637,488 | 100% | ||
diana.feuerberg | 0 | 167,900,991,645 | 100% |
Die Gesamt-Payouts werden nach Auszahlung von den Nodes nicht mehr vollständig zurückgegeben, daher wird auf Steempeak wahrscheinlich die Netto-Summe angezeigt. Da hatte ich vor Kurzem schon mal drüber nachgedacht und wahrscheinlich sollte man schon vorher (wenn der Post noch aktiv ist) die `rshares`, die sowieso nicht ausgezahlt werden, abziehen. Normalerweise müssten die Nodes das so zurückgeben oder zumindest nach Abrechnung die gleichen Werte liefern. Aktuell berechne ich den 'burned'-Anteil selbst und rechne diesen für bereits abgerechnete Posts wieder rauf, damit die User nicht verwirrt sind. Ich glaube auf Steemit werden nach Auszahlung auch nur Netto-Werte angezeigt. Die Sache mit dem schwankenden Vote-Betrag kommt von der Berechnung der STUs anhand gevoteter `rshares`. Da das System Zinsen auf aufgepowerte Shares zahlt, erhöht sich der Endbetrag im Laufe der Zeit (gar nicht mal so wenig, Steemit verdient mit der eigenen SP ~ eine Million pro Jahr). Wenn man wie ich die Traffic-sparsame `get_active_votes` verwendet und damit die STUs berechnet, kommt es zu kleinen Abweichungen. Das soll natürlich nicht so bleiben und ich werde für abgerechnete Posts die Berechnungslogik demnächst ändern. Man muss also immer den gesamten Post laden, um die ausgezahlten Beträge zu erhalten, darauf dann manuell die nicht ausgezahlten `rshares` addieren und aus der errechneten Gesamtsumme den korrekten Vote-Anteil ermitteln.
post_id | 77,133,745 |
---|---|
author | steemchiller |
permlink | ptrxwq |
category | deutsch |
json_metadata | {"tags":["deutsch"],"app":"steemit\/0.1"} |
created | 2019-06-27 20:22:03 |
last_update | 2019-06-27 20:22:03 |
depth | 5 |
children | 8 |
net_rshares | 3,383,148,114,617 |
last_payout | 2019-07-04 20:22:03 |
cashout_time | 1969-12-31 23:59:59 |
total_payout_value | 1.252 SBD |
curator_payout_value | 0.383 SBD |
pending_payout_value | 0.000 SBD |
promoted | 0.000 SBD |
body_length | 1,436 |
author_reputation | 278,255,940,220,712 |
root_title | "Das Upvoten – 8. Teil: Das mächtige Beneficiaries-Tool – a) Spät-Upvotes jetzt viel einfacher" |
beneficiaries | [] |
max_accepted_payout | 1,000,000.000 SBD |
percent_steem_dollars | 10,000 |
author_curate_reward | "" |
voter | weight | wgt% | rshares | pct | time |
---|---|---|---|---|---|
englishtchrivy | 0 | 375,067,370,493 | 100% | ||
elviento | 0 | 1,542,615,622 | 1.26% | ||
steemit.nemesis | 0 | 150,997,773,643 | 100% | ||
double-u | 0 | 1,104,620,432,683 | 100% | ||
vieanna | 0 | 272,723,468,425 | 100% | ||
mundharmonika | 0 | 0 | 100% | ||
jkiw | 0 | 64,757,894,986 | 100% | ||
chriddi | 0 | 231,740,954,528 | 50% | ||
condeas | 0 | 54,737,715,314 | 40% | ||
sbi3 | 0 | 290,755,404,368 | 14.94% | ||
kadna | 0 | 402,963,159,121 | 100% | ||
tiblog | 0 | 245,383,137,256 | 100% | ||
gerdtrudroepke | 0 | 54,842,606,804 | 50% | ||
ibc | 0 | 96,249,594,076 | 80% | ||
seo-boss | 0 | 36,747,139,799 | 50% | ||
i-c-e | 0 | 18,847,499 | 4% |
Danke, @steemchiller, für die schnelle, ausführliche Antwort! Ganz habe ich es nicht kapiert. Stellt der 'burned'-Anteil die Summe der Dust-Rewards dar? Ich habe den noch nicht ganz begriffen und meinte, das ist wahrscheinlich der Curation-Anteil, den der Autor seit der letzten HF aus seinem Selbst-Upvote nicht mehr bekommt. Da wir gerade beim Thema sind, erlaube ich mir noch 3 Fragen dazu, die mir schon lange unter den Nägeln brennen, da das meine Beitragsreihe betrifft, zu der auch dieser hier gehört (da ich deine knappe, kostbare Zeit so wenig wie möglich beanspruchen möchte, würde mir natürlich auch eine Literaturangabe genügen; leider konnte ich bisher nichts finden): 1. Reden wir von Dust-Upvotes, wo nur der einzelne Upvote keinen Autor-Reward und/oder keinen Kurator-Reward generiert, gleichzeitig aber andere Upvotes auf den gleichen Beitrag (Kommentar, Antwort) schon oder von Beiträgen, Kommentaren und Antworten, bei denen alle Upvotes zusammen die Dust-Grenze nicht überschreiten oder von beidem? 2. Wo sind die Dust-Grenzen für die 3 Reward-Arten (inkl. Benefactor-Reward) und auf welchem Wert basieren sie (rshares, vshares, VESTS, STEEM, $ oder STU)? 3. Besteht zwischen einem Autor-Dust-Reward, einem Kurator-Dust-Reward und ggf. einem Benefactor-Dust-Reward ein direkter Zusammenhang? Meinst du mit Netto-Werte die Gesamt-Rewards abzüglich 'burned'-Anteile oder die Autor-Anteile ohne Kuratoren-Anteile? Beides passt hier nicht: ![SW.png](https://files.steempeak.com/file/steempeak/mundharmonika/xcrnJgn0-SW.png) Mit dem Burned-Anteil sind es 1,124 $, ohne 1,122 $, also jeweils 0,001 $ Abweichung, ist wahrscheinlich eine Rundungsdifferenz.
post_id | 77,235,551 |
---|---|
author | mundharmonika |
permlink | re-steemchiller-ptrxwq-20190629t171934106z |
category | deutsch |
json_metadata | {"tags":["deutsch"],"image":["https:\/\/files.steempeak.com\/file\/steempeak\/mundharmonika\/xcrnJgn0-SW.png"],"format":"markdown","app":"steeve\/0.1"} |
created | 2019-06-29 17:19:39 |
last_update | 2019-06-29 17:26:54 |
depth | 6 |
children | 3 |
net_rshares | 68,178,922,174 |
last_payout | 2019-07-06 17:19:39 |
cashout_time | 1969-12-31 23:59:59 |
total_payout_value | 0.024 SBD |
curator_payout_value | 0.008 SBD |
pending_payout_value | 0.000 SBD |
promoted | 0.000 SBD |
body_length | 1,674 |
author_reputation | 27,471,912,141,256 |
root_title | "Das Upvoten – 8. Teil: Das mächtige Beneficiaries-Tool – a) Spät-Upvotes jetzt viel einfacher" |
beneficiaries | [] |
max_accepted_payout | 1,000,000.000 SBD |
percent_steem_dollars | 10,000 |
author_curate_reward | "" |
voter | weight | wgt% | rshares | pct | time |
---|---|---|---|---|---|
steemchiller | 0 | 68,178,922,174 | 25% |
Und jetzt komm ich nochmal auf meine Haupt-Fehlermeldung zurück, die ich anscheinend nicht klar genug ausgedrückt habe: Der erste Screenshot zeigt, dass mir die SW einen Upvote mit einem zugehörigen Reward ausweist, welcher so ***13 Tage zuvor*** stattgefunden hat! Und der angezeigte Post Payout hat eben auch schon ***6 Tage zuvor*** stattgefunden! Im dritten Screenshot wird das gleiche auf andere Art dargestellt, nämlich dass ich von @ennosan 44 min zuvor ***(also vorgestern 27.6. 18:39 und damit 13 Tage später als die meisten anderen Upvotes!)*** einen Upvote mit einem Reward von 0,012 STU (in der SW aber 0,01320 $ bzw. 0,01347 $!) erhalten habe!
post_id | 77,237,008 |
---|---|
author | mundharmonika |
permlink | re-steemchiller-ptrxwq-20190629t174915538z |
category | deutsch |
json_metadata | {"tags":["deutsch"],"format":"markdown","app":"steeve\/0.1"} |
created | 2019-06-29 17:49:21 |
last_update | 2019-06-29 17:49:21 |
depth | 6 |
children | 3 |
net_rshares | 69,548,217,569 |
last_payout | 2019-07-06 17:49:21 |
cashout_time | 1969-12-31 23:59:59 |
total_payout_value | 0.026 SBD |
curator_payout_value | 0.008 SBD |
pending_payout_value | 0.000 SBD |
promoted | 0.000 SBD |
body_length | 657 |
author_reputation | 27,471,912,141,256 |
root_title | "Das Upvoten – 8. Teil: Das mächtige Beneficiaries-Tool – a) Spät-Upvotes jetzt viel einfacher" |
beneficiaries | [] |
max_accepted_payout | 1,000,000.000 SBD |
percent_steem_dollars | 10,000 |
author_curate_reward | "" |
voter | weight | wgt% | rshares | pct | time |
---|---|---|---|---|---|
elviento | 0 | 528,722,089 | 0.42% | ||
steemchiller | 0 | 69,019,495,480 | 25% |