Wieso sollte man den Betrag einer Transaktion begrenzen und was hat das mit der Größe der Transaktion zu tun?
Um mehr Nachkommastellen zu realisieren ohne auf ein größeres Zahlenformat zu wechseln… Ergo Speicherbedarf bleibt der gleiche.
Es gibt keine Nachkommastellen im Bitcoin Netzwerk. Das wird nur nachträglich konstruiert. In den Transaktionen stehen alle Beträge ganzzahlig in Satoshis.
Diese Basiseinheit kann man auf den ersten Blick nicht einfach ausweiten also auf eine kleinere Einheit umrechnen. Dafür bräuchte es eine Hard Fork.
Eine deartige Begrenzung wäre aber sowieso nur mit einer Hard Fork möglich und ist sehr unrealistisch.
Deine Logik scheint nach Außen hin Sinn zu ergeben, aber im Programmcode ändert sich dadurch nichts, weil für die Variable immernoch der gleiche Datentyp Int64 verwendet wird.
Ich kann bspw. die Zahl „1“, welche eigentlich nur 1 bit bräuchte, auch als Int64 darstellen und dann benötigt sie 8 Byte, obwohl da immernoch nur eine „1“ drin steht.
Was ich damit nur klar machen möchte: Verwendung =/= Speicherbedarf
Ja, das ist mir klar, dass der Speicher immer verwendet wird.
War nur eine Idee, das virtuelle Komma zu verschieben, da der Wert ja dann gigantisch hoch sein wird.
Wo widersprechen wir uns? @mcwinston hat doch genau erklärt dass die Betrag in einem 64 bit int liegen. Im Netzwerk gibt es keine Nachkommastellen.
Es geht mir nur darum dieses Missverständnis zu vermeiden dass wir „nur Nachkommastellen anhängen“, was mit einer Soft Fork kein Problem wäre. (Soft Fork bedeutet immer: Alte Regeln funktionieren auch innerhalb der neuen Regeln).
Wir erweitern aber diese Ganzzahl und müssen komplett neu umrechnen. Das ist eine Ausweitung der Regeln.
Nur um einer Diskussion vorzubeugen, mir ist klar, dass ein Integer keine Nachkommastellen hat und die nur interpoliert sind… 
Ja, jetzt habe ich dich verstanden.
Im Grunde meinst du, da irgendwann eh niemand eine Transaktion mit mehreren hunderttausend Bitcoins machen wird, könnte man einfach statt bisher um 8 Stellen zu verschieben, einfach 10 oder gar 11 Stellen verschieben.
Das wäre schon ein fetter Bug, der in irgendeiner Form abgefangen werden müsste, falls es aus irgendwelchen Gründen doch zu so einer Transaktion kommt.
Im Endeffekt würde man damit einen Angriffsvektor öffnen…sprich das irgendjemand genügend BTC zusammenbekommt und das Netzwerk im schlimmsten Fall lahmlegt.
Natürlich macht dies Ökonomisch keinen Sinn, weil der Angreifer sein eigenes (nicht unerhebliches) Investment auf einen Schlag wertlos machen würde.
Edit:
Die Aussage mit dem „Verschieben“ klingt natürlich merkwürdig. Ich weiß, dass im Code nix verschoben wird, sondern stets nur mit ganzen Zahlen gemäß Int64 gerechnet wird. Die Nachkommastellen sind nur eine Interpretation der GUI.
1 „Gefällt mir“
Ja, man müsste vermutlich ein neues Adressformat einführen. Alle Adressen vor dem Fork müssten dann mit dem alten interpolierten Komma bewertet werden und nach dem Fork die neue Adresse mit mehr interpolierten Kommastellen. Und im Code müssten Transaktionen über 100.000 BTC als invalid erklärt werden.
Tja, an dieser Stelle kommt dir aber das UXTO-Modell in die Quere!
Schau dir bspw. mal diese Transaktion einer der größten Börsen an:
Da siehst du, dass es dennoch Wallets geben kann, die zumindest so viele BTCs halten. Und wnen sie nur wenige BTC von dieser Wallet abziehen wollen, müssen trotzdem erstmal alle „bewegt“ werden. Wie das in 50 oder mehr Jahren ist, weiß man natürlich nicht, aber mit so einer Protokolländerung würde man das Netzwerk dennoch stark einschränken.
Da fällt mir gerade ein super günstiger Angriffsvektor für diesen Fall sein.
Jemand hat 99.999,951 BTC auf seiner Adresse, weil diese Summe ja noch akzeptabel ist. Und ich schicke demjenigen einfach 0,04901 BTC und **ZACK Netzwerk im A*sch!
Weil das Problem ist ja, dass die Nodes auch prüfen müssten, ob nach der Transaktion nicht zu viele BTCs auf der Adresse sind.
Nein, das ist schon sehr unsauberes Programmieren… dann echt lieber die 3 regulär möglichen Nachkommastellen im 64bit-Integer ausnutzen oder gar auf 128bit-Integer wechseln. Das wäre zumindest sauber und ohne weitere Einschränkungen.
2 „Gefällt mir“