Pages:
Author

Topic: RFC: BURST Crowdmining Shares ~1+ PB Miner (Read 1897 times)

legendary
Activity: 1120
Merit: 1037
฿ → ∞
June 14, 2017, 04:11:18 AM
#58
Dann kannst ja mal deinen Code veröffentlichen  Tongue
Ich kann ja immer noch nicht so recht daran glauben..

Ich bin bereits mit 17 konsequent an allen Ägyptern vorbei, die mit den Worten "Bakschisch?" die Hand aufgehalten haben. Ich werde jetzt mit 47 nicht anfangen das zu ändern.

Wenn es kein Crowdmining Shares Projekt gibt (wovon ich jetzt mal ausgehe), bedeutet das noch lange nicht, dass ich nicht den Code für mich selbst so verwende, oder dass er bei einem anderen PoC coin zum Einsatz kommt.

Wäre ich Darth Vader, würde ich auch nicht den Code veröffentlichen, sondern mit den Worten "Ich finde Ihren Mangel an Glauben beklagenswert" andere Dinge veranstalten.  Wink Tja - so bin ich.

Ich denke, wir können diesen Thread schliessen.
legendary
Activity: 1022
Merit: 1004
Dann kannst ja mal deinen Code veröffentlichen  Tongue
Ich kann ja immer noch nicht so recht daran glauben..
legendary
Activity: 1120
Merit: 1037
฿ → ∞
also ich distanziere mich auch mal, so sehr mich diese Idee interessiert, von dieser Sache.

Meine Gründe dafür:

-> zu spät (König der Krümel usw.)
-> würde die reichen nur reicher machen weil nur effizient bei ohnehin schon großen Minern! (und ich zähle mich mal dazu)

Ganz ehrlich, sehe ich das mittlerweile ähnlich: Man muss nicht alles was technisch machbar ist auch umsetzen.
Wenn mir dieses Vorhaben etwas gezeigt hat, dann dass ein andere Coin her muss.  Smiley

Für die, die es interessiert Stand meines Mining vs Trading Experiments:

Start: 7.6.

Stand 14.6.

Miner: 1420 BURST
Trading: 58000 BURST
full member
Activity: 353
Merit: 100
also ich distanziere mich auch mal, so sehr mich diese Idee interessiert, von dieser Sache.

Meine Gründe dafür:

-> zu spät (König der Krümel usw.)
-> würde die reichen nur reicher machen weil nur effizient bei ohnehin schon großen Minern! (und ich zähle mich mal dazu)
legendary
Activity: 1513
Merit: 1040
Sind die 75 W ein realistischer Wert?

Sagt zumindest nvidia-smi bei der 1050Ti. Die kleineren karten sind tatsächlich weniger effizient als die großen Brocken.
Ok, dann ist das offenbar so. Das smi ist recht genau.
legendary
Activity: 1120
Merit: 1037
฿ → ∞
Sind die 75 W ein realistischer Wert?

Sagt zumindest nvidia-smi bei der 1050Ti. Die kleineren karten sind tatsächlich weniger effizient als die großen Brocken.
legendary
Activity: 1513
Merit: 1040
Quote
Das Problem was ich sehe: Es steht dem Dezentralisierungsgedanken entgegen, große Systeme haben Vorteile und nicht jeder kann sich Petabyte-Miner leisten.
Wenn der Skalierungseffekt im Grunde auf jede Kapazität anwendbar ist (?), dann ist das kein Problem. Man muss ja nicht zwingend mit einer high-end GPU arbeiten, die eine entsprechende Größe an HDD Kapazität voraussetzt. Kritisch wird es dann, wenn die notwendige Kapazität auf ein Minimum begrenzt werden kann und die GPUs bzw. deren Stromverbrauch überhand nimmt. Da wäre dann der Burstcoin nichts anderes, als einer der vielen anderen PoW Coins.

Runterskalieren geht zwar (mein kleiner Demonstrator  hier ist ein 20 -> 60 TB System), aber es ist nicht wirtschaftlich, weil ~30W (HDD) versus 75W (GPU). Von daher gibt es da ein Limit unterhalb dessen dieser hybride Ansatz keinen Sinn macht. Zumindest nicht so lange die Hardware so bleibt wie sie ist.

