david123 (OP)
Legendary
Offline
Activity: 1022
Merit: 1004
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 15, 2017, 08:00:49 PM Last edit: June 16, 2017, 08:58:34 AM by david123 |
|
Servus Leute, also, folgendes: Basierend auf der Idee von rico https://bitcointalk.org/index.php?topic=1962866.0habe ich mir mal die Technikalitäten beim Burst-Mining angeschaut. Und es ist tatsächlich so, dass man mit ein wenig GPU-Power einen ordentlichen Hebel-Effekt erreichen kann. Ich möchte das hier mal ausführen. Das Whitepaper ist mMn recht nutzlos, ein Blick auf das Schaubild verrät eigentlich alles: ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FalnEGIj.jpg&t=665&c=gdB6aoyGUSring) Zunächst muss man sich im klaren sein, wie das Prinzip im Normalfall abläuft: Wer konventionell minert, der erstellt sich zuerst die Plots. Jeder Plot ist 250 kb gross ("Plot" als output vom Plotter im Schaubild) und ist unterteilt in 4096 Scoops (oder "Chunks"? Im Zweifelsfall berichtige man mich.. Gemeint sind die 32-byte-words "Plot[ i ]" im Schaubild). Jedes Scoop ist ein 32-byte Word. Auf eurer Platte liegen viele viele solcher Plots, und die sind durchnummeriert mit den Nonces. Die Scoops werden errechnet aus eurer Burst-ID und der Nonce des entsprechnden Plots, und im Wesentlichen ist der i-te Scoop im Plot zur Nonce N gerade Shabal^i(BurstID,N), also Shabal i-mal angewandt auf das Word das aus eurer Burst-ID und der Nonce N zusammengesetzt ist. Dh um nur einen Plot auszurechnen, muss 4096-mal Shabal angewandt werden. Das passiert beim plotten und benötigt entsprechend viel Rechenzeit. Shabal ausrechnen können GPUs relativ effizient, vor allem wenn die Daten parallel vorliegen (d.h. wir rechnen in einem Aufwasch den ersten Scoop zu den nonces 1 bis z.B. 1000 aus, dann den 2. Scoop zu den nonces 1 bis 1000, usw. Das ist übrigens auch der Grund, warum GPU-Plots noch nicht optimiert sind, aber das soll uns hier egal sein.) Beim Mining macht man folgendes: Man ist i.W. konfrontiert mit einer ScoopNumber M und einem Datensatz GenSig, und die Aufgabe ist nun, Plots (oder besser: Nonces N) zu finden, deren M-ter Scoop (nennen wir ihn S_(M,N)) folgende Eigenschaft erfüllt: Shabal(GenSig, S_(M,N)) ist klein. Was macht also die Mining-Software? Sie liest aus jedem Plot (d.h. für jede Nonce N die ihr beim plotten reingenommen habt) den M-ten Scoop aus, berechnet Shabal(GenSig, S_(M,N)) und submittet, wenn das Ergebnis "klein genug" ist. Da wir für jeden Block nur einen fixen Scoop auslesen müssen, wird nur auf ein 4096-tel der Mining-Kapazität lesend zugegriffen. Für 100 tb immerhin noch 250 25 GB die verarbeitet werden müssen! Aufwand (konventionell) für x MB Mining-Kapazität: x MB Plattenplatz, x*4 Shabal-Berechnungen, x/4096 MB DatendurchsatzJe nach HW sind nun entweder die Shabal-Berechnungen das bottleneck (gerne bei cpu-minern) oder der Datendurchsatz (üblicherweise bei GPU-minern). Nun springt einem folgende Alternative gradezu ins Gesicht: Ich erkläre es für den Hebel-Faktor H=2: Der Plotter rechnet aus was er immer ausrechnet, nur speichert er nicht den ganzen Plot, sondern nur jeden zweiten Scoop. Plus den Final Hash, der wird konventionell verworfen, wir brauchen ihn aber. Insgesamt ist jetzt der Plot zu einer gegebenen Nonce nur minimal mehr als halb so groß wie konventionell. Der Miner macht folgendes (Fallunterscheidung je nach Parität der Scoop-Number): Glücklicher Fall: Ist für einen Block eine gerade Scoop-Nummer M angesagt, so schaut er einfach an die M/2-te Stelle in den Blöcken, denn die graden Scoops haben wir ja abgespeichert (Puh ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) ). Dann muss natürlich noch ge-Shabal-t werden für die Deadline, aber gegenüber konventionell hat sich am Aufwand gar nichts geändert. Nicht-so-glücklicher Fall: Ist M ungerade, so müssen wir an PlotChunk[M-1] rankommen, um darauf Shabal anzuwenden, denn das ist gerade PlotChunk[M] und daraus bekommen wir per xOR mit Final Hash den benötigten M-ten Scoop! An PlotChunk[M-1] kommen wir aber easy, wir müssen nur an die (M/2-1/2)-te Stelle in unserem Plot schauen und das xOR-en mit Final Hash rückgängig machen. ( Die ganze xOR-Geschichte lasse ich grade mal nur halb erklärt. Das ist eine Rechnung die lächerlich schnell ist im Vergleich zu Shabal, also quasi eine Formalität die man für die Aufwandsabschätzung vernachlässigen kann. Auch das coden ist straightforward und Bestandteil von meinetwegen 3 Codezeilen.) Wir müssen also pro Block zwei mal Shabalen. Nun treten die beiden Fälle auf lange Sicht gleich häufig auf, wir bekommen also: Aufwand (Hebel H=2) für x MB Mining-Kapazität: x/2 MB Plattenplatz, x*6 Shabal-Berechnungen, x/4096 MB DatendurchsatzAlternativ: Für eine gegebene Kapazität verdoppelt sich die "minebare Kapazität", aber der Rechenaufwand steigt um 50%, der Datendurchsatz sogar um 100%. Das lässt sich auf offensichtliche Weise für beliebige H realisieren (ich würde aber der Einfachheit halber auf Zweierpotenzen setzen, sonst verschenkt man auch etwas Platz). Einmal arithmetischen Reihe für Drittklässler liefert: Aufwand (Hebel H beliebig) für x MB Mining-Kapazität: x/H MB Plattenplatz, x*2*(H+1) Shabal-Berechnungen, x/4096 MB DatendurchsatzBemerkungen: - Nur ein Time-Memory-Tradeoff? Man gewinnt nichts?
Jein.. Es ist ein Tradeoff, aber vor allem zeigt es dass wir sehr ineffizient minen, insbesondere die unter uns die GPU-mining betreiben. Jeder GPU-Burst-Miner möge sich die Frage beantworten: Würde ich gerne (ohne zusätzliche Investitionen) mit doppelter Kapazität minen, wenn dafür meine round time (im Mittel) um 50% steigt? Mit dreifacher Kapazität, wenn dafür meine round time um 100% steigt? Allerdings kann man nicht beliebig skalieren: Wenn der Hebel H hochgeht, dann steigt nicht nur die nötige Rechenleistung, sondern auch der Datendurchsatz. Ich habe keine große Ahnung von den Performance-Werten, aber ich würde sagen H=8 oder 16 wäre ein möglicher Sweetspot bei 100tb und ner sauberen GraKa. H=64 oder 128 ist vielleicht machbar bei 8 Hammer-GPUs und mit SSDs. Müsste man testen..
- Eine theoretische Spielerei?
Quatsch, das lässt sich ohne weiteres in die Realität holen. Man muss sich nur eine neue Struktur für die Plot-Files überlegen (bzw einfach sicherstellen, dass der geforkte Miner den Final Hash da sucht, wo der geforkte Plotter ihn hingelegt hat) und diesen Hebel-Parameter als Argument in die Config-File von jminer bzw als Argument vom Plotter einpflegen, und halt die zwei Programme abändern. Ich denke, wenn alles fertig ist, hat man vielleicht 50-100 Zeilen Code insgesamt geändert/hinzugefügt. Blago oder Luxe brauchen dafür vlt 2 Stunden mit testen usw.
- Warum erkläre ich euch das hier und programmiere nicht meinen Miner? Jup, habe ich versucht, aber ich bin ein unerfahrener
Programmierer und der Nachmittag heute hat mich schon in den Wahnsinn getrieben. Weniger der Code, als vielmehr die zig Abhängigkeiten, OpenCL-Versionen, was weiss ich. Dafür ist mir meine Zeit zu schade und ich bin auch nicht geneigt, einen entsprechenden Miner aufzusetzen wo sich das lohnen würde. Burst ist nicht mehr lange profitabel. Trotzdem, wenn sich jemand berufen fühlt, das zu coden, wäre ich über eine Kopie natürlich nicht undankbar. Am besten wäre es vermutlich, wenn das gleich open source gemacht wird.
Den Ausschlag hat allerdings gegeben, dass mir rico mit seinem Bakshish-Kommentar, gelinde gesagt, ein weeenig unsympathisch geworden ist. ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) Da mache ich die Überlegungen hier lieber gleich öffentlich. Ist eh im Sinne des open source Gedankens
- Wenn es so einfach ist, warum ist noch niemand auf die Idee gekommen in den Jahren seit Burst existiert?
Das ist allerdings eine Frage, auf die ich keine Antwort habe... Die einzige Vorstellung, in der mein Weltbild konsistent bleibt, ist dass Luxe und Blago und deren Kumpels schon länger so minen oder gemined haben. Es ist für mich völlig unvorstellbar, dass man so etwas wie jminer programmiert und nicht auf die Idee kommt, das einzubauen. (Luxe's Code ist übrigens um Lichtjahre professioneller als Blago's, wenigstens eine Erkenntnis des heutigen Nachmittages^^)
Edit: Oha, einen kleinen Fehler habe ich noch gefunden.. Ist in Arbeit ![Grin](https://bitcointalk.org/Smileys/default/grin.gif)
|
|
|
|
david123 (OP)
Legendary
Offline
Activity: 1022
Merit: 1004
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 15, 2017, 08:26:18 PM |
|
OK, ich gebs zu, ich hätte das Schaubild genauer anschauen sollen.. Der Spott kann losgehen, ich nehms sportlich ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif) Ich lass es trotzdem mal da während ich drüber nachdenke, vielleicht gereichts noch jemand zur abendlichen Knobelei ![Wink](https://bitcointalk.org/Smileys/default/wink.gif)
|
|
|
|
luxe
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 15, 2017, 09:34:51 PM |
|
... - Wenn es so einfach ist, warum ist noch niemand auf die Idee gekommen in den Jahren seit Burst existiert?
Das ist allerdings eine Frage, auf die ich keine Antwort habe... Die einzige Vorstellung, in der mein Weltbild konsistent bleibt, ist dass Luxe und Blago und deren Kumpels schon länger so minen oder gemined haben. Es ist für mich völlig unvorstellbar, dass man so etwas wie jminer programmiert und nicht auf die Idee kommt, das einzubauen.
... Zunächst einmal, ich mine mit genau der jminer version, die auch öffentlich verfügbar ist. Vorstellbar oder nicht ... ich bin nicht auf diese Idee gekommen. Der openCL checker und kernel code im jminer ist übrigens nicht von mir, sondern von @burstcoin (org. burst dev) https://github.com/de-luxe/burstcoin-jminer/blob/master/src/main/java/burstcoin/jminer/core/checker/util/package-info.javaWenn ich alles richtig verstanden habe, müsste man sich schon beim Plotten entscheiden, welchen 'hebel' man nutzen möchte. Es brächte einen speziellen Plotter sowie ein neues 'Format' der Daten u.a. für das Speichern des 'final hash'. Außerdem brächte man einen speziellen Miner der mit diesem alternativem 'Format' umgehen kann. Finde den gesammten Gedanken sehr interessant. Geht aber natürlich gegen die eigentliche Idee von PoC. Daher sollte es eher das Ziel sein, PoC dahingehend zu härten und zu verbessern, dass es nicht mehr auf diese Weise 'ausgehebelt' werden kann.
|
|
|
|
david123 (OP)
Legendary
Offline
Activity: 1022
Merit: 1004
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 15, 2017, 09:39:34 PM |
|
Geil, hoher Besuch ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) Wusste gar nicht, dass du deutsch sprichst. Leider ist alles Käse.. Ich hätte besser drüber nachdenken müssen vorm posten. Also, mein Fehler war ja dass ich die Erzeugung des Arrays PlotChunk[] nicht richtig gelesen/verstanden hatte. Um PlotChunk[ i ] zu berechnen, braucht man keineswegs nur PlotChunk[ i+1 ], sondern jedes PlotChunk[j] für j>i. (Ich benutze die Zählweise aus dem Schaubild.) Die naive Idee, einfach ein paar Scoops wegzulassen und im Zweifelsfall zu berechnen, verbietet sich völlig , denke ich: - Ein Scoop, den ich easy weglassen kann, ist der erste: PlotChunk[4095]. Dann kann ich in 4096/4095*100 = 99.8 % der Fälle einfach
minern wie bisher. Falls Scoop=4095, dann muss ich den noch ausrechnen. Kein Problem. Einmal Shabal. - Jetzt will ich noch einen zweiten Scoop weglassen. Es ist eigentlich nicht so kritisch welchen, aber bei PlotChunk[4094] minimiere
ich immerhin die Eingabelänge für Shabal und die Lesezugriffe auf frühere Scoops falls die zweite Lücke aufgerufen wird, also nehme ich den. Immer noch geht minern meistens so schnell wie vorher, nur bei Scoop=4095 brauche ich einmal Shabal pro Nonce zusätzlich, bei Scoop=4094 brauche ich zweimal Shabal. - usw usw.. Jetzt lasse ich M Scoops weg, und ich denke es ist immer noch am cleversten die ersten M Scoops raus zu kicken.
Dann kann ich in manchen Fällen so schnell minern wie konventionell (wenn Scoop<M), und sonst muss ich rechnen: Pro Nonce im schlimmsten Fall M mal Shabal. Wenn also meine round time (ich rede hier vor der reinen mining Zeit der GPU, die Zugriffszeiten zur HDD ausgelassen) x sek normalerweise ist, dann brauche ich M*x sekunden falls Scoop=M gefragt ist. Ich denke, schon bei M=10 kann man es vergessen.
Die naive Idee, einfach ein paar Scoops nicht zu speichern, ist also nicht zielführend. Im Wesentlichen setze ich dann bei den Runden aus, bei denen Scoops gefragt sind, die ich weggeworfen habe -> nix gewonnen. Das basiert auf der Überlegung, immer die ersten Scoops rauszuschmeissen (d.h. nicht abzuspeichern. Beim plotten berechnen muss ich sie ja auf jeden Fall!). Meiner Meinung nach wird es nicht besser sondern noch schlechter, wenn ich nicht die ersten Scoops rauswerfe, sondern z.B. in regelmäßigen Abständen Lücken lasse: Wenn ein Scoop in der Lücke angesagt ist, muss ich immer noch sehr oft Shabal anwenden, und ausserdem muss ich absurd viel lesend auf die HDD zugreifen (ich brauche wie gesagt alle (!) Scoops davor). Wenn ich z.B. im Extremfall PlotChunk[1] auslassen würde, müsste ich, egal wie die Lücken vorher sind, den kompletten Platteninhalt auslesen, um eine Chance zu haben, auf PlotChunk[1] zu kommen. Wenn ich alles richtig verstanden habe, müsste man sich schon beim Plotten entscheiden, welchen 'hebel' man nutzen möchte. Es brächte einen speziellen Plotter sowie ein neues 'Format' der Daten u.a. für das Speichern des 'final hash'. Außerdem brächte man einen speziellen Miner der mit diesem alternativem 'Format' umgehen kann.
Das hätte ich vor 1h bejaht, jetzt zweifle ich ja am gesamten Konzept. Grade kommt mir der PoC-Algo hinter Burst doch ziemlich wasserdicht vor^^
|
|
|
|
luxe
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 15, 2017, 09:58:14 PM |
|
Zugegeben, ich habe nie versucht einen Plotter zu schreiben und mich daher auch nicht ausführlicher damit beschäftigt ... Du hattest mich quasi schon überzeugt. Das 'Schaubild' ist in dem Punkt nicht ganz eindeutig, denke ich. Bin beruhigt, dass PoC nun doch nicht so einfach 'ausgehebelt' werden kann :-P Dennoch danke für Deine Schilderungen, hab wieder etwas gelernt.
|
|
|
|
david123 (OP)
Legendary
Offline
Activity: 1022
Merit: 1004
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 15, 2017, 10:14:33 PM |
|
Jup, das Ding ist dass die Mining-Software dann auch teilweise die Aufgaben eines Plotters übernehmen müsste. Wegen dem Schaubild bin ich jetzt auch nochmal ins Zweifeln geraten, aber wegen Miners generate and cache chunks of data known as 'plots', which are divided into 4096 portions known as 'scoops'. Plots are generated by taking a public address and a nonce, then hashing it, pre-appending the resulting hash, repeating the hash-pre-append cycle many times, and then hashing the whole thing and xor'ing the last hash with the whole thing.
bin ich mir eigentlich doch relativ sicher dass es so geschieht wie ich es im letzten Post interpretiert habe. Bei genauerem Nachdenken ist das auch ein bisschen der Witz von dem PoC-Konzept. Wenn es so wäre wie ich zuerst dachte, wäre diese Hebelwirkung doch sehr offensichtlich gewesen. Darüber hinaus möchte ich noch mal betonen, dass die Idee, einen GPU-Hebel anzusetzen (ob sie nun realisierbar ist oder nicht) nicht von mir stammt, sondern von Rico. Was ich hier versuche, ist so gesehen nur reverse engineering, die chinesische Art quasi ![Grin](https://bitcointalk.org/Smileys/default/grin.gif)
|
|
|
|
david123 (OP)
Legendary
Offline
Activity: 1022
Merit: 1004
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 15, 2017, 10:55:01 PM |
|
Okeee, ich habe noch ein bisschen gebrütet und bin vielleicht auf eine nicht-triviale Idee zum hebeln gekommen. Hier wäre der Hebel fix und sehr gross (d.h. man braucht kleine, schnelle Platten), und gut skalierbar in der GPU-Power die man drauf schmeisst.. Ich denke, mit einem Multi-GPU-Monster kann man in den PB Bereich kommen. Und es hätte noch andere Vorteile. Aber bevor ich zuviel verspreche, muss ich nochmal drüber grübeln ob ich nicht wieder einen Fehler eingebaut habe.
Und: Bevor ich mir hier weiter die Finger wund schreibe: Gibt es überhaupt Leute, die das interessiert? Evtl Leute mit Programmiererfahrung, die Lust hätten das mit mir zu implementieren? Sonst spare ich mir den Aufwand..
|
|
|
|
rico666
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 16, 2017, 07:15:05 AM |
|
Ich kann nicht zuschauen wie ihr euch abkarpft.
@david123: Banach-Tarski Paradox sagt Dir was? Wir erinnern uns: Ein Paradox ist nur ein scheinbarer Widerspruch. Im Grunde lernt man aus dem Beispiel, dass unsere Ansicht über Mengen sehr naiv ist, was zur Geltung kommt, wenn Begriffe wie "unendlich dicht" vorkommen. Einfache Auflösung von Banach Tarski: Ich kann eine unendlich dichte Menge in zwei unendlich dichte Mengen aufteilen, wenn ich nur geschickt bei der Iteration der Oberflächenpunkte vorgehe.
Was hat das nun hier mit BURST zu tun?
Die Mengen mit denen wir hier hantieren, sind diskret und endlich, also auf den ersten Blick: NICHTS.
Aber - und Du führst es in Deinem Text auch schon aus - nicht alle Nonces sind in den Plots "gleich tief begraben", d.h. der Rekonstruktionsaufwand für einige ist wesentlich einfacher als für andere.
Man muss sich nur von der linearen Denke verabschieden "jeder dritte" oder "jeder Nte". Auch hier gibt es Endomorphismen.
edit: Warum glaubst Du das Whitepaper sei nutzlos? Es ist ein wenig komisch aufgebaut mit den Literaturangaben mittendrin - da darf man nicht aufhören zu lesen.
|
|
|
|
david123 (OP)
Legendary
Offline
Activity: 1022
Merit: 1004
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 16, 2017, 08:53:50 AM Last edit: June 16, 2017, 09:17:56 AM by david123 |
|
Guten Morgen, erst mal @rico: Ich glaube es gibt hier einen ignore-button, dann musst du dir das nicht antun wie ich mich "abkarpfe". Ich denke, das wäre in unser beider Sinne. ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) Ich will mal meine Überlegung ausführen, die mir gestern abend gekommen ist. Ich gehe davon aus, sie ist noch ausbaufähig, aber die Grundidee gefällt mir schon mal: Burst ist eigentlich so designed, dass man, um an Plot[ i ] ranzukommen, alle PlotChunk[j] kennen muss (und nicht nur die für j>i). Das soll folgendes Szenario vermeiden: Ein Miner speichert einfach gar nichts. Bei fast allen Scoops macht er auch gar nichts. Falls Scoop=4095 aufgerufen wird, so berechnet er jeweils PlotChunk[4095] on the fly. Dafür nimmt er sinnvollerweise einen ETH-Miner mit vielen GraKas. Der scannt permanent das Burst-Netzwerk und alle 4 Tage, wenn ein Scoop-4095-Block dran ist, hört er kurz auf mit ETH und holt sich diesen Block, denn den bekommt er dann. Um das zu vermeiden, gibt es den FinalHash. Ich muss alle PlotChunk[ j ]'s kennen, um den FinalHash zu berechnen, und den brauche ich, um aus PlotChunk[4095] den Plot[4095] zu bekommen. Allerdings: Den FinalHash könnte ich speichern! Also folgende Idee: Beim Plotten wird alles ausgerechnet (da gibts eh kein Weg drum herum) aber NUR der FinalHash gespeichert. Dann kann ich nämlich Plot[4095] easy aus meinem Key und den zu inkrementierenden Noncen errechnen. Ich brauche nur für jede Nonce 2x Shabalen statt einmal. Damit könnte ich 100 tb Mining-Kapazität vorgaukeln, obwohl ich nur 25GB FinalHashes gespeichert habe. Allerdings NUR bei Scoop=4095, d.h. meine effektive Mining-Kapazität ist doch wieder nur 25 GB. Gegenüberstellung: Mining, konventionell: Für 25 GB Mining-Kapazität brauche ich: 25 GB Plattenplatz, 10^5 Shabal-Operationen pro RundeMining, wie oben beschrieben: Für 25 GB Mining-Kapazität brauche ich: 25 GB Plattenplatz, 2*10^5 Shabal-Operationen pro Runde in der ich mitmache (gemittelt)Noch nicht so geil, aber das Prinzip kann ich ja weitertreiben. Mein Miner wacht nicht nur auf, wenn Scoop=4095 gefragt ist, sondern bei Scoops 4085-4095, unter der Annahme ich kann 10 Shabal-Zykeln noch schaffen pro Nonce. Dann melde ich mich nur bei 1/400-tel aller Blöcke überhaupt zu Wort, aber bei denen mit einer Hashrate die 100 tb entspricht. Mining, wie grade beschrieben: Für 250 GB Mining-Kapazität brauche ich: 25 GB Plattenplatz, 8,8*10^6 Shabal-Operationen Oder, um es besser vergleichen zu können: Für 25 GB Mining-Kapazität brauche ich: 2,5 GB Plattenplatz, 8,8*10^5 Shabal-Operationen pro Runde in der ich mitmache (gemittelt)Hier hätten wir also einen Hebel von 10 mit einer moderaten Rechenlast (im Mittel) realisiert. Vorteile: - Diesmal ist kein Fehler im Gedankengang (hoffentlich
) - Der Miner realisiert diese 25 GB in dem er ca. 2,5 mal am Tag für jeweils 2 Minuten arbeitet. Er braucht nahezu keinen Plattenplatz
und kann die GPUs 99% der Zeit anderen Dingen widmen, z.B. ETH-Mining.
Nachteile: - Nur bei 1/400-tel der Blöcke wird mitgemacht, d.h. erstens kann man Pech haben und es kommt mal keiner. Vor allem kann man nur
maximal 2,5* Blockreward pro Tag abstauben. - Man kann den Hebel H grösser machen, d.h. bei mehr Blöcken mitminern. Dann steigt die Rechenlast im Mittel nur moderat. Die Rechenlast
für Scoop 4096-H steigt aber erheblich. Daher sehe ich nur begrenzte Skalierbarkeit.
Das war die Überlegung für fixierte Gesamt-Kapazität. In der Realität wird man vielleicht auch bei Scoop=4096-H für relativ grosse H mitminern, so lange eben die Runde dauert. Für H=500 wird man dann nicht mehr den ganzen FinalHash-Plot durchlaufen, aber immerhing noch einen gewissen Anteil. Mein Fazit bis hierher: Ich glaube nicht, dass man mit dem Verfahren den Superminer herstellen kann. Aber der PoC-Algorithmus ist nicht optimal (gelinde gesagt). Es ist eher ein Proof-of-Precomputation Algo als ein Proof-of-Capacity Algo. Die oben beschriebenen Vereinfachungen sorgen dafür, dass bei entsprechendem Miner-Design die Blöcke mit höherer Scoop-Nummer einfacher zu knacken sind als die mit niedriger Scoop-Nummer. Das ist offensichtlich problematisch. Wenn hier keiner einen Fehler findet, werde ich das definitiv den Entwicklern melden. Dieses Problem lässt sich easy vermeiden wenn man zur Berechnung von Plot[ i ] nicht nur PlotChunk[ i ] und FinalHash, sondern auch noch einen "Streuwert" aus den anderen PlotChunks benutzt.
|
|
|
|
rico666
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 16, 2017, 09:35:05 AM |
|
erst mal @rico: Ich glaube es gibt hier einen ignore-button, dann musst du dir das nicht antun wie ich mich "abkarpfe". Ich denke, das wäre in unser beider Sinne. ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) Oh. Da habe ich wohl die falschen Signale ausgedsandt. Im Vergleich zu einem "rück den Code raus" zeugt dieser Thread nämlich von Initiative und Fähigkeit und mit "ich kann nicht zusehen wie ihr euch abkarpft" meinte ich "das ist der richtige weg mein Herz zu erweichen, so dass ich etwas code rausrücke". Aber wenn es in Deinem Sinne ist, dass ich mich zurückhalte (klar - meine Art muss nicht jeder), dann mache ich das. Ansonsten gehst Du ganz anders an die Sache ran als ich, für mich ist das durchaus eine spannende Lektüre. Aber kommentieren werde ich nicht mehr. Versprochen.
|
|
|
|
Evolver
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 16, 2017, 12:00:35 PM |
|
also ich finde die Herangehensweise genau richtig! mein Interesse daran ist auch immer noch vorhanden und hoch, aber das würde ich nur noch zu Lernzwecken mitnehmen. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) hab mich heut auch schon wieder totgecodet mit einem Multithreadpool, der sogar funzt, leider jedoch keine Performance(wofür er gedacht war) bringt, weil der zeitliche Flaschenhals an einer ganz anderen ecke sitzt. ![Angry](https://bitcointalk.org/Smileys/default/angry.gif)
|
|
|
|
rico666
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 16, 2017, 12:45:37 PM |
|
also ich finde die Herangehensweise genau richtig! mein Interesse daran ist auch immer noch vorhanden und hoch, aber das würde ich nur noch zu Lernzwecken mitnehmen. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) hab mich heut auch schon wieder totgecodet mit einem Multithreadpool, der sogar funzt, leider jedoch keine Performance(wofür er gedacht war) bringt, weil der zeitliche Flaschenhals an einer ganz anderen ecke sitzt. ![Angry](https://bitcointalk.org/Smileys/default/angry.gif) Ich habe jetzt ein paar Blöcke geforged und nun sind die nicht mehr in der Blockchain. Operation am offenen Herzen. :-)
|
|
|
|
schnebihacked
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 16, 2017, 12:48:09 PM |
|
also ich finde die Herangehensweise genau richtig! mein Interesse daran ist auch immer noch vorhanden und hoch, aber das würde ich nur noch zu Lernzwecken mitnehmen. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) hab mich heut auch schon wieder totgecodet mit einem Multithreadpool, der sogar funzt, leider jedoch keine Performance(wofür er gedacht war) bringt, weil der zeitliche Flaschenhals an einer ganz anderen ecke sitzt. ![Angry](https://bitcointalk.org/Smileys/default/angry.gif) Ich habe jetzt ein paar Blöcke geforged und nun sind die nicht mehr in der Blockchain. Operation am offenen Herzen. :-) Kannst du das etwas genauer erläutern, warum?
|
|
|
|
rico666
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 16, 2017, 01:02:18 PM |
|
also ich finde die Herangehensweise genau richtig! mein Interesse daran ist auch immer noch vorhanden und hoch, aber das würde ich nur noch zu Lernzwecken mitnehmen. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) hab mich heut auch schon wieder totgecodet mit einem Multithreadpool, der sogar funzt, leider jedoch keine Performance(wofür er gedacht war) bringt, weil der zeitliche Flaschenhals an einer ganz anderen ecke sitzt. ![Angry](https://bitcointalk.org/Smileys/default/angry.gif) Ich habe jetzt ein paar Blöcke geforged und nun sind die nicht mehr in der Blockchain. Operation am offenen Herzen. :-) Kannst du das etwas genauer erläutern, warum? Das versuche ich herauszufinden, die einzige Antwort, die ich momentan bekomme ist: Im not sure. Like I said, pools are having problems thismorning. The pool I was mining on hasnt been working correctly since last night you may want to reach out to the pool admin Ich habe Angst, dass ich das Problem bin. ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) Einer von meinen BURST nicks hat z.B. neulich 371662 gemined, auch vom pool ca. 50% der BURSTs (von den 60%) bekommen. ~585 Burtst waren noch in der Queue und nun sind die weg, der Block auch. Egal, war ja nicht der erste Block heute. ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) Aber ich wüsste schon gerne was da passiert ist.
|
|
|
|
schnebihacked
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 16, 2017, 01:09:35 PM |
|
also ich finde die Herangehensweise genau richtig! mein Interesse daran ist auch immer noch vorhanden und hoch, aber das würde ich nur noch zu Lernzwecken mitnehmen. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) hab mich heut auch schon wieder totgecodet mit einem Multithreadpool, der sogar funzt, leider jedoch keine Performance(wofür er gedacht war) bringt, weil der zeitliche Flaschenhals an einer ganz anderen ecke sitzt. ![Angry](https://bitcointalk.org/Smileys/default/angry.gif) Ich habe jetzt ein paar Blöcke geforged und nun sind die nicht mehr in der Blockchain. Operation am offenen Herzen. :-) Kannst du das etwas genauer erläutern, warum? Das versuche ich herauszufinden, die einzige Antwort, die ich momentan bekomme ist: Im not sure. Like I said, pools are having problems thismorning. The pool I was mining on hasnt been working correctly since last night you may want to reach out to the pool admin Ich habe Angst, dass ich das Problem bin. ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) Einer von meinen BURST nicks hat z.B. neulich 371662 gemined, auch vom pool ca. 50% der BURSTs (von den 60%) bekommen. ~585 Burtst waren noch in der Queue und nun sind die weg, der Block auch. Egal, war ja nicht der erste Block heute. ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) Aber ich wüsste schon gerne was da passiert ist. Dann verrate doch mal auf welchem Pool du bist... Denn dann scau ich, dass ich den im Moment meide ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif)
|
|
|
|
eneloop
Legendary
Offline
Activity: 1513
Merit: 1040
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 16, 2017, 03:19:16 PM |
|
Am besten Solo probieren um sich selbst als Problem auszuschließen.
|
|
|
|
schnebihacked
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 16, 2017, 03:53:00 PM |
|
Am besten Solo probieren um sich selbst als Problem auszuschließen.
nee, es funktioniert ja alles ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) wollte nur im vorhinein sicher gehen ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif)
|
|
|
|
david123 (OP)
Legendary
Offline
Activity: 1022
Merit: 1004
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 16, 2017, 04:26:49 PM |
|
Also, ich habe mal in das Hellman-Paper geschaut. Was der gute Mann macht, ist, nachzurechnen dass sich der folgende Memory-Time-Tradeoff lohnt: Gegeben sei eine schwierig-zu-invertierende Funktion f:X -> Y (z.B. eine Hash-Funktion). Nehmen wir der Einfachheit halber an, X=Y und X ist nicht allzu wahnsinnig groß. Möchte man in der Lage sein, f zu invertieren, dann gibt es verschiedene Herangehensweisen: 1. Ich berechne für alle x \in X den Wert f(x) und lege ihn in einer Liste zusammen mit x ab. Ein Eintrag der Liste ist von der Form (x, f(x)) und es ist günstig, die Liste auf eine geeignete Art nach dem zweiten Eintrag zu sortieren. Bin ich nun in der Verlegenheit, ein Urbild von y zu finden, dann brauche ich nur in meiner sortierten Liste nachzuschauen, ob ein Paar mit 2. Eintrag y existiert. Falls ja, dann habe ich mein Urbild als ersten Eintrag gefunden. Nachteil: Braucht wahnsinnig viel Speicher. 2. Ich speichere gar nichts, sondern suche Brute-Force, d.h. ich laufe über alle x \in X und rechne f(x) aus. Falls f(x)=y, dann habe ich x als Urbild gefunden. Nachteil: Braucht wahnsinnig viel Zeit. 3. Als Zwischenlösung präsentiert Hellman folgendes: Fixiere einen Hebelwert H. Dann suche ich mir (zufällig/systematisch.. das ist Feintuning) eine Teilmenge Z \subset X raus, die grade 1/H-tel so viele Elemente wie X enthält. Ich speichere die Liste mit den Einträgen (x, f^H(x)) für x \in Z, wieder sortiert nach dem 2. Eintrag. Wird ein y nachgefragt, so schaue ich in meiner Liste, ob irgendwo y als zweiter Eintrag vorkommt. Falls ja, ist f^(H-1)(erster Eintrag der Liste) mein gesuchtes Urbild. (-> Ich musste H-1 mal f ausrechnen) Falls nein, berechne f(y) (einmal f anwenden). Suche wieder in der Liste, ob f(y) als zweiter Eintrag vorkommt. Falls ja, so ist f^(H-2)(erster Eintrag) mein gesuchtes Urbild. (-> Insgesamt musste ich wieder H-1 mal f anwenden). Usw.. Insgesamt kommt man hier mit 1/H-tel des Speichers von 1. aus, muss aber für jedes Urbild H (oder H-1..) mal f anwenden. Das kostet Rechenzeit. Hellman zeigt aber, dass es unter gewissen Annahmen und für geeignetes H möglich ist, ein f auf diese Weise "billig" zu invertieren, während die Alternativen 1. und 2. unmöglich oder sehr teuer sind. Burst ist nun "im Prinzip" so konzipiert, dass 1. gut funktioniert, aber 2. katastrophal langsam. "Im Prinzip" sollte man aber auch 3. anwenden können. Im Prinzip, weil der Burst Algo eben nicht ganz so einfach aufgebaut ist dass man ein f invertieren muss. Ich sehe zumindest im Moment noch nicht, was bei Burst das geeignete f wäre, um Hellman's Methode direkt anwenden zu können. Also, vielleicht (hoffentlich) ist der Burst-Algo so gut, dass dieser Hebel-Trick gar nicht einsetzbar ist. Vielleicht übersehe ich noch etwas. Ich bleibe dran ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif)
|
|
|
|
rico666
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 16, 2017, 05:17:13 PM |
|
/subset und /in - wenns jemand braucht:
⊂ ∈
Ist kein Kommentar - ich bin hier nur zufällig.
|
|
|
|
|