Solo Mining Wahrscheinlichkeit

Finde ich auch, habe gestern noch auf die schnelle einen eigenen Rechner geschrieben:

Da hat @skyrmion’s hübsche Formel natürlich Einzug gefunden. :stuck_out_tongue:

Ist gestern aber ein bisschen spät geworden, vor allem die Formel habe ich erst gegen Ende noch dazu geschmissen, also wäre cool wenn ihr ein bisschen damit rumspielen könnt, um Fehler zu finden. :slight_smile:

Als Wert für die Hashrate nehme ich jetzt aktuell den vorherigen Tagesdurchschnitt. Der rechnet die krassen Schwankungen raus, ist aber trotzdem Top-Aktuell. Sicherlich kann man hier noch diskutieren, ob ein Monatsdurchschnitt nicht sinnvoller wäre. Aber bei den kleinen Zahlen im Solo Mining spielt das im Endeffekt auch keine große Rolle. Es geht schließlich immer um die Größenordnung.

(In macOS Safari passieren mal wieder seltsame Dinge, also einen gescheiten Browser nutzen…)

4 „Gefällt mir“

N :icecream: Und danke. Damit hast Du mir Arbeit gespart :smiley:

Ich hätte etwas UX Senf für Dich. Falls nicht gewünscht, einfach ignorieren :stuck_out_tongue_winking_eye:

„Expected hashrate increase“
Hier würde ich einen Default-Wert setzen, der sich aus dem Durchschnitt der Vergangenheit speist (soweit möglich) oder zumindest die Erklärung um einen sinnvollen Vorschlag erweitern. Die meisten (mich eingeschlossen) haben keine Idee, welcher Faktor angemessen ist.

Der Auswertungstabelle würde ich noch eine Überschrift spendieren á la: Deine Gewinnwahrscheinlichkeit. Die UX leidet nicht unter ihr, bietet aber all jenen eine schnellere Orientierung, die etwas Webseiten blind sind.

Die Zahlen in ihr würde ich um Trennzeichen ergänzen, um ihre Lesbarkeit zu verbessern. (Laut gedacht: Außerdem frage ich mich, wie sinnvolle ein Hinweis für die deutschen Besucher auf das englische Zahlenformat in einer Erklärung wäre. Vermutlich sollte sich das Problem durch die Trennzeichen von selbst erklären/erledigen :thinking:)

Die Prozentzahlen würde ich auf 2 Stellen nach dem Komma bzw. Punkt runden. Der Lesbarkeit wegen.

Ich würde schätzen, dass die meisten das Wachstum der Hashrate nicht mit einrechnen wollen. Daher finde ich den Default 1 eigentlich ganz sinnvoll.

Bei der Jahresangabe ist der Default 72, da das die durschnittliche Lebenserwartung weltweit ist.

Dann steht da aber bei jeder relevanten Rechnung 0.00%… :sweat_smile:

Aber ja, Formatierung der Zahlen ist noch verbesserungswürdig. Die wissenschaftlichen Zahlen sollte man auf jeden Fall auf zwei Stellen fixieren und auch bei größeren Wahrscheinlichkeiten macht das Sinn.

Das würde ich hinterfragen. Ich betreibe den Nerd Miner, um etwas über das Mining zu lernen. Dazu gehört auch, sich mit der wachsenden Hashrate des Netzwerks auseinander zu setzen. Abgesehen davon wird das Ergebnis durch Ignoranz des Wachstums verfälscht. Insofern kann sich jeder den Faktor auf 1 setzen. Die Erklärung kann trotzdem für Erleuchtung sorgen. Aber, ist ja Dein Tool :smiley:

0.000005 * 10^-5 = 0.05 * 10^-9

(Deine Vorschläge sind größtenteils umgesetzt :slightly_smiling_face:)