Wenn GPUs mal um den Faktor 10 effizienter werden, wird dieses Limit zu Ungunsten der HDDs sinken. Auf der anderen Seite können ja auch wieder bezahlbare 2.5 multi-TB SSDs kommen und die Waage geht in die andere Richtung.
Sind die 75 W ein realistischer Wert? Mir kommt das sehr hoch vor. Mit einer 1080 ti (TDP 250 W) lassen sich laut deiner Schätzung ~240 TB in ~4 min bedienen und für 20 TB in der gleichen Zeit bedarf es 75 W? Bei gleicher Fertigungsgröße und damit sehr ähnlicher Effizienz (low-end vs. high-end GPU) verstehe ich das nicht ganz. Hat das einen dermaßen ungünstigen nicht-linearen Verlauf?
Eigentlich sprechen wir fälschlicherweise immer von Leistung, es sollte der Verbrauch in kWh oder Wh dazu herangezogen werden. Die Anschaffungskosten von 40 TB sind dennoch ein vielfaches, das darf man nicht vergessen! Bis die Mehrkosten vom zusätzlichen Stromverbrauch der GPU aufgefressen sind, dauert es lange.

Quote
Wenn es eine derart simple Möglichkeit
gibt, mit einer 1080 die Mining-Kapazität zu verfünffachen, dann wundert es mich sehr dass weder
luxe noch blago das tun. Die haben beide >> 240 tb am laufen, sind bestens mit dem Mining-Prozess
vertraut in Theorie und Praxis.
Die Frage stellt sich mir auch schon von Anfang an. Wobei, wenn ich das Wissen dazu hätte, dann gäbe es hier keinen Thread ehrlich gesagt.
legendary
Activity: 1022
Merit: 1004
Hmm, also irgendwie bin ich davon nicht so recht überzeugt. Wenn es eine derart simple Möglichkeit
gibt, mit einer 1080 die Mining-Kapazität zu verfünffachen, dann wundert es mich sehr dass weder
luxe noch blago das tun. Die haben beide >> 240 tb am laufen, sind bestens mit dem Mining-Prozess
vertraut in Theorie und Praxis. Irgendwie erscheint mir das zu einfach um wahr zu sein, sorry..
Funktioniert dein Demonstrator denn wirklich und gewinnt er auch Deadlines so wie es bei 60 th zu
erwarten ist?
Die Wirtschaftlichkeit ist auch in dem kleinen Massstab schon scheissegal. Wenn ich für 45W
Mehrverbrauch aus 20 tb 60 tb zaubern könnte, würde ich das machen. Das Fenster fürs
Burst-Mining schliesst sich sehr sehr bald, allein schon der Vorteil keine 40 tb zusätzlich plotten zu
fällt da ins gewicht.
legendary
Activity: 1120
Merit: 1037
฿ → ∞
Quote
Das Problem was ich sehe: Es steht dem Dezentralisierungsgedanken entgegen, große Systeme haben Vorteile und nicht jeder kann sich Petabyte-Miner leisten.
Wenn der Skalierungseffekt im Grunde auf jede Kapazität anwendbar ist (?), dann ist das kein Problem. Man muss ja nicht zwingend mit einer high-end GPU arbeiten, die eine entsprechende Größe an HDD Kapazität voraussetzt. Kritisch wird es dann, wenn die notwendige Kapazität auf ein Minimum begrenzt werden kann und die GPUs bzw. deren Stromverbrauch überhand nimmt. Da wäre dann der Burstcoin nichts anderes, als einer der vielen anderen PoW Coins.

Runterskalieren geht zwar (mein kleiner Demonstrator  hier ist ein 20 -> 60 TB System), aber es ist nicht wirtschaftlich, weil ~30W (HDD) versus 75W (GPU). Von daher gibt es da ein Limit unterhalb dessen dieser hybride Ansatz keinen Sinn macht. Zumindest nicht so lange die Hardware so bleibt wie sie ist.

Wenn GPUs mal um den Faktor 10 effizienter werden, wird dieses Limit zu Ungunsten der HDDs sinken. Auf der anderen Seite können ja auch wieder bezahlbare 2.5 multi-TB SSDs kommen und die Waage geht in die andere Richtung.
legendary
Activity: 1513
Merit: 1040
Quote
Das Problem was ich sehe: Es steht dem Dezentralisierungsgedanken entgegen, große Systeme haben Vorteile und nicht jeder kann sich Petabyte-Miner leisten.
Wenn der Skalierungseffekt im Grunde auf jede Kapazität anwendbar ist (?), dann ist das kein Problem. Man muss ja nicht zwingend mit einer high-end GPU arbeiten, die eine entsprechende Größe an HDD Kapazität voraussetzt. Kritisch wird es dann, wenn die notwendige Kapazität auf ein Minimum begrenzt werden kann und die GPUs bzw. deren Stromverbrauch überhand nimmt. Da wäre dann der Burstcoin nichts anderes, als einer der vielen anderen PoW Coins.
legendary
Activity: 1120
Merit: 1037
฿ → ∞
Es ist keine Attacke, da man sich ja an das Protokoll hält. Es widerstrebt nur dem grünen Gedanken, dass es sich dann doch lohnt mehr Strom (GPUs) auf das Problem zu werfen. Idealerweise sollte (meiner Meinung nach) bei einem PoC-Coin wirklich nur der Plattenplatz zählen.

