Topic: Hashrate der Hardware basiert auf..? (Read 1286 times)

Die Frage mit der Anzahl der Anlaeufe waere beantwortbar wenn man verstehen wuerde wie das mit der Noncekodierung funktioniert.

Im Moment geht mir das noch nicht wirklich auf. So wie ich das oben beschrieben haben ist es nicht ganz richtig. Der Autor reserviert den Platz fuer 1000 Nonces in der Booleschen Formel (oder 10000 in einem anderen Beispiel) und dann beginnt der Solver diese zu fuellen. Zmdst verstehe ich jetzt warum der Solver auch UNSAT ausgeben kann (Fall (v)), naemlich wenn die 1000 Nonces nicht reichen.

Gruss,
cu

P.S.: kennst du ein Tutorial wo das Prinzip BTC-Mining relativ genau erklaert wird? Also "target" holen, zweimal Hashfunktion drauf ansetzen, Ergebniss pruefen, sowie wie die Difficulty bestimmt wird ... am besten erklaert an Code.

Soweit ich das verstanden habe, hängt das mit den führenden 'Nullen' zusammen. sobald da eine 1 auftaucht
kann man dann den nächsten Versuch starten. Allerdings ist meine Vermutung das der Test zwar schneller durch ist, dafür aber mehr Anläufe nötig sind.

Was ich mich derzeit frage ist ob es 'was' bringt

a) statt dem Ansatz mit dem midstate einfach die zwei SHA256 hashes 'hintereinander' durchzurechnen und/oder
b) statt einem sequentiell abzuarbeitendem C-Programm eine Netzliste zu verwenden.

Ich wuerde das so nicht stehen lassen. Ich habe noch ein bischen ueber das Paper nachgedacht. Und eigentlich ist es relativ simpel. Die vorgeschlagene Methode ist sozusagen "Mining in elegant".

Das worauf heute alle gucken, die GH/s, wuerde der Solver uebernehmen. Wenn ich das BTC-Prinzip richtig verstehe, so bekommen alle die gleiche Aufgaben, jeder versucht per Brute Force die Loesung zu berechnen (eine Schleifendurchlauf = 1 H) und der erste bekommt dann den Zuschlag.

Mit der in der Publikation genannten Methode wuerde die Schleife vom Solver uebernommen, d.h. solange der Solver keine Loesung gefunden hat und Teilbaeume des Suchbaums verwirft, solange beweist der Solver, dass Mengen (!) an Hashs nicht die Loesung sein koennen. Das kann die vorhandene Software nicht, die kann diese Aussage immer nur fuer den gerade gegebenen Hash treffen. Ein Miningalgorithmus wuerde dann wie folgt aussehen:
   (i) hole Aufgabe;
   (ii) erzeuge und schreibe die Constraints in eine Datei;
   (iii) starte den Solver mit Constraints als Input;
   (iv) wenn der Solver satisfiable ausgibt:
        (a) lese die Loesung ein;
        (b) erzeuge daraus das was man benoetigt um den Zuschlag zu bekommen und hole Zuschlag;
        (c) gehe zu (i);
   (v) wenn der Solver unsatisfiable ausgibt, hmm ... weiss noch nicht recht;
   (vi) wenn jmd anderes die Loesung findet:
        (a) stoppe Solver;
        (b) gehe zu (i);
Was die Publikation unter "non-deterministic" versteht, bedeutet, so glaube ich (bin mir aber nicht 100% sicher), dass die Loesung fuer die Nonce nicht eindeutig ist, es kann sehr viele Loesungen geben, die Nonce haengt dann einfach von der Implementierung des Solvers ab bzw. wenn man einen Zufallsgenerator benutzt um das Branching des Solvers zu bestimmen, eben von der Sequenz der Zufallszahlen.

Ich kann mich mit meiner Interpretation der Methoden aber auch irren ...

Es kann auch gut sein, dass, je groesser die Difficulty ist, desto besser ist die vorgeschlagene Methode. Ich habe die Erfahrung gemacht, dass, je constrainter ein Problem ist, desto schneller findet der Solver eine Loesung. Aber mit solchen Aussagen muss man vorsichtig sein, SAT ist nun mal sehr schwer zu loesen.

Wer Lust hat das mal zu implementieren, ich koennte den SAT-Teil uebernehmen.

Gruss,
cu

Fuer die zweite Datei out_1k_sat.cnf braucht Cryptominisat 50s und reportet ein Variablenbelegung. Ich muss mir das Paper mal genauer zu Gemuete fuehren ... hab aber keine Ahnung von Kryptographie, arggghhhhh ... Minisat abgeschossen, dauert zu lang!

Cryptominisat hat unsat reportet nach 53s. Geht also. Minisat roedelt immer noch.

hmm ... bei mir konnte noch keiner der Solver die out_1k_unsat.cnf loesen, selbst minisat muss beissen.

Das scheint der direkte Link zu sein:

http://jheusser.github.io/2013/02/03/satcoin.html

Bin noch am schmoekern.

https://www.google.com/search?q=sat+solving+bitcoin

Nochmal: das ist nicht die nächste Generation von Minern!

Sukrim darf ich d3n link zum artikel ? LG Raphael

Mining =  SHA256 von gewissen Werten berechnen.

Der Algorithmus ist nicht sehr speicherintensiv, man braucht eher XOR-Einheiten und Bitshifts wie bei vielen Kryptoalgorithmen. FPGAs und ASICs sind dann einfach nur daraufhin konfiguriert (FPGA) bzw. rein dafür gebaut (ASIC) genau einen bestimmten Algorithmus zu berechnen, man spart sich also SEHR viele zusätzlichen Aufwand, was die Berechnung schneller macht.

ASIC (also genau für diesen Zweck gebaute Chips) sollten erstmal das Ende der Fahnenstange sein, ich habe zwar einen interessanten Artikel über SAT-solvingalgorithmen zu Mining gelesen, das ist aber ein anderer Ansatz als der derzeitige Bruteforceansatz und würde nur bei einer Schwäche von SHA256 gut klappen, die wohl nicht besteht.

Hallo, gibt es irgendwo eine genaue Erläuterung aus was für Werten sich die Hashrate einer GPU(z.b Shader,Takt..) , FPGA, ASIC ergibt?
Auf was kommt es an, was macht den Asic soviel schneller als den FPGA/GPU?

Ist nach dem Asic Miner Schluss??