Ein zusätzlicher Hinweis lässt einen jetzt direkt den Faktor für eine exponentiell ansteigende Hashrate setzen (abhängig vom gewählten Zeitraum, Verdoppelung alle 2 Jahre).

Ich bin mir allerdings grade etwas unsicher, ob das so Sinn ergibt @skyrmion?

Also z.B. bei 10 Jahren würde man den Faktor 25 = 32 und bei 50 Jahren den Faktor 225 = 33 554 432 nehmen?

2 „Gefällt mir“

Rechnerisch passt es auf jeden Fall. Über den Wert könnte man lange diskutieren, aber ich finde Moore’s Law als Basis eine sehr gute Idee!

In den letzten 5 Jahren ist die Hashrate ungefähr um den Faktor 8…9 gestiegen. Moore’s Law würde für diesen Zeitraum einen Faktor 5,7 ergeben; passt also ganz gut.
Außerdem steigt die Hashrate auch nicht exakt exponentiell. In den letzten 5 Jahren war das zwar in sehr guter Näherung so. Aber im gesamten Zeitraum nach der Einführung der ASICS verläuft die Hashrate eher leicht abflachend ggü. eines exponentiellen Anstiegs. Also ist ein leicht geringerer Wert für den unterstellten zukünftigen exponentiellen Anstieg im Vergleich zu den letzten Jahren sinnvoll; z.B. eben die Verdopplung alle zwei Jahre.

Vielleicht wäre es generell sinnvoller nicht den Gesamtfaktor zu verwenden, sondern einen Jahresfaktor. Also den Faktor, um den sich die Hashrate jedes Jahr erhöht. Das wäre auch für die User einfacher.

Die Formel würde dann folgendermaßen aussehen:

P = 1 - \text{e}^{-\frac{H_{solo}}{H_{rest}}\frac{1-b^{-N}}{1-b^{-1}}} = 1 - \text{e}^{-\frac{H_{solo}}{H_{rest}}\frac{1-j^{-N/52560}}{1-j^{-1/52560}}} = 1 - \text{e}^{-\frac{H_{solo}}{H_{rest}}\frac{1-j^{-t/1y}}{1-j^{-1/52560}}}

N : Anzahl der Blöcke (z.B. 52560 für ein Jahr)
j : Faktor, um den die Hashrate des restlichen Netzwerks pro Jahr wächst
b : Faktor, um den die Hashrate des restlichen Netzwerks pro Block wächst (j=b^{52560}; b=j^{\frac{1}{52560}})
t : Zeit in Jahren

Der User trägt also z.B. j ein (Default \sqrt{2} \approx 1,41). Ich würde dann ausgehend von j zuerst b=j^{\frac{1}{52560}} berechnen und dieses dann in die erste Formel einsetzen, welche ich am schönsten und natürlichsten finde. Du kannst dir aber eine aussuchen.

Sehr interessant ist außerdem, dass die Erfolgswahrscheinlichkeit mit langer Laufzeit ganz offenbar asymptotisch gegen einen Grenzwert läuft. Im Zähler 1- b^{-N} des Bruches wird b^{-N} mit steigendem N irgendwann wesentlich kleiner als 1.
Das ist auch nicht verwunderlich, wenn die restliche Hashrate im Vergleich zur eigenen stetig exponentiell steigt.
Bei einem Anstieg nach Moore’s Law ist der Term für ein Jahr b^{52560} = j \approx 1.41, also b^{-52560} \approx 0,71. Für zehn Jahre ist bereits b^{-10\cdot52560} \approx 0,03, ist also im Zähler des Bruches schon fast vernachlässigbar.
D.h. falls die restliche Hashrate dauerhaft nach Moore’s Law ansteigt, lohnt es sich kaum über zehn Jahre hinaus zu minen. Die Gesamt-Erfolgswahrscheinlichkeit ändert sich dann nur noch im Prozentbereich.

Die Erfolgswahrscheinlichkeit steigt also mit längerem Mining immer weiter an, ändert sich aber nach einigen Jahren kaum noch und liegt immer unter einem Maximalwert, der nicht überschritten werden kann. Dieser beträgt nach Vernachlässigung von b^{-N} im Zähler:

P_{max} = 1 - \text{e}^{-\frac{H_{solo}}{H_{rest}}\frac{1}{1-b^{-1}}} = 1 - \text{e}^{-\frac{H_{solo}}{H_{rest}}\frac{b}{b-1}}

Bei einem Anstieg nach Moore’s Law wäre b \approx 1,00000659389 und damit:

P_{max} \approx 1 - \text{e}^{-151657\frac{H_{solo}}{H_{rest}}} \approx 151657\frac{H_{solo}}{H_{rest}}

(die letzte Näherung gilt für nicht allzu große Solo-Hashrate)

D.h. bei einem zukünftigen Anstieg nach Moore’s Law erreicht man selbst bei ewigem Mining nur die gleiche Erfolgswahrscheinlichkeit, wie bei ca. 3 Jahren Mining mit konstanter Gesamthashrate.

Noch kurz zu deinem Recher…

Ich habe bisher kaum herumgespielt, hätte aber noch folgende Anmerkungen:

  • Mir ist aufgefallen, dass dein Rechner im Feld „Expected hashrate increase (by factor)“ entweder gerundet anzeigt, oder wirklich nur mit Integers rechnet. Zumindest die Rechnung würde ich allerdings genauer durchführen. Bei Anzeige eines Jahresfaktors würde ich dann auch wenigstens zwei Nachkommastellen anzeigen.

  • Das Feld „Expected hashrate increase (by factor)“ würde ich vielleicht noch ergänzen zu „Expected hashrate increase for total lifetime (by factor)“.
    Falls du dich für den Wechsel zu einem Jahresfaktor entscheidest, dann „Expected hashrate increase per year (by factor)“.

  • Auf dem Smartphone kann man mit dem Finger nicht über die Fragezeichen hovern, sondern nur darauf tippen, was zu einer sehr kurzen Anzeige führt.

  • Da du schon Javascript verwendest, könntest du theoretisch die exakten Werte iterativ berechnen. Also eine Schleife, welche die einzelnen Wahrscheinlichkeiten pro Block aufmultipliziert: 1 - P_{kein \,Erfolg\,Block\,1} \cdot P_{kein \,Erfolg\,Block\,2} \cdot \, ... \, \cdot P_{kein \,Erfolg\,Block\,N-1}
    Die einzelnen Wahrscheinlichkeitswerte wären jeweils einfach Rest-Hashrate / (Rest-Hashrate + Solo-Hahsrate), wobei du die Rest-Hashrate eben in jedem weiteren Block mit dem Faktor b ansteigen lassen müsstest.
    Meine Formel stimmt in allen realistischen Szenarien, selbst für größere Mining-Anlagen. Aber falls jemand irgendwelche Extremwerte testet, liefert eine exakte Rechnung halt den exakten Wert.

5 „Gefällt mir“

Erstmal danke für die Mathe-Vorlesung!

Also man kann da schon Kommazahlen eingeben und mit denen wird dann auch gerechnet. Wenn man Moore’s Law anklickt kommt halt immer eine glatte Zahl, da ich bei ungeraden Jahresangaben einfach nach unten Runde.

Ich werde das aber definitiv auf einen Jahresfaktor umstellen und dann schöner lösen. Alleine schon weil es halt einfach naheliegender ist.

Joah, Bootstrap… xD

Die Tooltips hatten nach rechts teilweise keinen Platz, daran lags wahrscheinlich und sollte jetzt gefixt sein.

Aber dann wäre doch der Flex mit der geschlossenen Formel weg… ;)

3 „Gefällt mir“

Ich habe die Formel oben nochmal minimal angepasst. Am Ergebnis ändert das praktisch nichts, aber sie ist jetzt minimal genauer.

