Zukunft ohne Miner - Was kommt zum "Schluss"?

[trasla]

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.

[minime]

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

[bill86]

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.

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

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.

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.

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

Lass mal kurz nachprüfen.

Code:

0.28 + 0.07 = 0.35000000000000003

Ä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

[bill86]

Hallo trasla,

@bill86:
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.

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

Gruss,
Bill

[bill86]

Tach auch minime,

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

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

[Chefin]

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.

[mezzomix]

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.

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

[Chefin]

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.

[minime]

Tach auch minime,

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

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

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

[tomxtc1979]

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

[david123]

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.