Minen kann nicht einfacher oder erfolgreicher werden, weil das Netz die diff anpasst um die Menge der generierten Blocks (und damit BTC) pro Zeiteinheit auf einem Wert zu halten.
Jeder Miner konkurriert mit allen anderen um diesen Pott, und wenn einer anteilsmäßig viel Hashleistung hat, bekommt er genau diesen Anteil an den erzeugten BTC, statistisch. Etwas Glück ist drin, aber grundsätzlich und auf längere Zeit gesehen ist das einfach eine Torte mit verschieden großen Stücken.
Wenn nun jemand mehr Leistung ins Netz stellt, so
- erhöht er seinen Anteil, und damit die anteilige Ausschüttung, die Anteile der anderen werden weniger (es gibt halt nur 100% Summe)
- allerdings steigt die Gesamtleistung auch
- daher passt das Netz die Diff an und der Ertrag pro Stunde sinkt wieder, weil Hashleistung weniger wert ist.
Daher wird die HL immer weiter aufgepustet: "jeder" Miner ist gierig und will mehr dollars -> mehr HL aufstellen -> diff höher -> mehr TH/s trotzdem nur gleiche $$$ -> vorne anfangen
Du würdest jetzt mit deiner Optimierung "nur" deinen Miner mit mehr Leistung ausstatten und damit dein Tortenstück größer machen -> die anderen bekommen weniger -> HL wird aufgestellt -> du musst mitziehen.
Da du jetzt nicht soooo großartig viele GH/s hast, wird erstmal nix passieren, und wenn alle dein System nutzen, sind es doch wieder die gleichen Verteilungen, nur eben nicht mit "20GH/s pro Kiste" sondern mit "200 Schlumpf-GH/s pro Kiste"
aber der Kuchen ist eben nicht 200000GH groß sondern 2000000 Schlumpf-GH. Dein Anteil bleibt gleich, wie jeder andere auch.
Es müsste also "jemand" mit massiver Leistung mit deiner Optimierung massiv dazugewinnen, damit er bis zur Verbreitung des Systems im Vorteil gegenüber den anderen wäre. Danach wären alle gleich schlau.
Und jetzt zu deinen Ausführungen:
Du willst die (jetzt zufällig besetzte) Nonce vorberechnen, um die W-Kurve zu treffen, das würde die Erzeugung einer gültigen SHA abkürzen. Soweit war ich vorher schon.
Allein: Der Beweis fehlt, das es so einen Vorteil geben würde.
Also:
Schreib ein Programm, das für einen beliebigen Block an Daten (nix BTC, einfach so!) eine nonce findet, ebenso wie BTC das tut.
Schreib ein zweites, das die W-Kurve vorberechnet.
Lass beide 100000-Mal eine Nonce für einen zufällig gewählten Block an Daten finden, aber für beide Programme den jeweils gleichen Block!
Schau, wie viele Versuche BTC braucht, und wie viele deine Version.
Wenn deins in der Summe x% weniger braucht, hast du einen Vorteil von x%.
Implementier das Verfahren in deinen Bitcoin-Core und mine fröhlich los. Oder CGMiner auf AMD. Oder so. Werd reich.
Ich bin sicher, das genau diese Idee schon von fähigen Kryptologen durchgeführt wurde, und ich bin genau so sicher, das selbst wenn so eine Schwäche a) durchführbar und b) vorhanden ist, es trotzdem nicht möglich ist den Aufwand wesentlich zu reduzieren.
Das h verloren geht ist richtig, denn h ist ein Wert, der vor dem Hashen vorbesetzt wird und dann als Rechenregister benutzt wird. Dabei wird h immer wieder neu verwürfelt.
Deine negative Null erklärt sich mir nicht, aber ich bin beinah sicher, das es ein signed/unsigned-Problem ist, oder einfach eine Vermeidung von Nullbytes.
Die W-Kurve hängt wesentlich von den ersten 16 Worten des jeweiligen Blocks ab, aber die ändern sich ja. Und von 16 32bittigen Werten (immerhin 512 bit) letztendlich die Nonce-Wahrscheinlichkeiten für bestimmte Zahlen vorzuberechnen, ist m.E. unmöglich. Du müsstest ja quasi alle Werte durchzählen, die entsprechende Wahrscheinlichkeit errechnen und in eine Tabelle stecken, die dann sortieren und dann wieder durchgehen um die jeweilige Nonce zu prüfen. Sollte rein aufgrund des Speicherplatzes unmöglich sein. Es mag andere Algo's geben, aber mir fiele keiner ein. Ich denke nicht, das es möglich ist via Fourier die Kandidaten in absteigender Wahrscheinlichkeit abzugeben, denn wenn deine "Formel" nur ein Bit danebenliegt klappt es nicht.
Testest du 1 Bit "Reichweite", vervielfacht sich ja schon die anzahl der Tests, anstelle einer Nonce musst du "Noncebreite +1" Nonces testen, bei 2 Bit sinds schon "Noncebreite^2 +1".