Die endgültige Fassung lautet:

P = 1 - \text{e}^{-\frac{H_{solo}}{H_{rest}}\frac{1-b^{-N}}{1-b^{-1}}}

P : Erfolgswahrscheinlichkeit
H_{solo} : Hashrate des Solominers
H_{rest} : Hashrate des restlichen Netzwerks zu Beginn (≈ Gesamthashrate)
N : Anzahl der Blöcke (z.B. 52560 für ein Jahr)
b : Faktor, um den die Hashrate des restlichen Netzwerks pro Block wächst (j=b^{52560}; b=j^{\frac{1}{52560}})
j : Faktor, um den die Hashrate des restlichen Netzwerks pro Jahr wächst

Auf diese Version kommt man viel einfacher und nur mit einer einzigen Annahme, nämlich H_{solo} \ll H_{rest}, wenn man die Herleitung von Anfang an mit b durchrechnet.

1 „Gefällt mir“

Habe jetzt auf einen jährlichen Faktor für die Hashrate umgestellt. (Und natürlich die neue Version der Formel genommen). :slight_smile:

Der Default ist √2. Im Input wird einem 1,41 angezeigt, aber im Hintergrund wird der genauere Wert vom Math Objekt genommen. Auch wenn man manuell 1,41 nachträglich eintippt.

Mit einer Checkbox kann man zurück zur konstanten Hashrate wechseln, der Faktor ist dann 1, und im Hintergrund wird die Formel in dem Fall erst gar nicht genutzt für ein möglichst exaktes Ergebnis.

Die ersten Tests liefern sinnvolle Ergebnisse, muss aber nichts heißen. Also bitte mit Vorsicht genießen und nach Bugs Ausschau halten. :sweat_smile:

3 „Gefällt mir“

:+1:

In der Herleitung der Formel gibt es eine Fallunterscheidung. Für den Fall b \neq 1, also veränderliche Hashrate, ergibt sich unsere Formel von oben (s.a. (iii) weiter unten). Für den Fall b=1, also konstante Hashrate, ergibt sich die gleiche Formel, nur mit einem Faktor N statt des Bruches:

P = 1 - \text{e}^{-\frac{H_{solo}}{H_{rest}} N} \tag{i}

Es ist also richtig, den Fall b=1 in der Berechnung gesondert zu behandeln. Allerdings würde ich stattdessen nicht einfach in jedem Fall die folgende Formel verwenden, so wie es aktuell im Rechner implementiert ist:

P = \frac{H_{solo}}{H_{rest}} N \tag{ii}

Das hat den Nachteil, dass die unterjährigen Werte (Per day, Per year) erstens bei großer Hashrate grob daneben liegen und zweitens den Wert 100% erreichen können, ab dem dann einfach abgeschnitten wird (z.B. bei 10x S19 Pro 15% statt 14%, bei 100x S19 Pro dann begrenzt auf 100%).

Die Formel (ii) ist schließlich auch nur eine Näherung für den Fall \frac{H_{solo}}{H_{rest}} N \ll 1.

Die Formel (i) hingegen ist eine Näherung für den Fall \frac{H_{solo}}{H_{rest}} \ll 1. Sie ist also für N > 1 rein mathematisch gesehen genauer als (ii). Allerdings macht die e-Funktion bei zu kleinen Exponenten numerisch Probleme (zumindest in Excel :see_no_evil:).

Ich würde also für den Fall b = 1 folgendes machen:
Nur falls der Exponent \frac{H_{solo}}{H_{rest}} N so klein ist, dass die e-Funktion numerisch Probleme macht, würde ich die ganz einfache Formel (ii) verwenden, ansonsten (i). Auch bei den unterjährigen Werten.
Bei welchem Wert man da am besten wechseln sollte weiß ich nicht, evtl. bei \frac{H_{solo}}{H_{rest}} N = 10^{-8}.

