Für sowas gibts ja eigentlich die BIPs, da sollte man nicht direkt an die Chefprogrammierer ran 
Finds stark, dass du da so in Materie einsteigst !!!
Von meinem Verständnis her ist aber das Hauptproblem, dass hier mit der Warteliste und dem entsprechend „Zufallsverfahren“ einfach nur ein potentieler Single Point Of Failure geschaffen wird .
Also meiner Meinung nach lässt sich deine „Warteliste“ nicht umsetzen, da hier immer einer Sybil Attack möglich ist. Das bedeutet, dass ein Miner unendlich viele pseudonyme in diesem Fall Miner anmelden kann um seine Wahrscheinlichkeit aus der Liste gezogen zu werden zu erhöhen. Ein ASIC hat ja keinen online überprüfbaren unique identifier mittels man einem ASIC eine Stimme in der Warteliste zu ordnen kann.
Ein Miner kommuniziert ja sowieso mittels einer Node mit dem Netzwerk, dass heißt er könnte wie von Skyrmion beschrieben seine Stimmanzahl durch zusätzliche Nodes erhöhen. Jeder seiner Nodes kann er im Hintergrund seine Gesamtanzahl seiner ASICS zuordnen, sodass er bei Auswahl seiner Node/Stimme seine gesamte Hashrate zum minen einsetzen kann.
Ein Nachweis durch Erbringung eines „Speedtests“ und der damit Verbundenen Verknüpfung der ASICS funktioniert auch nicht. Da du eine Registrierung in der Warteliste über einen gewissen Zeitraum gewähren musst, bis sich alle Interessenten registriert haben, kann ein Miner sich auch hier mit mehreren Nodes registrieren und nach einander innerhalb des Zeitfensters seine ASICS für seine Nodes den Speedtest ausführen lassen. Jetzt könnte man natürlich fordern, dass während des gesamten Registrierungszeitraums die Hashrate zum Beweis zur Verfügung gestellt werden muss, sodass man sie nicht für die Registrierung mehrerer Nodes nutzen kann. Auch hier kann ein Miner seine Hashrate für die Registierung auf mehrere Nodes aufteilen und bei erfolgreicher Ziehung einer seiner nodes /Stimme für den eigentlichen Proof of Work seine gesamte Hashpower/ Alle ASICS einsetzen ohne, dass es das Netzwerk überprüfen kann. Abgeliefert wird ja am Ende nur ein valider Block (Blockhash unterhalb des Difficulty Schwellenwertes) und nicht wie ein Miner zu diesem Ergebnis gekommen ist.
Du kannst also gar nicht verhindern, dass 1. die Warteliste manipuliert wird und 2. ein Miner der aus der Warteliste gezogen wird nicht einen Miningpool repräsentiert, der dann mit der Gesamten Hashrate des Pools minen wird.
Es ist gut, dass du dir Gedanken machst, aber wenn du das Bitcoin White Paper nochmal genau ließt, wird dir auffallen dass eben genau der Proof of Work Algorithmus in seiner Reinform solch eine Sybil Attack verhindert: „The proof-of-work also solves the problem of determining representation in majority decision making. […] Proof-of-work is essentially one-CPU-one-vote“ (Nakamoto 2008). Das Schlüsselwort ist hier „Work“. Der Beweis wird über die Erbringungen von Arbeit geleistet, dies ist bei deinem vorgeschalteten Lotteriemechanismus nicht der Fall und wenn es der Fall wäre, hätten wir keine Stromersparnis.
Ist es ein Killer-Gegenargument, wenn ich behaupte, dass jeder Mining-Betreiber seine „inaktiven“ Miner dann einfach während der Zeit in der sie nicht minen dürfen, auf einen anderen SHA256-Coin hetzt?
Einfach nur um die Rendite aufrecht zu erhalten…
In diesem Fall würde nur die Hashrate runter gehen und der Stromverbrauch sogar gleich bleiben^^
Sorry, nein, dieser Ansatz macht keinen Sinn…
No offense und Deine Begeisterung und Energie in allen Ehren.
Ich glaube, wenn man in diesen ‚space‘ eintaucht, entwickelt man eben genau besagte Gedanken. Und es ist auch toll, wenn dies als Grundlage für Diskussionen dient. Aber wie skyrmion schon mit "Dein Selbstbewusstsein möchte ich haben! 
" angedeutet hat, sind diese Ideen nicht neu und die Bitcoin-Community alles andere als auf den Kopf gefallen. Das klang zunächst alles wenig demütig und wirkte mehr als ‚Hey, ich habe die Entdeckung gemacht - lasst uns mal eben das Energie-Problem beseitigen‘.
Trotzdem ist es ja immer wieder schön sich anhand dieser Beispiele bewusst zu machen, weshalb das Bitcoin-Netzwerk so ist wie es ist.
Ich finde es ja durchaus löblich, dass du den Austausch in diesem Forum suchst. (Das spricht ja auch für das Forum).
Andere mit deiner Begeisterung und Energie würden folgendes tun (in ungefähr dieser Reihenfolge):
Zynismus beiseite. Der Entdeckung von Bitcoin sind Jahrzente Vorarbeit vorangegangen. Ein Suchbegriff für das von dir thematisierte Teilgebiet lautet: leader election.
Hallo! Ich bin echt begeistert von den vielen und so ausführlichen Antworten und denke, wenn es so viel Gegenwind gibt, bin ich wahrscheinlich doch auf dem Holzweg. Möchte es genau verstehen und kann vielleicht andere für gute Ideen anregen.
Ich merke, wie viel stärker noch das Argument Energie die Sicherheit von Bitcoin definiert, als ich es bislang wahr genommen hatte.
Ich versuche mal wieder gesammelt auf die Kommentare zu antworten, da es sonst zu chaotisch wird.
Vorher rudere ich noch mal zurück, um zu erklären, warum nur eine Teilmenge (z. B. 10.000 Maschinen) zur gleichen Zeit „aktiv“ minen sollten:
Der Stromverbrauch reduziert sich immer auf max. 10.000 Maschinen die jeweils durch den Mining-Algorithmus voll ausgelastet sind und volle Leistung ziehen.
Dadurch verringert sich der Stromverbrauch massiv und das entkräftet die Einwände von Gegnern.
Man kann dann argumentieren, das Netzwerk verbraucht maximal 10.000 x die Wattzahl der Asics + Anzahl der Nodes * Wattzahl der Nodes. (Ja, es gibt sehr viele unterschiedliche Modelle und die neusten sind immer am sparsamsten)
Ich bin mir sicher, wenn wir auf einen hohen Stromverbrauch aufgrund von Sicherheit beharren, könnten das die Länder und Institutionen später einmal als „offizielles“ Argument gegen Bitcoin nutzen; egal ob es stimmt oder nicht oder welche anderen Gründe sie sonst noch haben.
Echte Zufallszahl:
Hier ein kurzer und bereits älterer Artikel vom 2016 der den Sachverhalt etwas erklärt und das es möglich ist:
https://winfuture.de/news,93326.html
Warum „Warteschlange“:
Wie bisher könnten sich unendlich viele Maschinen zum schürfen anmelden und werden in die Warteliste eingetragen. Sie sind aber nicht im Standby und halten eine permanente Verbindung zum Bitcoin-Netzwerk, als wenn sie ganz normal minen würden. Lediglich der stromintensive Algorithmus läuft nicht auf hochtouren und sie können keine neuen Blöcke finden.
Sobald eine solche Maschine in der Warteschlange die Verbindung abbaut, ist sie sofort aus der Warteliste raus und muss sich erneut anmelden. Eine doppelte Anmeldung an der Warteliste klappt nicht, da sie sich nur 1x anmelden darf.
Vielleicht suggeriert mein Begriff „Warteliste“, daß die Maschinen nur dumm herumstehen und andere Dinge machen könnten. Das meine ich nicht so. Vielleicht sollte ich es besser als „stromsparende Pre-Mining-Phase“ benennen, in der die Maschinen wesentlich stromsparender laufen.
- Ich merke aus den Antworten, dass alle etwas gegen die Warteliste haben. Welche anderen Möglichkeiten seht ihr, dass die Maschinen zwischenzeitlich einmal den Stromverbrauch senken?
(Vielleicht kann man die Anzahl aktiv schürfender Rechner auch anders begrenzen, indem dennoch alle Rechner angemeldet sind.)
@skyrmion:
Das tut mir leid, welche Argumente habe ich vergessen? Ich hoffe ich kann es hiermit etwas besser erklären.
@Bontii:
Das Beispiel von Bontii finde ich klasse und klar wäre es super, wenn die Miner alle so fortschrittlich arbeiten würden. Aber wenn z. B. sogar 95% der Energie darüber und über Wind, Wasser und Solar erzeugt werden würden, hätten wir dennoch keinen Beweis für die Länder und Institutionen, die immer noch behaupten würden, dass a) zu viel Strom verbraucht wird oder b) man den Strom auch anders nutzen könnte.
„Je mehr man in den Code einfügt desto angreifbarer wird der Bictoin.“ → Das stimmt natürlich. Daher immer besser Bitcoin als andere Altcoins halten, an denen permanent herumprogrammiert wird.
„Es gibt unzählige Parameter, die man auf die Random-Funktion anwenden könnte und die zusammen kombiniert eine Zufallzahl sicher machen] … Klingt z.B. nach einem gigantischen Potential für Angriffe“ → Mit diesen Werten wird der Zufallszahlen-Generator nur initialisiert (siehe Link oben) Erst nach dieser Initialisierung wird die „echte“ Zufallszahl ermittelt. Ich meine hier keinesfalls, dass aus diesen Angaben die Zufallszahl zusammengerechnet werden soll.
@Mcwinston:
Ja, also die „echte“ Hashrate der beteiligten Maschinen ist dann natürlich geringer, aber da man vorher zum stromsparenden Pre-Mining in die Warteliste muss, ist sie eigentlich genau gleich hoch. (Sicherheit = Wartende Miner + Verlosung + Gewinner beim Mining)
Ich denke nicht, dass die Änderung im Protokoll zu einem Preissturz führen wird, sondern ganz im Gegenteil zu einer Preis-Steigerung:
Hashrate = aktiv minende Rechner + Rechner in Warteschlange (ja, auch über die Rechner in der Warteschlange ist ja das Netzwerk weniger angreifbar)
„Ist es ein Killer-Gegenargument, wenn ich behaupte, dass jeder Mining-Betreiber seine „inaktiven“ Miner dann einfach während der Zeit in der sie nicht minen dürfen, auf einen anderen SHA256-Coin hetzt. Einfach nur um die Rendite aufrecht zu erhalten“
→ Theoretisch ist es ja der gleiche Algorithmus, auf den der Asic optimiert wurde. Aber das müsste man irgendwie verhindern.
@HODLer:
Ich habe versucht, alles akribisch zu lesen. Nein, der Miner arbeitet schon, ist nur so lange inaktiv im etwas stromsparenderen „Pre-Mining-Status“, bis er zum Minen gezogen würde. Wenn er sich aus der Warteschlange abmelden würde bzw. die Maschinen ausschalten würde, hat er keine Chance mehr am Mining teilzunehmen.
Kann mir einmal jemand ganz genau erklären, wie die Warteliste angegriffen werden könnte?
Ich sehe, es ist nicht leicht, einen neuen Algorithmus zu gestalten und wird noch schwerer, wenn schon ihr als langjährige Bitcoin-Kenner so starke (sicherlich auch berechtigte) Zweifel habt, erst recht erst die normalen Investoren und Nutzern zu überzeugen.
Ich finde es toll, wie stark argumentiert wird. Aber meint ihr es gibt wirklich keine Möglichkeit, jemals den Algorithmus stromsparender zu machen, statt nur Grüne Energie zu nutzen?
@sutterseba:
Ja, die Auswahl der Rechner aus der Warteliste ist vollkommen zufällig. Aber die ausgewählten 10.000 Rechner, die minen, weisen unterschiedliche Leistungen auf. Da können extrem schnelle und auch langsame Asics dabei sein.
Für einen 51% Angriff: Besteht die Warteliste z. B. aus 49 Millionen Asics, müssten 51 Millionen Asics vorhanden sein, die sich dann zuerst alle gleichzeitig an die Warteliste anmelden. (Sehr unwahrscheinlich) Damit stehen 100 Millionen Asics in der Warteliste und der Zufallsgenerator wählt davon nur 10.000 Asics aus. Wenn wir dann von einer wirkliche zufälligen Verlosung sprechen, könnte (nicht müsste) dann ein Angriff möglich sein. (Ggf. könnte es durch die Reduzierung der Asics in der Warteschlange aber auch schon minimal vorher einen Angriff geben, wenn nämlich zufällig mehr angreifende Rechner ausgelost werden würden.)
Durch die 24 Stunden Wartepause nach einem erfolgreichen neuen Block, wäre es aber extrem unwahrscheinlich, die Kette falsch weiterzuschreiben.
Bislang könnten auch 51 Millionen angreifende Asics direkt ohne Warteschlange losminen und ebenfalls angreifen.
@Sich:
Jede Änderung im Code birgt natürlich gefahren. Aber wie genau könnte die Liste angegriffen werden?
@Normen:
„Das bedeutet, dass ein Miner unendlich viele pseudonyme in diesem Fall Miner anmelden kann um seine Wahrscheinlichkeit aus der Liste gezogen zu werden zu erhöhen.“ > Die Anmeldung dürfte wie bisher auch immer nur 1 x erfolgen, sonst könnten diese dann nicht mehr „losminen“.
Aber ich verstehe, dass ihr hier Angst habt, das das irgendwie umgangen werden könnte.
„Ein Nachweis durch Erbringung eines „Speedtests“ und der damit verbundenen Verknüpfung der ASICS funktioniert auch nicht.“ - Das verstehe ich. Lassen wir das lieber weg:
Es geht also um die Umgruppierung und den Zusammenschluss während des Speed-Tests: Zuerst meldet sich ein Asic-Verbund von vielen Maschinen an und erzielt einen hohe Leistung, schaltet dann herunter und dann beim Mining wieder hoch. Besser kein Speed-Test. Dann kommen auch andere Maschinen dran.
@Makowski
Guter Tipp (Scherz). Das Schlagwort war genial! Da braucht man, um dass durchzuarbeiten.
Nochmals vielen Dank und behaltet bei den aktuellen Kursen die Ruhe!
Ja, er verbraucht Strom. Aber nein, er arbeitet nicht, also in dem Sinne als das er etwas erwirtschaften würde. Er läuft schlichtweg unnötigerweise in dem stromsparenden Modus.
Das ist als würdest Du Dir einen Ferrari kaufen, den Du aber nicht fahren darfst. Außer Du gewinnst glücklicherweise bei der Tombula. Da überlegt man sich fünf mal, ob sich dieses ‚Invest‘ lohnt.
Der Miner hängt einfach nur in der Warteschlange fest. Das Verhältnis von Investition zu potentiellen Gewinn wird schlecht. Miner springen ab. Das Netzwerk wird unsicher. Angreifbar. Nein… diese Änderungen möchte ich nicht.
… da es keinen echten Zufall geben kann, ist das eine Schwachstelle. Habe ich jetzt aber schon mehrfach gesagt.
Nein! Innerhalb der 10.000 muss ja die Hashrate >50% sein, nicht in der Warteschlange. Das bedeutet dass man als Angreifer, obwohl man in der Warteschlange noch relativ klein ist, durch Zufall bei den aktiven 10.000 eine Mehrheit haben kann. Mehr Hashrate → Mehr Sicherheit, punkt.
Was unfassbar unwahrscheinlich ist, allein schon weil man dann mit nutzloser Hardware in Milliardenhöhe da stehen würde.
Ahh, moment, bei deinem Vorschlag steht man ja auch auf ungenutzter Hardware rum 
Aber mal ernsthaft, du kannst das Risiko eines 51% Angriffs in deinem Vorschlag nicht damit entkräften indem du sagst „ist ja aktuell auch möglich“. Das steht in KEINEM Verhältnis.
Das ist ein sehr, sehr, sehr, sehr großes „irgendwie“!
@mcwinston hat hier ein Totschlag Argument.
Lustig, das aus den total verkehrten Kontraste-Report. Sie haben es noch immer nicht richtig gestellt.
Eigentlich wollte ja Roman unter Youtube noch ein Feedback zu ihrer Antwort an ihn geben.
Hallo!
Blockquote „Das ist als würdest Du Dir einen Ferrari kaufen, den Du aber nicht fahren darfst. Außer Du gewinnst glücklicherweise bei der Tombula.“
Sehr guter Vergleich: Alle 50 Millionen Ferraris, die sich beim Rennen angemeldet haben, stehen mit laufenden Motor und fahrtbereit an der Startlinie. Die Motoren verbrauchen im „Leerlauf“ aber wesentlich weniger Benzin als wenn alle 50 Millionen Ferraris zur gleichen Zeit das Rennen fahren würden. Ein Zufallsgenerator zieht dann davon 10.000 Ferraris, die dann losfahren und von denen der schnellste gewinnt.
Alle nicht am Rennen angemeldeten Ferraris, die nicht mit laufenden Motor auch nicht an der Startlinie stehen (sondern z. B. im Museum), sind natürlich nutzlos und können das Rennen nie gewinnen.
Alle Ferraris an der Startline wurden gekauft, da man kalkuliert hat, daß sie losfahren dürfen und dann im Rennen gewinnen können.
Wie schaut es jetzt aus? Ca. alle 10 Min. kann auch nur ein einziger der am Rennen teilnehmenden 50 Millionen Ferraris gewinnen. Auch jetzt verlieren alle anderen und der Benzinverbrauch ist wesentlich höher, die Ferraris verschleißen unter Dauervollauslastung schneller.
Entschuldige, es ist für mich sehr schwer zu verstehen.
Klar ist ein einfacheres System mit weniger Code immer sicherer, aber es wäre gut, wenn es irgend eine Lösung dennoch geben würde bei diesem Trilemma
Ach ja die Chefprogrammierer 
By the way
Man wird das nie lösen können.
Da kann man meiner Meinung nach diskutieren ohne Ende. Es ist immer ein Kompromiss aus Schnelligkeit, Sicherheit und Dezentralität
Lg euer Roadrunner
Ja aber die Chance ist höher, was verstehst du denn daran nicht???
Ich werde jetzt nicht zum 1000sten mal die selben Argumente wiederholen…
Der Ansatz ergibt überhautp keinen Sinn und ist nicht umsetzbar.
Hallo!
Danke auch Dir für die Antworten!
Ok, wir sehen das mit dem von Algorithmen ermittelten echten Zufällen trotz meines Links einfach anders.
Vielleicht gibt es ja auch eine andere automatisierte Möglichkeit, die Warteliste auf 10.000 Maschinen zu begrenzen?
Blockquote " Nein! Innerhalb der 10.000 muss ja die Hashrate >50% sein, nicht in der Warteschlange."
Ja, das meinte ich mit „…(Ggf. könnte es durch die Reduzierung der Asics in der Warteschlange aber auch schon minimal vorher einen Angriff geben, wenn nämlich zufällig mehr angreifende Rechner ausgelost werden würden.)“
Mit anderen Worten: Wenn aus der Warteliste eine wirkliche Zufallsfunktion die aktiven Miner auswählen würde, wäre das Verhältnis zwischen „Fairen Minern vs. Angreifern“ auch in der reduzierten Warteliste über viele Ziehungen durch das statistische Mittel immer das Gleiche. Kann aber in einzelnen Ziehungen auch mal davon minimal abweichen.
Blockquote „… Ahh, moment, bei deinem Vorschlag steht man ja auch auf ungenutzter Hardware rum
Finde das verdreht Wortspiel gut gekontert und musste auch schmunzeln.
Blockquote „…Theoretisch ist es ja der gleiche Algorithmus, auf den der Asic optimiert wurde. Aber das müsste man irgendwie verhindern.“
Ich komme nochmals auf die super Analogie mit den Ferraris zurück. Die Fahrer sitzen in den Autos mit den laufenden Motoren und warten auf den Einsatz. Auch hier müsste man verhindern, dass diese Autos nicht zur gleichen Zeit noch irgend ein anderes Rennen auf einer anderen Rennstrecke fahren, d. h. während sie „warten“ keinen Coin minen, der die gleiche Berechnungsmethode nutzt wie Bitcoin.
Technisch müsste das doch möglich sein, daß sich die Maschinen vorab mit dem Bitcoin-Netzwerk verbinden und dann keine anderen Aufgaben zur gleichen Zeit lösen können, weil sie mit etwas nicht so stromintensiven anderen beschäftigt sind?
Entschuldige, - vielleicht gibts aber jemand mit einem besseren Vorschlag. Wäre gut, wenn sich das irgendwie lösen lässt und den Gegnern die Argumente nimmt. Oder nicht?
Es würde aber niemand einen Ferrari für dieses Rennen kaufen. Verstehst Du das?
Sehr kontrovers. Mal sehen, ob jemand einen anderen Vorschlag hat.
Fangen wir mal so an:
Ist es möglich, in Zukunft den Code von Bitcoin so anzupassen, dass insgesamt weniger Strom verbraucht wird?
Falls ja, welche Vorschläge habt ihr?
Über viele Ziehungen. Im statistischen Mittel.
Es reicht aber eine einzige Losung mit >51% angreifenden Minern. Ein nicht tragbares Risiko.
Es ist schlichtweg nicht gewünscht.
Neue Analogie:
Dicke des Safes =! Energie’verbrauch’
Ich will einen verdammt dicken Safe, um die gesamte Geldmenge der Welt zu schützen. Das heißt es braucht einen großen Energiebedarf.
Wichtiger ist eben die Frage, woher diese Energie kommt.
Und daran muss gearbeitet werden. Das macht dann auch Diskussionen über den Energieverbrauch obsolet.
Blockquote „Dicke des Safes =! Energie’verbrauch’“
Nicht ganz. Zur besseren Sicherheit beitragen könnte:
)Ja, zudem ist es wichtig, woher die Energie kommt. Aber wie soll das dann den Kritikern nachgewiesen werden?