Der Witz ist ja, dass man bei den großen Minern weniger Strom mit GPU braucht, im vorliegenden Beispiel gehe ich davon aus, dass eine 1080Ti mit 300W auskommt, für die entsprechenden 96 Stck 10TB Platten kann ich von 500W ausgehen.

Ganz zu schweigen von den Anschaffungskosten. Ergo: So ein großer Miner ist auch energetisch effizienter.

Das Problem was ich sehe: Es steht dem Dezentralisierungsgedanken entgegen, große Systeme haben Vorteile und nicht jeder kann sich Petabyte-Miner leisten.
full member
Activity: 154
Merit: 100
Es ist keine Attacke, da man sich ja an das Protokoll hält. Es widerstrebt nur dem grünen Gedanken, dass es sich dann doch lohnt mehr Strom (GPUs) auf das Problem zu werfen. Idealerweise sollte (meiner Meinung nach) bei einem PoC-Coin wirklich nur der Plattenplatz zählen.
legendary
Activity: 1120
Merit: 1037
฿ → ∞
Meine Frage ist aber jetzt: Kann man einen PoC-Coin bauen, der nicht für diese "Attacke" anfällig ist?

Wie gesagt, halte ich das nicht für eine Attacke (Du - den Anführungszeichen nach zu urteilen - vermutlich auch nicht). Also sehe ich auch keine Notwendigkeit für einen Schutz. Es ist eine Design-Entscheidung und es macht auch nur Sinn bei großen Minern, wo der Skalierungseffekt die GPU effizienter stellt als die Menge an HDDs die sie ersetzt.

Quote
Und Scoops gibt es damit man nicht bei jedem neuen Block seine Plots KOMPLETT durchgehen muss, sondern nur den Teil, der zum aktuellen Scoop gehört oder? Sorry, wenn ich hier etwas unbedarft frage. Wenn jetzt alle Noncen (Tickets, Deadlines) unabhängig voneinander wären, würde einem die GPU ja nicht helfen, da man keinen Ansatzpunkt hat, wo man anfangen soll zu rechnen.

Wir haben ja bereits ausgeführt, dass ein Miner pro TB nur ungefähr 256 MB Daten einlesen muss. Wir wissen, dass wir beim BURST mining a) beliebig viele Plot files haben können, b) es egal ist wo diese im "nonces"-Suchraum positioniert sind. Letzteres impliziert auch, dass diese z.B. "Löcher" aufweisen können.  Wink
full member
Activity: 154
Merit: 100
Ich finde die Idee des hybriden Burst-Minings sehr spannend. Über ähnliches hatte ich auch schonmal nachgedacht, ich müsste halt auch mal das Paper lesen ^^

Die Frage ob man das machen soll: Wenn's ökonomisch sinnvoll ist ja, sonst macht's ein anderer. Vor allem jetzt wo die Idee draußen ist.

Meine Frage ist aber jetzt: Kann man einen PoC-Coin bauen, der nicht für diese "Attacke" anfällig ist? So wie ich das verstehe baut dein Ansatz darauf auf, dass du dir bestimmte Dinge vorberechnest, die den Suchraum verkleinern, in dem man dann ad-hoc mit der GPU minet. Dass das überhaupt geht, hängt doch damit zusammen, dass es für jede Nonce mehrere Scoops gibt oder? Und Scoops gibt es damit man nicht bei jedem neuen Block seine Plots KOMPLETT durchgehen muss, sondern nur den Teil, der zum aktuellen Scoop gehört oder? Sorry, wenn ich hier etwas unbedarft frage. Wenn jetzt alle Noncen (Tickets, Deadlines) unabhängig voneinander wären, würde einem die GPU ja nicht helfen, da man keinen Ansatzpunkt hat, wo man anfangen soll zu rechnen. Aber dann müsste man wie gesagt für jeden Block auch alles einlesen, da jedes Ticket potentiell gewinnen kann.

Stimmt das ungefähr was ich sage?
full member
Activity: 353
Merit: 100
sorry für späte Antwort; darf nur alle 6 Minuten mal.

Die Annahme von @Evolver ist so nicht korrekt:
Quote
das (hinter die accountID(z.b. 1234567890) gepackt) ergibt z.b. 12345678901a2b3c4d
die 1a2b3c4d sind zwar 8 Zeichen (auf dem Bildschirm), werden aber intern durch 4 Bytes repräsentiert (1a, 2b, 3c, 4d - alles Zahlen, die in 1 Byte passen). Somit ist oben die Account-ID + 4 Byte bzw Account-ID + 8 Bildschirmzeichen dargestellt.

mein lieber I, Karus, schön das es dich gibt! genau da bin ich durcheinander gekommen 8 zeichen <> 8 byte! Aber das Prinzip sollte stimmen (ist es so?)

