Erstmal wieder herzlichen Dank für deine unermüdliche, großartige Arbeit! Hier eine kleine Ungereimtheit, die dich interessieren dürfte, zusammen mit einem Verbesserungsvorschlag:
Gestern habe ich als Stammtisch-Organisator die Autoren-Rewards für meine Einladung und für den Last Call dazu rausgesucht, um diese an die Teilnehmer zu verteilen. Da der Payout für die Einladung 8 Tage her war, also einen Tag zu lang, um in der SteemWorld in den Account Operations noch angezeigt zu werden, habe ich in steemd nachgeschaut.
Ich habe dann aber gemerkt, dass ich den Betrag von 6,036 SP doch schon zuvor aus der SteemWorld notiert hatte. Nun zeigt aber steemd stattdessen in der Auflistung 6,039 SP an, in der Block-Detailansicht aber nur den zugehörigen VESTS-Wert (sh. Hardcopy). Ich vermute, dass es an unterschiedlichen VESTS-SP-Umrechnungs-Zeitpunkten liegt, da sich der Umrechnungsfaktor ja kontinuierlich erhöht.
Nun stellt sich die Frage, welcher SP-Wert der richtige ist (auch wenn es hier keine nennenswerte Auswirkung auf die Verteilung hatte, nämlich 0,0005 SP je Teilnehmer). Ich habe den Wert der SteemWorld verwendet. Toll wäre es, wenn auch bei den Finished Posts die Payouts neben den $ auch in STEEM, SP und SBD stehen würden – und am besten auch noch die VESTS!
Vielen Dank für die Info! Ja, das hast du richtig vermutet, also die ausgezahlten 'vesting shares' ändern sich nie, aber natürlich die daraus errechnete SP je nach aktuellen Umrechnungswerten der Blockchain. Ich denke auch, dass der Wert zum Zeitpunkt der Auszahlung der wahrscheinlich 'richtigste' wäre.
Was die angezeigten Summen in den bereits abgerechneten Posts betrifft, bist du an die Grenzen des derzeit mit der Steem API Machbaren gestoßen und daher kann ich da noch nicht alle Werte anzeigen, wie ich sie gerne hätte ;)
Das ist unter vielen anderen ein Grund dafür, warum ich jetzt an einer eigenen API (SDS) arbeite. Ich habe geplant, zum Zeitpunkt der Abrechnung eines Posts die genauen Werte für diesen Post in meiner Posts-DB zu speichern. Dafür werde ich die virtuellen Operationen parsen und für jede nach 7 Tagen eintreffende 'author_reward' Operation die endgültigen Werte übernehmen.
In ein paar Wochen wird SteemWorld über die neue API laufen und die vielen Grenzen sind dann endlich aufgehoben. Auch die noch fehlenden Summen für die Allzeit-Rewards kann ich dann endlich reinbringen. Bezüglich der Account-Historie bin ich mir noch nicht sicher, ob ich das auch über meinen Server laufen lassen kann (könnte aus Speicherplatzgründen eng werden), aber es hätte seine Vorteile.
Mit der jetzigen Steem API kann ich nämlich nicht einfach die Operationen eines bestimmten Datums ermitteln sondern nur rückwärtszählend vermuten/prüfen, wo ich mich befinde, was auch der Grund für die aktuelle 7-Tage-Grenze ist. Bald wissen wir mehr :)
Danke für deine schnelle, interessante Antwort, und den 100%er!
Wenn ich das als Laie richtig sehe, müsstest du über die Blocknummern alles auf 3 sec genau ansteuern bzw. prüfen können (natürlich nur, soweit sie zur Verfügung stehen).
So kann ich die einzelnen virtuellen Operationen ermitteln (woraus sich eine Account-Historie aufbauen lässt) aber leider nicht gezielt die Account-Historie für einen Benutzer. Es würde also bedeuten, dass dein Browser alle Operationen downloaden müsste, um danach die für dich relevanten rausfiltern zu können.
Die Daten aller Steemians für eine Woche zu laden liegt im GB-Bereich und es würde die Nodes ziemlich überlasten, wenn ich das für jeden Benutzer auf SteemWorld machen würde. Der API-Aufruf
get_account_historyliefert mir gezielt für einen Benutzer die letztenXOperationen ausgehend von der gewählten Start-Operations-IDY. Die ID ist nur ein Index (der auch von Node zu Node unterschiedlich sein kann) und sie ist nicht an ein Datum geknüpft.Ich denke, es führt nichts daran vorbei, einen eigenen Index zu führen der die einzelnen Operations-IDs mit einem Zeitstempel verknüpft oder (die bessere Lösung) die gesamte Account-History per User zu speichern und mit einem Datumsfeld zu versehen (was ich wahrscheinlich tun werde).
Danke, dass du mir/uns trotz deiner knappen Zeit so ausführlich so interessante und laienverständliche Infos gibst! Mir ist da ein On-demand-Verfahren als Alternative (?, vielleicht ja völlig abwegig) in den Sinn gekommen:
Wenn ein User seine SteemWorld-Seite aufruft oder die autom. Aktualisierung ansteht, wird eine SQL-Abfrage o. ä. (ggf. mit userdefiniertem beliebigem Zeitraum, aber wohl umfangsmäßig begrenzt) direkt an der Datenquelle – also wohl bei den Nodes – ausgelöst und nur das Ergebnis zurückgegeben. Hab natürlich keine Ahnung, ob sowas möglich und/oder wirklich sinnvoll wäre.