Das Upvoten – 8. Teil: Das mächtige Beneficiaries-Tool – a) Spät-Upvotes jetzt viel einfacher
Das Upvoten – 5. Teil: Der Schieberegler (Slider), das Vote Weight und das Total Vote Weight
Das Upvoten – 7. Teil: SteemWorld-Simulationen mit kühnen Änderungs- und Erweiterungsvorschlägen
Aus gegebenem Anlass fiel mir meine vor 11 Monaten aus den Augen verlorene Beitragsreihe wieder ein, die ich hiermit sehr spät endlich fortsetze. Allerdings schiebe ich hier ein anderes Thema ein und mache mit den damals angekündigten Themen im Anschluss weiter.
Problemlösung und enorme Vereinfachung von Spät-Upvotes
Es gibt die – eher selten genutzte – Möglichkeit, dass man mit dem Kommentar-Trick, den @reiseamateur vor langer Zeit auf deutsch vorgestellt hat, auch Beiträge – und auch Kommentare und Antworten aller Ebenen! – nach deren Payout nach 7 Tagen noch ewig (indirekt) upvoten kann. Ich nenne die mal Spät-Upvotes.
Der Vollständigkeit halber sei angemerkt, dass auch direkte Spät-Upvotes ewig möglich sind, diese aber halt keine Rewards mehr mit sich bringen, weshalb auch die Vote Power (VP) davon nicht reduziert wird. Das ist dann wie ein Like auf anderen Plattformen als Ausdruck der Anerkennung und Wertschätzung.
Das macht Sinn, weil solche Upvotes in der SteemWorld genauso wie alle anderen dargestellt werden, so dass sie der Autor genauso bemerken kann. Dort steht dann als Betrag 0.00000 $ (ich habe 5 Nachkommastellen in den Settings). Darum mache ich das seit langer Zeit immer wieder mal, zumal ich mich über solche Upvotes, die ich gar nicht so selten kriege, ca. 3-4 mal im Monat, auch freue. Schließlich bin auch ich nicht nur wegen der Kohle auf Steemit! ;-) Genauso dürfte das auch bei Downvotes funktionieren, das habe ich nicht ausprobiert.
Zurück zu den Spät-Upvotes mit Rewards: Hier war der bisherige Trick, dass der Kurator unter dem Beitrag (bzw. Kommentar oder Antwort) einen Kommentar bzw. eine Antwort postet in der Hoffnung, dass der Autor diesen bemerkt und darauf antwortet, womit der Kurator dann die Möglichkeit hat, diese Antwort stellvertretend zu voten. Wie ich mitbekommen habe, bemerken das aber die Autoren oftmals nicht, so dass es nichts wird mit dem Spät-Upvote.
Viel besser geht das mit der Beneficiaries-Funktion (Beneficiaries: Begünstigte, Nutzniesser). Draufgekommen bin ich durch die Entdeckung des genialen, umfangreichen, aber auch komplexen Upvote-Tools Steemrewarding von @holger80. Dort ist das eine der vielen automatisierten Upvote-Möglichkeiten. Es erzeugt sogar den nötigen Kommentar, der dann mit der besagten Beneficiaries-Regel versehen wird. Einen weiteren Teil dieser Beitragsreihe werde ich diesem Tool widmen, sobald ich alles verstanden habe.
Wie geht das jetzt ohne Steemrewarding? Ganz einfach:
- Steempeak oder Steemitbenutzen (mit Busy, Steeve und Partiko geht das nicht) [Edit am Sa 7.12.19 18:51]
- Diesen ziemlich kurzen Beitrag von @steempeak (englisch) lesen
- Einen Kommentar in der ersten Ebene mit entsprechendem Text verfassen, die Regel eintragen, posten und upvoten [Edit So 16.6.19 14:39]
Dazu noch einige Erläuterungen und Anmerkungen: Es geht eben nicht nur bei Beiträgen, so wie dort beschrieben, sondern auch bei Kommentaren, wie es auch in den Kommentaren und Antworten zu vorgenanntem steempeak-Post zum Ausdruck kommt. Die Regel kann nur einmalig beim Veröffentlichen eingetragen und dann nicht mehr geändert werden. Aufrufen kannst du die Funktion mit dem dunkelgrauen Button links unten mit den Köpfen und dem +:
In den Favorites wird der Autor praktischerweise gleich automatisch vorbelegt. Du brauchst nur draufzuklicken.
Und statt dass du nur dem Autor den vollen Reward zukommen lässt, also einen Eintrag mit idR 100 % machst, kannst du auch noch weitere Beneficiaries eintragen (aufpassen, dass es in Summe 100 % sind, außer du selbst willst auch was vom Reward):
Das habe ich real so gemacht für einen Spät-Upvote des vorgenannten Posts von @steempeak. Kleiner Fehler: In diesem Stadium kannst du den Save-Button nicht auslösen. Du musst erst auf den grünen +-Button klicken, so als ob du noch einen anfügen wolltest:
Verbesserungswürdig: Unpraktischerweise ist ein direkter Eintrag im %-Feld nicht möglich, sondern der %-Satz kann nur mit + und - ausgewählt werden. Ebenfalls unpraktischerweise laufen die % nicht weiter, wenn man auf + bzw. - draufhält, sondern man muss für jedes % einen Klick machen.
Aber, kleiner Trick: Wenn man bei 0 auf - klickt, kommt 100, es geht also auch von hinten her. Nur bei 50 ist es egal, wie rum man 50x klickt.
Nicht so kleiner Fehler: Es wird nicht geprüft, ob mehr als 100 % eingetragen wurden. Ich habe beide auf 100 % gesetzt und es wurde so gespeichert. Beim posten kam dann folgende Fehlermeldung:
In der SteemWorld sieht das so aus:
Ich habe folgende Infos in den Kommentar eingetragen:
Comment for a late upvote of this post
Beneficiaries:
@steempeak 80 %
@steemchiller 20 %
Der 2. Comment-Eintrag kommt übrigens von einem Edit.
Ich habe also diesem meinem Kommentar einen 100-%-Upvote gegeben. Normalerweise sind ja Eigenupvotes von Kommentaren nicht gern gesehen, aber hier ist das ja eine hundertprozentige Reward-Umleitung (80 % + 20 %). Und hier die aufgeklappten Comment Options:
In der ersten Zeile sind die Curation Rewards erwähnt. Hier gibt es keine Besonderheiten. Es werden also die 75 % Author Rewards verteilt wie immer.
Die % werden hier wie immer als Weight bezeichnet und in 1/100 % ausgedrückt. Es wäre also auch hier diese feine %-Auflösung möglich, aber in Steempeak kann man nur volle % auswählen.
Und daran können sich natürlich noch andere anhängen mit Upvotes. Aber: Da könnten auch manche tricksen und alles selber abgreifen. Darum solltest du bei einem Kommentar-Autor, dem du nicht genügend vertraust, mit dem Cursor über den Rewardbetrag gehen, dann siehst du, ob das so stimmt (zumindest auf Steempeak), bevor du dich mit einem Upvote dranhängst!
Und es könnte sogar einer, der hier zu spät zum Upvoten kommt, einen weiteren Kommentar erstellen und das Spiel von vorne beginnen usw.! Mehr zu diesem Tool im nächsten Beitrag: Das Upvoten – 9. Teil: Das mächtige Beneficiaries-Tool – b) Weitere Anwendungsmöglichkeiten
Beneficiaries:
@steemchiller 12 %
@steempeak 6 %
Erstmal danke für deine Unterstützung!
Das ist innerhalb der Nodes etwas verwirrend gelöst, aber es sind 10000 (100%) von 50% (da maximal 50% SBD-Auszahlung möglich ist). Man nutzt also in dem Fall 100% der möglichen Auszahlung in SBD.
Das gibt mir zu denken und es wurde dann eindeutig nicht professionell gelöst. Mein Post-Editor ist zwar noch nicht fertig, aber diese Prüfung war eine der ersten, die ich eingebaut habe.
Das ist auch der Grund, warum ich bisher nur Steemit nutze, denn immerhin ist hier Geld im Spiel und Frontends müssen daher umso überlegter entwickelt werden (was bei Steemit, was die Sicherheit betrifft, auf jeden Fall gegeben ist).
Gute Software braucht immer Zeit :)
LG, Chiller
Bitte, gern, auch wenn die bei meiner SP winzig ausfällt. Aber wichtiger ist für mich hier der Aspekt, mit gutem Beispiel voranzugehen, auf dass hoffentlich viele nachfolgen.
Danke für die Detailinfo, ich ändere das im Beitrag. Ich muss eh noch was ändern, da die Beneficiaries nur in der ersten Kommentarebene eingetragen werden können, also nicht in den Replies. Ich hatte das doch nicht geprüft vorher.
Das denke ich mir, dass dir so ein Schnitzer nicht passieren würde. Aber die Blockchain hat es ja abgewiesen, es kann also nichts passieren in der Hinsicht. Wie heisst es so schön: "Gut Ding braucht Weile."
Ich wundere mich, dass noch nicht mal Steemit die Beneficiaries-Funktion anbietet.
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 :)
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:
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.
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-sparsameget_active_votesverwendet 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 ausgezahltenrsharesaddieren und aus der errechneten Gesamtsumme den korrekten Vote-Anteil ermitteln.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!
Ja, so in etwa kann man das sagen, aber ich kann ohne weiteren Aufwand solche Votes nicht erkennen und filtern, sonst würde ich es schon längst getan haben. Die Node gibt in so einem Fall die Votes als neue Operationen zurück. Es werden sogar neue Transaktionen dafür erstellt, die in meinem Augen eigentlich nicht benötigt werden, aber wie ich hier auf GitHub erfahren habe, soll das wohl so bleiben...
Danke für die Bestätigung! Sehr verwunderlich, dass so etwas verwirrendes bewusst beibehalten werden soll!
Ich habe gerade gemerkt, dass bei dir gerade die selbe Chose abläuft, weil du deinen #36-Beitrag editiert hast.
Posted using Steeve, an AI-powered Steem interface
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):
Meinst du mit Netto-Werte die Gesamt-Rewards abzüglich 'burned'-Anteile oder die Autor-Anteile ohne Kuratoren-Anteile? Beides passt hier nicht:
Mit dem Burned-Anteil sind es 1,124 $, ohne 1,122 $, also jeweils 0,001 $ Abweichung, ist wahrscheinlich eine Rundungsdifferenz.
Dust-Votes gibt es schon seit Längerem nicht mehr, nur noch Dust-Payouts. Solange ein Post die Mindestsumme von $0.02 erreicht, werden also auch Mini-Votes berücksichtigt.
Min.
author_reward: 0.02 STUMin.
curator_reward: 0.001 SPMin.
comment_benefactor_reward: 0 (frag mich nicht warum)Ich habe heute folgende Operation erhalten:
'Netto' ist wahrscheinlich keine angemessene Bezeichnung, da man dann auch die Kuratoren-Anteile abziehen müssten. Ich meinte nur abzüglich des 'burned'-Anteils, wobei selbst die Bezeichnung 'burned' nicht 100%ig richtig ist, da die Shares gar nicht erst verteilt werden, aber das ist ein anderes Thema. Nach der nächsten HF werde ich das vermutlich mal ändern und genauer beschreiben.
Das hat mit Selbst-Upvotes nichts zu tun, sondern es betrifft auch die Votes aller anderen Kuratoren. Wenn jemand genau nach 7 Minuten und 30 Sekunden votet, gehen 50% der
rsharesbei Auszahlung zurück in den Pool (bis dahin sind sie aber in der Post-Summe enthalten, was wahrscheinlich einige Leute schon des Öfteren verwirrt hat). Man bekommt auch für Selbst-Upvotes nach wie vor Curation-Rewards.Ja, das wird wahrscheinlich eine Rundungsdifferenz sein, aber unter 0.002 sollte man in Steem-Frontends auch gar nicht erst anfangen zu zählen.
Inzwischen bereue ich, dass ich die Anzeige mit mehr als 3 Nachkommastellen überhaupt eingebaut habe. Wenn man nicht genug verdient, hat man entweder zu wenig investiert, keine interessanten Beiträge am Start oder die Zielgruppe ist (noch) nicht groß genug. Ich denke, Erbsenzählerei hindert Menschen daran sich auf große Ziele zu konzentrieren und das geht dann schon in den Mikro-Erbsen-Bereich... ^^
Herzlichen Dank für deine ausführliche Antwort! Ich fühle mich geehrt, dass du meine Fragen trotz knapper Zeit schnell und direkt beantwortest! Das ist für mich natürlich angenehmer, als wenn ich es mir aus einer Literaturempfehlung herausziehen müsste. Wenn es genehm ist, erlaube ich mir, an einem Punkt nachzuhaken, um dieses Thema hier für mich abschliessend zu klären: Ist es mit der letzten HF so gravierend geändert worden, dass ein bewusst frühes Upvoten, um dem Autor Gutes zu tun, weil der dann den entsprechenden Teil des eigenen Curation Rewards bekommt, jetzt nur noch zum eigenen Rewardverlust führt, ohne dem Autor zu nützen? Oder hatte ich das vorher falsch verstanden gehabt?
Es wundert mich sehr, dass
a) für die Dust-Grenzen verschiedene Einheiten verwendet werden und
b) für die author-rewards die relativste und abgeleitetste Einheit STU (= $?) verwendet wird, die ja vom stark schwankenden Wechselkurs abhängt.
Für mich wäre es viel einleuchtender und nachvollziehbarer, überall die Grundeinheiten VESTS oder rshares anzuwenden.
Wenn es einen min.
comment_benefactor_rewardgibt, müsste es auch einen min.post_benefactor_rewardgeben.Das sehe ich nicht so, vor allem in Micker-Kurs-Zeiten wie diesen. Die Planktons (bin ich überhaupt noch eins?) werden es dir danken, sehen sie doch damit nicht nur lauter demotivierende Nullen! Und nicht jeder Neuling hat die Kohle, gleich mal kräftig aufzupowern, sprich zu investieren. Ich habe gerade eben meine SBD getauscht und aufgepowert und bin jetzt bei lausigen 0,00635 $ TMVA (also bei 2x 100 %).
Da hast du wohl recht, aber das war hier nicht meine Intention, sondern einen möglichen Fehler aufzudecken (wenn es denn nicht an Rundungsdifferenzen liegen würde). Und hier wäre halt der Fehler nur an diesem Mikro-Unterschiedsbetrag sichtbar geworden.
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.
Spät-Upvote-Kommentar
Beneficiary:
@marcus0alameda 100 %
für seinen Kommentar hier
Oh cooler Trick mit den Beneficiaries 👍
Yeah, aber das ist noch nicht alles! Stay tuned, ich schreibe gerade die Fortsetzung...
Ein Teammitglied von Steempeak hat mir vor ein paar Tagen auf die Frage hin zu genau dieser Möglichkeit mitgeteilt, dass sie diese Funktion ungefähr so nutzen wollen, ohne dass man die Einstellungen jedes mal aufs neue treffen muss. Sondern so, dass "Spät-Upvotes" automatisch mit einem Klick funktionieren. Zumindest davon gehe ich mal aus. Die Votes, die dann noch innerhalb von 7 Tagen von anderen Usern eventuell nachfolgen, würden dann wohl automatisch auf den Kommentar umgeleitet werden.
Spät noch danke für die Infos, sehr interessant, bin gespannt!
PS: Habe dir einen Spät-Upvote gemacht.