legendary
Activity: 1120
Merit: 1037
฿ → ∞
Zur Klarstellung, RFC = "Request for Comment" - der vorliegende Beitrag stellt kein Angebot, Aufruf zum Kauf o.ä. dar.
Er soll vielmehr als Entscheidungsfindung für ein eventuell Solches dienen.

Als Comment von mir: Das sieht für mich (der recht unbedarft ist) alles sehr überlegt aus. Wenn dann sogar schon ein funktionierender Prototyp existiert, dann steht doch dem Angebot eigentlich nichts mehr im Wege, oder?

Dazu meine Frage: Die grob überschlagenen 15.000 Euro verteilen sich auf 1,2 Petabyte = 1.200 Terabyte. Angeboten werden sollen Shares zu 100 Terabytes (?). Somit wären 12 Shareholder möglich, und 1 Share würde  Pi*Daumen (gibt's da kein Kürzel für?) 15000 / 12 = 1.250 Euro kosten. Liesse sich die Sharegrösse noch verkleinern? Bei den Kosten wäre 10 TB meine Wunschvorstellung.

Und nun zum Wichtigsten: Mit welchem Rücklauf wäre zu rechnen? Das Nachrechnen fällt mir momentan schwer, da ich die notwendigen Parameter nicht kenne.

Wenn man genau darüber nachdenkt, ist das Alles eher nicht überlegt. Auf der technischen Seite ja, aber die Sinnfrage habe ich mir selbst noch nicht beantwortet.

Wenn ich mir die BURSTS, die täglich gemined werden ansehe: http://burstcoin.biz/charts/burstcoins-mined-per-day

Sehe ich erst einmal, dass man schon recht spät zur Party gekommen ist. Hinsichtlich Rücklauf, eine grobe Überschlagsrechnung:

Wenn 500k COINS pro tag bei 50PB Netzkapazität ausgeschüttet werden, dann hätte man bei 1PB 10k coins.

http://burstcoin.biz/calculator spricht von 13778 - sei's drum. Das sind also derzeit ca. 190 EUR? Oder gerne weniger - man soll sich die Sachen ja nicht schönrechnen.

Sagen wir 150 EUR, dann wären das 100 Tage. ABER: Ich habe nicht gesagt, dass ich die Shares zum Selbstkostenpreis weitergeben würde.
Wenn 100TB ~3000 EUR kosten, mich aber - in diesem speziellen Fall - 1500 EUR, dann ist die Preisfindung irgendwo dazwischen.

Hinsichtlich kleinerer Shares habe ich mir auch noch keine Gedanken gemacht (siehe "sehr überlegt"  Wink ) Bin da aber nicht so begeistert von, weil Flohzirkus-Management gehört nicht zu meinen Kernkompetenzen. Damit möchte ich nun keine kleinen Shares als Flöhe beleidigen, aber ich sehe nicht, wie ich nebeher 120 Leute bemuttern sollte.


Fakt ist, dass egal was man sich einreden mag, man gegenwärtig BURSTs minen sollte mit Hardware die man eh schon hat, oder (wie ich) sich welche besorgt für die man auch anderweitig Verwendung hat. Ansonsten ist der Rücklauf nicht unter 200 Tagen - sehe ich das richtig?
member
Activity: 70
Merit: 10
sorry für späte Antwort; darf nur alle 6 Minuten mal.

Die Annahme von @Evolver ist so nicht korrekt:
Quote
das (hinter die accountID(z.b. 1234567890) gepackt) ergibt z.b. 12345678901a2b3c4d
die 1a2b3c4d sind zwar 8 Zeichen (auf dem Bildschirm), werden aber intern durch 4 Bytes repräsentiert (1a, 2b, 3c, 4d - alles Zahlen, die in 1 Byte passen). Somit ist oben die Account-ID + 4 Byte bzw Account-ID + 8 Bildschirmzeichen dargestellt.
full member
Activity: 353
Merit: 100
lasst mich arzt, ich bin durch... ich habs korrigiert Roll Eyes
sr. member
Activity: 317
Merit: 251
für 4 Bytes (32 Bit) ist das Maximum 4294967296 ( 0 - 4294967295 )
für 8 Bytes (64 Bit) ist das Maximum 18446744073709551616 ( 0 - 18446744073709551615 )

Also sollte es kein Problem sein, dass ich von Nounce 50 Milliarden an plotte? Hab gerade einen kleinen Schock bekommen, das sich das dann evtl. doppelt mit Nounces, die ich vorher schon geplottet hatte.
member
Activity: 70
Merit: 10
für 4 Bytes (32 Bit) ist das Maximum 4294967296 ( 0 - 4294967295 )
für 8 Bytes (64 Bit) ist das Maximum 18446744073709551616 ( 0 - 18446744073709551615 )
Pages:
Jump to: