Topic: Wie wird sich die Netzwerk-Hashrate entwickeln? - page 2. (Read 5369 times)

Wir können ja wetten abschließen ob vmc scam ist oder nicht   brauchen nur ein escrow.  Ich bin mit 10btc gegen vmc.

das FastHash Modul sieht aus wie ein Avalon Modul finde ich.

Hmm... VMC. Noch nie war ich mir bei nem Bitcoin Unternehmen so unsicher ob das nun echt oder ein richtig geschickter scam ist. Wenn ich mir KSlaughter anschaue gehn bei mir schon einige Alarmglocken los. Andererseits präsentiert er auch immer wieder Fakten die zeigen, dass er wohl wirklich ein ASIC entwickeln lässt.

Bin gespannt wohin das geht. Wenn echt ist würde das einige Konkurrenten alt aussehen lassen, wenns ein Scam ist würde wohl selbst Pirate daneben wie ein kleiner Fisch wirken/ naja oder zumindest in der gleichen Liga.

Leute, schaut euch mal hier das Auslieferungsdatum an:

http://virtualminingcorp.com/shop1/index.php?id_product=10&controller=product&ad=3

Ist das ernst gemeint?
Ich dachte, VMC würde noch ewig brauchen, bis die soweit sind.

Könnte sein, dass die Hashrate doch heftiger ansteigt...

Diese Aussage hat mich zum Rechnen veranlasst.
Mein Bauchgefühl sagt mir nämlich, dass die Schwankungen im 8-Stunden-Durchschnitt nicht auf den Tag-Nacht-Rhythmus der Miner zurückzuführen sind, sondern einfach nur durch die ganz normale Stichprobenvarianz hervorgerufen werden.

Die Mathematik zeigt, dass ich Recht hatte.

Dazu habe ich zuerst ein paar Variablen eingeführt:

Die nominale Hashrate, d.h. die Hashrate, die den Schwierigkeitsgrad bestimmt: nominal_hashrate
Die tatsächliche Hashrate zu einem bestimmten Zeitpunkt: actual_hashrate
Die Hashrate innerhalb einer Stichprobe: sample_hashrate
Anzahl Hashes in einer Stichprobe: n_hashes
Die nominale Blockrate, d.h. der Erwartungswert der Blockrate bei nominaler Hashrate: nominal_blockrate
Anzahl Blöcke in einer Stichprobe: n_blocks
Die Dauer der Stichprobe: time
Die Wahrscheinlichkeit, mit einem Hash einen Block zu finden: probability
Der Erwartungswert einer Variablen: expectation(_)
Die Standardabweichung einer Variablen: deviation(_)
Die relative Standardabweichung einer Variablen: relative_deviation(_)

Durch das Bitcoin-Netzwerk ist diese Konstante festgelegt:

nominal_blockrate = 1/600

Allgemein gilt:

hashrate = n_hashes/time
blockrate = n_blocks/time
expectation(n_blocks) = n_hashes*probability
variance(n_blocks) = n_hashes*probability*(1 - probability)
deviation(_) = variance(_)^(1/2)
relative_deviation(_) = deviation(_)/expectation(_)

Daraus folgt:

probability = nominal_blockrate/nominal_hashrate
deviation(n_blocks) = (n_hashes*probability)^(1/2)*(1 - probability)^(1/2)
sample_hashrate = n_blocks/probability/time

Wenn man das alles zusammenpackt, ergibt sich:

relative_deviation(sample_hashrate) = (nominal_hashrate/actual_hashrate*600/time)^(1/2)*(1 - 1/600/nominal_hashrate)^(1/2)

Das ist leider eine sehr unhandliche Formel.
Deshalb wird gerundet:

relative_deviation(sample_hashrate) ~= (nominal_hashrate/actual_hashrate*600/time)^(1/2)

Das ist schon besser, aber immer noch unpraktisch, weil man die tatsächliche Hashrate ja gar nicht kennt.
In der Praxis wird man also einen geschätzten Wert eintragen.
Dabei bietet es sich an, die nominale Hashrate zu benutzen, weil sich das ganze dann nochmal vereinfachen lässt:

relative_deviation(sample_hashrate) ~= (600/time)^(1/2)

Das kann man dann auch als Prozentzahl schreiben:

relative_deviation(sample_hashrate) ~= (600/time)^(1/2)*100%

Das heißt:
Wenn man eine Stichprobe macht, die time Sekunden dauert, dann muss man damit rechnen, dass die gemessene Hashrate um (600/time)^(1/2)*100 Prozent von der tatsächlichen Hashrate abweicht.

Ein paar Beispielwerte:

• Wenn man nur eine Stunde misst, dann beträgt die Ungenauigkeit der Messung etwa 41 Prozent. Das Ergebnis eignet sich also höchstens um die ungefähre Größenordnung der Hashrate abzuschätzen.
• Wenn man nur 8 Stunden misst, dann hat man immer noch eine Ungenauigkeit von etwa 14 Prozent.
• Bei einer eintägigen Messung ist es schon besser, dann hat man eine Ungenauigkeit von etwa 8.3 Prozent.
• Beim 3-Tage-Durchschnitt hat man eine Ungenauigkeit von etwa 4.8 Prozent.
• Der 7-Tage-Durchschnitt hat eine Ungenauigkeit von etwa 3.1 Prozent und ist wohl der beste Durchschnitt, den man berechnen kann, ohne das Zeitfenster unrealistisch groß zu machen.

Die 14% varianzbedingte Abweichung beim 8-Stunden-Durchschnitt kann man also nicht so einfach mit Minern begründen, die nachts ihre Geräte abstellen.

Das bedeutet auch, dass wenn es bei unserer Wette so knapp wird, dass es auf die 8% ankommt, dann können wir bis zum letzten Tag nicht wissen, wer gewonnen hat; es bleibt also spannend.

Wenn das stimmt dann wird die difficulty schon bald sehr stark ansteigen:
http://thegenesisblock.com/latest-shipment-of-avalon-asics-could-increase-network-hashrate-by-500/

Sollte es sein, ist es augenscheinlich aber nicht. Ich tippe auf ein Problem des Scripts nach einem Difficulty-Change...

IMHO kommen die Schwankungen beim 8-hour auch eher von den Minern, welche ihre Rigs nicht 24/7 laufen haben. Luck hin, Luck her, 8*7.5 Blöcke sind schon eine Menge Holz.

Qkos Services Ltd.

Ich wette, es gab da schon mal eine Downtime. Ob's ein Backup gibt, weiß ich nicht, aber es wären Anfänger, wenn sie kein's hätten.

Naja, 60 Minuten ist viel zu kurz um einen Mittelwert zu bestimmen.

Es kommt ja des öfteren mal vor, dass in 60 Minuten nur 1 Block gefunden wird, oder eben gleich 10.
Da ist die Varianz viel zu groß, sodass man das nicht mehr "Hashrate" nennen kann.

Ich finde es schon recht ungenau, wenn man nur 24 Stunden für den Mittelwert heranzieht. Da hat man nämlich auch schon sehr viel Varianz.

Hier ist eine schöne Grafik:


Also der Wert vom "8-hour window estimate" ist ja ziemlich unbrauchbar, weil durch Varianz verfälscht.

"1-day window estimate" geht gerade so, einige verfälschende Ausrutscher durch die Varianz kann man aber noch erkennen.

"3-day window estimate" sieht mir in dieser Grafik am realistischsten aus, wobei ich normalerweise das "7-day window estimate" verwende, das hier leider nicht eingezeichnet ist.


Ich bin gerade noch am Suchen und Vergleichen, welche Zahlen jetzt bei bitcoincharts.com/bitcoin stehen.
Vielleicht ist es das "1-day window estimate"?

Ist nur eine Vermutung: der obere Wert scheint sich an den gefundenen Blöcken der letzten Stunde zu orientieren. Der untere an denen der letzten 24 Stunden. Somit dürfte der obere Wert stärker schwanken...

Oh, das hab' ich übersehen.

Weiß du zufällig auch wie die Hashrate bei http://bitcoincharts.com/bitcoin bestimmt wird?
Danach richten sich ja viele Leute, es steht aber nicht da wie die rechnen.

Vor allem weil's dort gleich zwei Zahlen gibt: Rechts oben, und weiter unter nochmal, und die sind meistens unterschiedlich.

