Topic: Zukunft ohne Miner - Was kommt zum "Schluss"? (Read 2764 times)

Ich hab auch ein paar Probleme mit den Gebühren: Aus meiner Sicht ist die Gebührenstruktur schwer mit einer weiten Verbreitung und
einem hohen BTC/$ Kurs in Einklang zu bringen. Grund: Die Gebühren sind in BTC festgelegt, und wenn der BTC/$ Kurs über die Maßen
steigt, dann muss ich plötzlich zig $ pro Transaktion ausgeben   Dann werden BTC unattraktiver und der Kurs fällt bis die Transaktionen
wieder vernünftig teuer sind. Die Gebühren führen also zu einer Art Selbstregulierung, und zwar gegen einen großen Kursanstieg, was ja nicht so
schön ist

Das Argument, die Gebühren lassen sich jederzeit ändern (genauer gesagt, die Standard-Einstellung im Client, ab welcher Fee-Höhe Transaktionen
eingebaut oder relayed werden), entkräftet das Problem nur teilweise. Das habe ich mir mal von DeathAndTaxes erklären lassen: Es
gibt gewisse orphan costs (und die messen sich - das ist der Punkt - in BTC), die spiegeln das Risiko eines Miners wieder, dass der Block verwaist weil er eine
bestimmte Transaktion akzeptiert hat. Ein rationaler Miner wird keine Transaktion akzeptieren, deren Fee unter der Orphan Cost
liegt. Die Orphan Costs sind im wesentlichen konstant innerhalb einer Block Reward Period. Wenn also der BTC/$ Kurs so hoch steigt
dass die Orphan Costs zB 10$ pro kB (um nur eine Zahl zu nennen) betragen, dann gibt es ein Problem, dem man nicht mit
Fee-Kürzungen beikommt.

Um das Ganze mal zu einem versöhnlichen Ende zu bringen:

Wir ALLE werden das Erreichen des 20.999.999.xxxxxxx BTC nicht mehr miterleben,
daher sind alle o.g. Rechnereien zwar ganz nett, aber für unsere "Lebenszeit" völlig
irrelevant !!!

Interessanter ist wohl eine "Langzeit-Prognose" bzgl. des BTC-Kurses...

MfG Tom

hey bill,
die gebühren werden als einkommen mehr als ausreichen, es wird aber nicht für alle reichen... am ende werden die über bleiben die ihre miner günstig mit strom versorgen können das wird auch bedeuten das die hashrate wenn es aufs ende zu geht wieder drastisch fallen wird...
der code wird nicht geändert werden sollte dieses passieren ist der btc tot.
der blockreward wird irgendwann ebenfalls irrelevant da es mehr an gebühren geben wird als man per block reward bekommen wird...
just my 2 btc

Dann lese mal den Code durch und fast alle Berechnungen erfolgen in Floats. Lediglich in Hash-algorythmen sollte man auf floats verzichten, weil sie langsamer sind und ständig Rundungsprobleme machen. Und selbst doppelgenaue Floats keine 8 Stellen mehr abdecken, es also zusätzlich zu problemen kommt.

Die von dir angesprochenen Probleme betrafen Hash-Algorythmen und dort hat Float nichts verloren. Aber...wenn ich unbedingt will kann ich es auch damit lösen. ich muss dann nur höllisch aufpassen nie eine Rundung zu vergessen. Der Code wird unnötig kompliziert, langsam und Fehleranfällig.

Kleines Detail am Rande: Irgendwo im Forum hat sich mal jemand darüber ausgelassen, dass Satoshi am Anfang von einigen Teilnehmern der Mailingsliste davon abgebracht werden musste, tatsächlich Floats (in welcher Auflösung auch immer) zu verwenden.  

Wen es interessiert, der kann ja mal unter sci.crypt Archäologie betreiben...

Nimm das modifiziere hier mach das...alles gut gemeint und diskussionswürdig.

Aber Programmieren ist Individualsache. Wenn ich etwas programmiere dann gibt es zuvor eine Idee oder ein Problem das ich lösen muss. Dieses Problem kann ich auf verschiedene Wege lösen. Ob ich dabei streng den regeln der Mathematik folge oder nicht ist meine Sache. Wenn ich an irgendeiner Stelle wo mir die Regeln negativ aufschlagen einfach künstlich eine grenze setze ist dann auch mir überlassen.

Wenn also derjenige der Bitcoin "erfunden" hat sagt: ich will das es nur 21 Millionen gibt, ist diese Aussage erstmal gesetz und nicht irgendwelche Regeln der Mathematik.

Wenn in der praktischen Umsetzung sich dann probleme ergeben, in diesem Fall durch das teilen der Ausschüttung von 50->25->12,5->6,25...usw füge ich einfach an passender Stelle die Ausnahmeregel ein. Ich könnte die Kommastellen abschneiden oder mathematisch runden. Und ich kann begrenzen, wenn X <1 then Ende.

Es geht mir nicht drum, dich als Blöd hinzustellen, auch habe ich gelesen was du von dir gegegen hast. Es geht drum, das man nicht Argumente der Mathematik bzw Gesetzmässigkeiten einfach auf Programmierung übertragen kann. fest gegossen in Silizium sind nur die 4 Grundrechenarten. 1+1 ergibt immer 2 das ist unveränderlich. Aber Wurzel aus 2 muss nicht 1,41 ergeben. Das kann ich umprogrammieren. Natürlich ist das Sinnlos. Aber es liegt in meiner Macht. Und weil das so ist, werden an der Stelle, wo man merkt das Dinge nicht so laufen wie man will, Exeptions programmiert.

Ich kenne programmierer die so wenig Ahnung von Mathe haben das sie fast jede Berechnung von einem Dritten sich schreiben lassen und sich nur um die verwaltung der Daten kümmern. Wenn ich denen erkläre was eine Fakultät(mathematisch) ist, fragen die mich, was eine Uni mit dem Programmierproblem zu tun hat. Wenn solche Leute programmieren, benutzen interessiert es sie nicht, das man Zahlen beliebig runterteilen kann. Wenn sie sagen das bei 1 schluss ist dann ist auch schluss. Oder du musst den ganzen Code ändern und seine Exeptions rausnehmen. Und wenn nunmal diese Ausnahmen drin sind, wird der nächste der dran rumprogramiert sich genau an diese Vorgaben halten. Auch wenn sie mathematisch nicht nötig wären.

Die 21 Millionen Coins Ausschüttung sind unverrückbar. Du darfs gerne mal den Vorschlag an Garvin machen, das zu ändern. Vieleicht geht er drauf ein. Aber ohne seine Zustimmung wirst du dich damit abfinden müssen, das es so ist wie es ist. Wenn du das änderst hast du einen Fork. Und der nutzt dir nichts, weil kaum jemanden deiner Ansicht folgt und somit in deinem Zweig der Coins landet. Ob es also zu mehr Coins kommt, ist keine Frage der Mathematik sondern des Konzepts. Das es mathematisch geht weis jeder sobald er 1,50 ausgeben kann. Und das man Programmcode umschreiben kann bestreitet ja auch keiner. Aber man MUSS ihn umschreiben, damit es funktioniert, es ist mit dem momentanen Code nicht möglich.

Tach auch minime,

Das "Wann" ist aber genau der Witz an der Geschichte. Einige hier rechnen damit, dass irgendwann nur die Gebühren als Einkommen für die gefundenen Blöcke zur Verfügung stehen würden. Zumindest innerhalb der nächsten 150 Jahre würde das angeblich gelten.

Oben haben wir aber gesehen, dass diese Annahme so nicht stimmen muss.

Darüberhinaus könnten wir die MAX_MONEY-Konstante auch weglassen und dennoch werden wir keine 21 Millionen Bitcoins sehen. Zumindest solange nicht, bis ein konstanter Blockreward greift (in dem Fall würden wir dann doch dringend die explizite Definition MAX_MONEY brauchen).

Dieses lästige Theoriegesch***e hat also durchaus seinen Sinn. So kann später keiner mit der Meldung ankommen: "Wir haben die maximale Geldmenge in allen Bitcoinclients gehackt, indem wir einen Wert umgeschrieben haben!"
Wir wissen nun, dass das alleine überhaupt nichts ändern würde. Selbst wenn es wahr wäre.

Gruss,
Bill

Hallo trasla,

Danke trasla. Ich fing schon an, an meinem Verstand und dem Forum hier zu zweifeln.

Gruss,
Bill

Aloha Chefin,

ich habe gerade keine Ahnung, warum du das so persönlich nimmst. Aber nach der Nummer hast du dir eine entsprechende Antwort verdient.

Dann nimm mal bitte den Quellcode des Bitcoind. Modifiziere ihn bitte so, dass das Netzwerk pro Minute 1000000 Blöcke anpeilt und setze MAX_MONEY in der main.h auf 500 Millionen.
Daraufhin startest du das in einem kleinen (virtuellen) Netzwerk zwischen zwei Nodes.

Kleiner Tipp:Du solltest dich darauf einstellen, dass du überrascht wirst.
Lösung für Ungeduldige: Selbst wenn MAX_MONEY 500 Millionen gesetzt werden würde, würden wir nichtmal die 21 Millionen-Marke erreichen.

Die Mathematik ist also in dem Fall sehr wohl relevant.

Also ermöglicht Fließkommadarstellung immer genaues Rechnen? Interessant.

Lass mal kurz nachprüfen.


Ähm. *räusper*
Oh, schon sooooo spät?! Ich muss los!

Sollte im Bitcoinnetzwerk jemals Fließkomma in der Form eingesetzt werden, wie du es in deinem letzten Beitrag propagierst, dann steige ich aus dem Projekt komplett aus. Damit könnte man nämlich Bitcoins aus dem Nichts erschaffen. Im wahrsten Sinne des Wortes. Einfach ein Skript dranhängen, welches zwischen zwei Wallets immer weiter Beträge hin- und herverschiebt. Schon wird man reich.

Das ist der Grund, warum das Protokoll momentan die Satoshis als Integer speichert und auf Fließkomma komplett verzichtet.

Den Rest von dir kommentiere ich nicht, weil du offensichtlich am Thema vorbeiargumentierst. Wofür oder wogegen diskutierst du eigentlich mit mir?
Und vor allem: Warum?  

Gruss,
Bill

man man man do wieso einfach wenns auch kompliziert geht... es wird nicht mehr als 21mio coins geben da kannst du so lange rechnen wie du willst... auch der Zeitpunkt wann diese 21mio coins errechnet sind ist voll kommen irrelevant...

Irgendwie vertieft sich gerade massiv mein Eindruck, dass du, Chefin, nicht liest / verstehst was die Leute vor dir schreiben, aber trotzdem gerne den Eindruck erwecken möchtest, voll im Thema zu stecken, was dann in einer Mischung aus "falsch", "umständlich ausgedrückt" und "völlig am Thema vorbei" resultiert...

@bill86:
Ich stimme dir zu, bei beliebig genauer Teilung nähern wir uns natürlich asymptotisch dem Maximalwert an. Ich rechne auch damit, dass irgendwann in der Zukunft die Genauigkeit erhöht wird. Momentan gibt es aber viele Leute, die liebend gerne ausrechnen, wie viele BTC es exakt geben würde, wenn wir denn beim Satoshi als kleinste Einheit blieben. Und dann landen sie halt rundungsbedingt irgendwo unter 21kk, und dann nennen sie das die Obergrenze aller coins, ohne dazu zu sagen, dass es unter der Annahme einer gleich bleibenden Genauigkeit gilt.

@Bill86

Und wo war nochmal der Hinweis das Programmierung den Gesetzen der Mathematik folgt?

es ist scheiss egal, was die Mathematik sagt oder seine regeln. Ein Programmierer kann es so umsetzen oder ändern. Nur weil ich Fliesskommazahlen benutze heist das nicht, das ich die Ausgabe auch so mache. Ich muss sogar sehr oft umrechnen. Ein Bildpunkt zb lässt sich setzen oder nicht, es ist nicht möglich in 0,7 zu setzen. Aber ob ich ihn setzen muss berechnet sich aus Fliesskommazahlen um Rundungsfehler zu vermeiden. Auch in der Regeltechnik(Maschinenbau) braucht man oftmals Kommazahlen hat aber am Ende nur Integer als Ausgabemöglichkeit. Wenn ich einen Wert einlese, dann scaliere ich ihn auf meinen Regelbereich, passieren schon die ersten Rundungsfehler. Wenn ich dreimal 34,4 als 34 aufaddiere, komme ich zu 103 mathematisch oder 102 ohne Kommastellen. Deswegen rechne ich lieber in Fliesskomma, auch wenn ich es später nur als Ganzzahl benutzen kann.

Bei Bitcoin wurde es einfach so festgelegt. Es spielt dabei keiner Rolle, ob das mathematisch notwenig wäre oder nicht. Es geht drum, das man weis nach welchen Grundlagen man programmiert. Wenn ich zb den aufenthaltsort jedes Bitcoins wissen will lege ich eine Tabelle mit 21 Millionen Einträge an. Wenn ich dann erfahre, das man jeden Coin bis zu 8 Stellen hinter dem Komma aufteilen kann, muss ich 21millionen*10^8 Einträge anlegen. An dieser Stelle würde ich aber von einer reinen Hauptspeicherlösung zu einer Datenbank ausweichen. Aber auch diese wäre dann mit der passenden Anzahl vorbelegt.

So funktioniert Programmierung. Und ja..man könnte es OpenEnd programmieren, man einigen Nachteilen. Die Vorteile wären die flexibilität, die ich aber lt Vorgaben nie benötige. Die Nachteile wären das der Zugriff nicht mehr wahlfrei erfolgt sondern indiziert oder sequentiell. Beides kostet zusätzlich Zeit in der Verarbeitung. wenn ich 1 Million Datensätze a 16bytes habe kann ich auf den Datensatz 776345 zugreifen indem ich 16*776346 rechne und ab dieser Stelle 16 Bytes einlese. Ein lahmer Festplattenzugriff statt dutzende.

Es gibt genug Gründe warum man Dinge eben so und nicht anders macht. Man erkauft sich damit einfache Handhabung, aber muss dann damit leben, das Erweiterungen mehr Aufwand bedeuten. Aber nur weil man als Programmierer mit Zahlen umgeht muss man sich nicht unbedingt an die Mathematik halten. Lediglich die Grundregeln sind fertig implementiert, die kann ich nicht ändern. Wie du oben siehst(die zwei unterschiedlichen Zahlen bei den Datensätzen sind keine Tippfehler) rechnen wir Programmierer mit Null und Datensatz 10 ist der 11. Datensatz. Programmierer unterscheiden zwischen Null und Nichts. Null ist um 1 größer als Nichts. Aber Nichts ungleich -1.

wann genau der zeitpunkt erreicht wird ist voll kommen irrelevant...

Moin Moin mezzomix,

Das kannte ich bereits. Die Quelle dafür bezieht sich auf eine Diskussion hier im Forum.
Stimmen wir jetzt mal kurz ab? Wer ist dafür, dass der Mond aus Käse ist? Wenn die Mehrheit dafür ist, dann muss er das natürlich auch sein.
So schafft man sich zwar seine eigenen Wahrheiten, aber ganz sicher keine vertrauenswürdigen Fakten.

Mit verlässliche Quelle meinte ich sowas wie z.B. die src/main.h:
Da steht als obere Grenze aber übersetzt "genau 21000000 BTC".

Wir haben also eine Zahl, die dem Grenzwert der darunterliegenden geometrischen Reihe für
entspricht  (Term der geometrischen Reihe unterstrichen).

Wir schauen mal kurz in die ersten Kapitel irgendeines Standardwerkes für analytische Mathematik (Funktionen, Reihen, Analysis und dergleichen) und stellen fest, dass diese geometrische Reihe demnach sich immer weiter dem Grenzwert nähert, aber diesen bei idealer Genauigkeit niemals erreichen wird  (d.h. beliebiger Teilbarkeit der einzelnen Elemente, Fachchinesisch: reelle Zahlen).

Sollte also die Genauigkeit angepasst werden, so verschiebt sich der Zeitpunkt für die letzte Ausschüttung der Belohnung sehr weit in die Zukunft.
Bei signed int64 sind da noch 10 3 Nachkommastellen für die Satoshis drin. Sollte sich da nochmal was ändern, dann kommen natürlich noch Stellen hinzu.

Da wirst du mit 130 Jahren in der Zukunft nicht mehr auskommen. Es sei denn, die Halbierung wird irgendwann durch einen konstanten Betrag ersetzt (d.h. ab einer bestimmten Blockanzahl wird einfach die ausgeschüttete Blockbelohnung nicht mehr halbiert) oder es wird ein effizientes Verfahren entwickelt, welches bei wachsender Difficulty konstant mehrere tausend Blöcke pro Stunde finden kann.

Gruss,
Bill

Edith meint: Formeln sind ein bisschen besser lesbar, falls man Subscript und Superscript verwendet.
Edith sagt auch: Tippfehler fallen erst beim Veröffentlichen auf. Peinlich, wenn es den gedachten Sinn verfälscht.

Echt, es tun immer alle so, als ob es einen Punkt gibt, an dem Mining unrentabel wird, und dann hören alle schlagartig auf, und bitcoin is tot.
Aber das ist ebend nicht der Fall, das ganze ist ein selbst-regulierendes System. Wenn es unrentabler wird, gehen vielleicht manche Miner (die mit hohen Stromkosten...) vom Netz. Dadurch wird es automatisch für alle anderen profitabler, weil die difficulty sinkt. Selbst wenn massive Anteile wegfallen, dann haben wir halt ein paar zähe Tage, aber danach wieder ne wesentlich niedrigere diff. Und soweit absinken, dass ich mit meinem einsamen Asicminer Stick sämtliche Transaktionsgebühren einstreichen kann, wird es wohl nicht.

Die Ära ist bereits beendet. Die heutigen "Homeminer" wissen das aber nicht, oder besser gesagt wollen es nicht wissen.


Ich denke es wird auf ein Gleichgewicht hinauslaufen. Wenn die Miningleistung sinkt, wird es irgendwann wieder für andere interessant, Rechenleistung bereit zu stellen. Die aktuelle Entwicklung beweist, dass es für einige sogar interessant ist, wenn es sich wirtschaftlich nicht rechnet.


 

Für mich ist es ganz klar, dass die Ära des "Home-Mining" zu Ende geht.

Die Miner-Hersteller werden noch einige Jahre selber minen und evtl. auch noch Cloud-Mining-Verträge verkaufen, aber ewig wird auch das nicht gehen! Der finanzielle Aufwand, der getrieben werden muss, um immer bessere Asics zu entwickeln, die trotz der Stromkosten/Difficulty-Spirale noch den Break-Even erreichen, wird bald zu hoch werden. Das bedeutet, dass wohl der letzte Bitcoin-Block nie geschürft werden wird!

Andere Verfahren, Crypto-Systeme abzusichern, sind ja bereits im Einsatz. Proof-of-Stake hat nicht das Problem der Stromkosten/Difficulty-Spirale und hat sich bereits in einigen Altcoins bewährt. Aber vielleicht kommt da noch etwas besseres, wir stehen ja erst am Anfang einer großartigen Entwicklung.

Den Algorithmus (sind ein paar Zeilen im Code) und einen Taschenrechner. Irgendwann bleibt beim Halbieren nur noch der Rest übrig und das Ergebnis ist 0. Damit ist dann die Ausgabephase beendet - in ca. 130 Jahren.

Hier eine berechnete Tabelle: https://en.bitcoin.it/wiki/Controlled_supply

Hallo Rising,

Diese Zahl ist mir früher schonmal begegnet. Allerdings habe ich außer dem Halbwissen von einigen uninformierten Journalisten dazu nichts gefunden, weshalb ich diese eher zu den Mythen und Legenden zählte. Gibt es eine verlässliche Quelle dazu?

Sollte das die tatsächliche Grenze sein, dann sind meine obigen Überlegungen natürlich uninteressant. Der Grenzwert der erzeugten geometrischen Reihe ist dann höher als der gegebene Zielwert, weshalb dieser unter den gegebenen Umständen erreicht wird.

Dann wird wahrscheinlich der letzte Blockreward irgendwann zwischen 2120 und 2130 ausgeschüttet (theoretisch zwischen den Jahren 2121 und 21252125 und 2129). Die Belohnung zu diesem Zeitpunkt ist dann ungefähr 18,62645149230957 9,31322574615478 Satoshi hoch ("ungefähr" deshalb, weil ich hier trotz GMP mit Rundungsfehlern in meiner Simulation zu kämpfen habe). Das ist die Belohnung während der 28.29. Halbierung.

Gruss,
Bill

Edith sagt: Deine Simulation verursacht eine Menge Rechenfehler. Korrigiere das mal.
Habe ich gemacht.

Wenn es keinen Fork gibt: nie, da es nur 20999999,9769 Bitcoins geben wird.