Für den Fall b \neq 1 würde ich ähnlich vorgehen:
Nur falls der Exponent \frac{H_{solo}}{H_{rest}}\frac{1-b^{-N}}{1-b^{-1}} so klein ist, dass die e-Funktion numerisch Probleme macht (z.B. 10^{-8}), würde ich die Formel (iv) verwenden, ansonsten (iii). Auch bei den unterjährigen Werten.

P = 1 - \text{e}^{-\frac{H_{solo}}{H_{rest}}\frac{1-b^{-N}}{1-b^{-1}}} \tag{iii}
P = \frac{H_{solo}}{H_{rest}}\frac{1-b^{-N}}{1-b^{-1}} \tag{iv}

Aktuell wird der Hashrate-Increase bei den unterjährigen Werten gar nicht berücksichtigt. Das ist z.B. sehr verwirrend wenn man als „Time to live“ auch 1 Jahr einstellt und dann unten unterschiedliche Ergebnisse bei ''Per year" und „In your lifetime“ sieht.

Muss man natürlich alles nicht so machen, sind nur Hinweise… :slight_smile:

Evtl. gibt es die numerischen Probleme bei dir auch gar nicht. Dann würde ich immer bei den Formeln mit der e-Funktion bleiben.

Ansonsten noch ein paar Anmerkungen zum Rechner:

  • Die Formeln (iii) und (iv) funktionieren allgemein für b \neq 0 \land b \neq 1. Man könnte also auch den Bereich 0<b<1 im Rechner zulassen, falls jemand annimmt, dass die Hashrate in den nächsten Jahren fällt. Aktuell erhält man ja generell für b<1 die Meldung „BITCOIN IS GOING TO ZERO?!“. :grin:

  • Die Meldung „You are certainly not dead yet!“ sollte nur bei „Time to live“ < 0 kommen. Sie kommt aber auch schon bei „Time to live“ < 1.

  • Den „Time to live“ Defaultwert von 72 Jahren finde ich persönlich zu hoch. Bei einem stetigen Hashrate-Anstieg macht es aus wirtschaftlichen und technischen Gründen keinen Sinn, länger als einige Jahre zu minen. Selbst aus Spaß wird man einen Nerd-Miner wahrscheinlich keine 72 Jahre betreiben.

1 „Gefällt mir“

Jepp, sehe ich genauso, da der Altersmedian nicht bei 18-28 liegt. Da es sich eh um keine logisch herleitbare Zahl handelt, fände ich eine 21 oder 42 ganz schön. Hätte zumindest irgendeinen Bezug :slight_smile:

1 „Gefällt mir“

@sutterseba, ich glaube ich war vorhin noch etwas zu müde.

Für den Fall b = 1 kann man ja einfach direkt die exakte Formel verwenden, unabhängig von den Hashrate-Verhältnissen und Laufzeiten:

P = 1 - (\frac{H_{rest}}{H_{rest} + H_{solo}})^{N}

Evtl. hattest du das weiter oben mit „exaktem Ergebnis“ gemeint und hast das auch so für den Fall b = 1 implementiert. Falls nicht, würde ich das genau so machen. Ist schließlich genau der exakte Wert, ohne jegliche Näherung. Es gibt für b = 1 keinen Grund, sich zwischen irgendwelchen Näherungsformeln zu entscheiden.

Im Fall b \neq 1 würde ich dann aber so vorgehen, wie im vorherigen Beitrag beschrieben.

Außerdem würde ich wie gesagt bei b \neq 1 auch für die unterjährigen Werte „Per day“ und „Per year“ die Formeln mit b verwenden, damit es nicht verwirrend ist.

1 „Gefällt mir“

Okay, nochmals danke für den super Input! :)