wer betreibt eigentlich blockchain.info?
und war die Seite schon mal down bzw. gibt es Ersatz/backup?
TIA

Bei http://blockchain.info/stats steht's im Kleingedruckten: 'All statistics are for the previous 24 hour period unless otherwise stated'. Beim Durchschnitt der letzten 24 Stunden kann man IMHO schon großzügig von einer 'aktuellen Hasrate' sprechen.

Hmm, ja, jetzt hast du mich erwischt.
Also die Daten, die in die Difficulty einfließen, können bis zu 4032 Blöcke alt sein, also rund 28 Tage, durchschnittlich sind's aber nur rund 14 Tage.

Die aktuelle Hashrate im wortwörtlichen Sinne lässt sich aber gar nicht bestimmen, das ist ja das Problem an der Varianz. Man kann sich ja nur die letzten X Zeiteinheiten anschauen, zählen wieviele Blöcke da gelöst wurden und daraus den X-Mittelwert berechnen.
Es ist ein bisschen wie Quanten-Physik: Da kann man auch nicht alles genau messen.

Ich bin gerade von den ganzen Webseiten ein bisschen enttäuscht, weil die immer eine Hashrate angeben, ohne zu sagen, welches X sie gewählt haben.
Die einzige Seite, die da professionell vorgeht ist http://bitcoin.sipa.be/ - aber leider sind das nur Charts, und sich da was aus den Charts abzulesen ist auch ein ziemlicher Fummelkram.





Also dann nehme ich letztlich doch deinen Vorschlag an: http://blockchain.info/stats ist die Referenz.

Und dann haben wir ja noch genug Zeit, herauszufinden, welchen Mittelwert die eigentlich verwenden.

Keine Angst, sollte die Hashrate gegen 19:00 Uhr um 5 PHash/s liegen, schalte ich meine 8 PHash/s nicht dazu. Versprochen.

Nunja, diese Kleinigkeit kann schon 25% ausmachen. Unsere Difficulty gibt ja die durchschnittliche Hashrate der 2016 Blöcke vor dem letzten Difficulty-Change wieder. Wir sprechen hier aber über die aktuelle (bzw. zukünftig aktuelle) Netzwerkhashrate, oder?

Wenn dem so ist: deal!

Ich mag blockchain.info nicht.

Die aktuelle Difficulty ist zum Glück auf jeder Seite gleich, weil sie in der echten Blockchain abgespeichert ist, und mit der Formel...

Hashrate [ PH/s ] = Schwierigkeitsgrad * 2^32 / 600 / 10^15

...kann man das in die durchschnittliche Hashrate in PH/s während der letzten 2016 Blöcke umrechnen... Das ist dann praktisch ein 14-Tage-Durchschnittswert, der also weniger schwankt als die blockchain.info-Zahlen.


Naja, gut, das sind Kleinigkeiten^^

Also Wetteinsatz 0.1 BTC, ich bin dabei.

Durch diese Medienaufmerksamkeit würde der Bitcoin-Kurs stark steigen. Mit einer gewissen Verzögerung wirkt sich der Bitcoin-Kurs auf die Hashrate aus. Dadurch wird der Wettgegenstand verfälscht.

Warum nicht? Du tippst auf 5 PH/s, meine Wenigkeit auf 13 PH/s. Wer am 16.04.2014 (20:00 Uhr CEST, Referenz für die Hashrate: http://blockchain.info/stats) näher dran ist, hat gewonnen.

Ich würde just 4 fun sogar 0.1 BTC als Wetteinsatz einbringen.

Hey! Damit kannst du ja schon bei "Wetten Dass...?" auftreten.
Für den dummen Zuschauer muss man das ganze nur ein wenig interessanter machen bzw ausschmücken und irgendwelche B Promis einladen.

Ich hatte mit einer anderen aktuellen Hashrate gerechnet, deshalb kam ich auf nur 11 PH/s.

Hab' mich jetzt nochmal mit der Sache beschäftigt, und meine Glaskugel sagt mir jetzt doch einen kleineren Anstieg voraus.

Also für den 16.04.2014 komme ich auf rund 5 PH/s.

Wette?