Topic: Burst Leveraged Mining (Read 669 times)

/subset und /in - wenns jemand braucht:

⊂ ∈

Ist kein Kommentar - ich bin hier nur zufällig.

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  

nee, es funktioniert ja alles wollte nur im vorhinein sicher gehen

Am besten Solo probieren um sich selbst als Problem auszuschließen.

Dann verrate doch mal auf welchem Pool du bist... Denn dann scau ich, dass ich den im Moment meide

Das versuche ich herauszufinden, die einzige Antwort, die ich momentan bekomme ist:


Ich habe Angst, dass ich das Problem bin. 

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. 
Aber ich wüsste schon gerne was da passiert ist.

Kannst du das etwas genauer erläutern, warum?

Ich habe jetzt ein paar Blöcke geforged und nun sind die nicht mehr in der Blockchain.

Operation am offenen Herzen. :-)

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.
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.

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.

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.

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 Runde
Mining, 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.

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.

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..

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
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 

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.

Geil, hoher Besuch   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 ScoopFall 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.

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^^

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.java

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.
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.

OK, ich gebs zu, ich hätte das Schaubild genauer anschauen sollen.. Der Spott kann losgehen,
ich nehms sportlich 
Ich lass es trotzdem mal da während ich drüber nachdenke, vielleicht gereichts noch
jemand zur abendlichen Knobelei

Servus Leute,

also, folgendes: Basierend auf der Idee von rico
https://bitcointalksearch.org/topic/rfc-burst-crowdmining-shares-1-pb-miner-1962866
habe 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:



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 Datendurchsatz
Je 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 ). 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 Datendurchsatz
Alternativ: 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 Datendurchsatz

Bemerkungen:

• 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.  
  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