Habe die Berechnung jetzt etwas vereinheitlicht und ausgelagert:

  • Für b = 1 (oder auch N = 1) wird exakt berechnet, ansonsten Formel (iii) benutzt. Jetzt auch für die beiden anderen Zeiträume (wird einfach über das N übergeben).

    Gibt man als Zeithorizont 1 an, bekommt man für Per Year und In your lifetime also, wie man auch erwarten würde, das gleiche Ergebnis. (Auch wenn es natürlich sinnlos ist, diesen Zeitraum überhaupt zu wählen).

  • Ein Faktor zwischen 0 und 1 ist jetzt auch möglich, warum auch nicht. :smiley:

  • Der Zeitraum kann jetzt auch unter einem Jahr festgelegt werden, also wenn man z.B. den Wert für 6 Monate haben will, ist das auch möglich. Ist dann halt etwas trocken, dass ein Zeitraum von ein paar Monaten als „Your lifetime“ bezeichnet wird, aber egal. xD

  • Den Default für den Zeitraum hab ich jetzt einfach mal auf 10 Jahre gesetzt. Ist in meinen Augen eine realistische und runde Zahl.

2 „Gefällt mir“

Gerne, macht ja Spaß!

Ich will dich nicht verrückt machen! Aber ich hätte noch zwei gute Nachrichten und eine schlechte. :see_no_evil:

Erst mal eine gute:

Die ganzen Anpassungen finde ich super und (fast) alles funktioniert! :slight_smile:

Jetzt die schlechte (aber keine Angst):

Der Rechner hat bei kleiner Solo-Hashrate H_{solo} genau das Problem mit dem Genauigkeitsverlust, das ich weiter oben angesprochen hatte. Unterhalb von ca. 40 kH/s geht gar nichts mehr. Darüber wird es erst etwas ungenau und bei größerem H_{solo} dann immer besser.

In beiden verwendeten Formeln ist die Ursache die gleiche. Nämlich dass die Summe einer großen und einer kleinen Double Zahl verarbeitet werden sollen.

P = 1 - (\frac{H_{rest}}{H_{rest} + H_{solo}})^{N} \tag{1}
P = 1 - \text{e}^{-\frac{H_{solo}}{H_{rest}}\frac{1-b^{-N}}{1-b^{-1}}} \tag{2}

In Formel (1) erhält man bei kleinem H_{solo} für den Bruch eine Zahl, die fast exakt 1 ist und erst weit hinter dem Komma wieder Stellen ungleich 9 hat (z.B. 0.99999999999245).
Da das Double Format nur ca. 16 Stellen Genauigkeit zulässt, wird alles dahinter unterschlagen. Ist H_{solo} also um mehr als 16 Größenordnungen kleiner als H_{rest}, wird der Bruch einfach 1 und P = 0.

In Formel (2) erhält man bei kleinem H_{solo} und kleinem N für den Exponenten eine Zahl, die fast exakt 0 ist und erst weit hinter dem Komma wieder Stellen ungleich 0 hat (z.B. -0.0000000000245).
Das Potenzieren mit Basis \text{e} entspricht bei kleinen Zahlen x näherungsweise \text{e}^{x} \approx 1 + x. Wieder erhält man also die Summe einer großen Zahl 1 und einer sehr kleinen Zahl x. Ist der Exponent x kleiner als 10^{-16}, wird im Double Format \text{e}^{x} \approx 1 + x = 1, also P = 0.

Man muss es also vermeiden Zahlen zu addieren, deren Größenordnung sich um mehr als die Double-Genauigkeit unterscheidet.

Jetzt die abschließende gute Nachricht:

Die Klasse Math biete extra hierfür die Methode Math.expm1() an, welche nicht \text{e}^{x} \approx 1 + x berechnet, sondern direkt \text{e}^{x} -1 \approx x. Da wir am Ende für P sowieso immer die Differenz zu 1 berechnen müssen, passt dass hervorragend.

Meine Problembeschreibung findet sich übrigens so ähnlich auch unter „Description“ in der Doku der beiden Methoden:
Math.exp() - JavaScript | MDN
Math.expm1() - JavaScript | MDN

Wir müssen also doch die beiden ursprünglichen Formeln heranziehen…

P = 1 - \text{e}^{-\frac{H_{solo}}{H_{rest}}N} \,\,\,\,\,\,\, für \,\,\,b = 1 \tag{3}
P = 1 - \text{e}^{-\frac{H_{solo}}{H_{rest}}\frac{1-b^{-N}}{1-b^{-1}}} \,\,\,\,\,\,\, für \,\,\,b \neq 1 \tag{4}

… wobei wir aber statt 1 - Math.exp(x) direkt - Math.expm1(x) verwenden.

function calculateChance (local, N, b) {
    if (b === 1) {
        return (- Math.expm1(-(local/hashrate) * N)) * 100;
    }
    return (- Math.expm1(-(local/hashrate) * (1 - Math.pow(b, -N)) / (1 - Math.pow(b, -1)))) * 100;
}

Damit ist der Rechner bei sehr kleinen bis zu realistischen großen Werten genau.

4 „Gefällt mir“

Im Gegenteil, keine Sorge… :grin:

Das ist mir bei besonders kleinem Hashrate Input vorhin auch schon aufgefallen. Ich habe auch schon angefangen/versucht auf die simple Formel (ii) zurückzugreifen, sobald ich an die Grenzen von JS stoße – hattest du ja oben auch schon angesprochen. War da aber noch nicht zufrieden, weil ich mir nicht sicher war, diese „Grenze“ richtig gezogen zu haben. Nach etwas Verwirrung hatte ich dann erstmal keine Lust mehr für heute…

Aber diese Extrawurst-Methode von Math ist natürlich die Traum-Lösung!

Habe dich auch mal in die Credits unten gepackt, hoffe das passt. Ohne dein Feedback wäre der Rechner sicherlich nicht so genau geworden. :slight_smile:

Ich wache morgen früh also mit einer Wahrscheinlichkeit von 1 zu 173.178.949.625.514 um 6,25 BTC reicher auf. Wehe der Wert ist nicht genau!

2 „Gefällt mir“

Ich habe gerade versucht, in Deinem Rechner mit 0,527 TH/s zu rechnen. Das kam dabei heraus:

Solltest du dann nicht besser die Einheit wechseln? Wenn ich 527 GH nehme geht es.

1 „Gefällt mir“

Das war auch mein Workaround. Ich frage mich jedoch, wie viele dazu in der Lage sind? Ich würde auf eher weniger tippen.

Joa,

zwei Dinge,

  • Ich habe auch einmal 1,5 getestet, ist kein Problem, liegt also wie bei der Livetime nur daran das der Wert <1 ist.

  • wenn ich auf meinem Handy den Wert lösche und neu Schreiben möchte, steht mir kein Komma sondern nur ein Punkt zur Verfügung.
    Kann leider kein Screenshot machen aber das Komma ist ausgegraut.
    Der Rechner funktioniert aber trotzdem ohne Problem.

Genau, bei der Lifetime kann man unterjährige Werte angeben.

Die lokale Hashrate darf jetzt auch < 1 sein. Daran habe ich gar nicht gedacht, da man dafür schließlich die Einheiten hat.

Ich bin übrigens auch auf die durchschnittliche Hashrate der letzten Woche umgestiegen, da mir der tägliche Wert doch etwas zu sehr geschwankt hat. Schön wäre vielleicht noch dem Nutzer hier eine Auswahl zu geben.

Mit iOS kein Problem. Das ist halt ein ganz normaler Input-Tag mit Typ „Number“. Keine Ahnung was Android-Version XYZ daraus macht.

Dass nur ein Punkt verfügbar ist, macht allerdings sogar Sinn. Was die Seite betrifft ist es aber völlig egal, ob man , oder . nutzt.

2 „Gefällt mir“