Hallo Community,
Roman hat ja noch mal schön erklärt, dass eine Codeveränderung nur dann final möglich ist, wenn die Mehrheit der Miner und Full Node-Betreiber zustimmt.
Dabei kam mir ein Gedanke, den ihr bestimmt und hoffentlich schnell entkräften könnt.
Ich bin nämlich kein IT-ler und ich weiß nicht, wie das letztendlich organisatorisch und technisch umgesetzt wird mit der Zustimmung. (Drücke ich z.B. bei Zustimmung auf einen Knopf? Wie werde ich überhaupt eingebunden/gefragt etc.))
Die Frage lautet: Könnte es einem Programmierer gelingen, mit einer guten Programmierung Zustimmung zu erhalten, dann aber noch irgendwie anschließend etwas manipulieren zu können? Also z.B. nach der Zustimmung aber vor dem GoLive noch einen Bug oder Schadcode (oder ähnliches) mit reinlaufen zu lassen?
Danke für Eure Entkräftung dieser Bedenken.
Viele Grüße,
Rainer
Hier würde ich dir raten, dass du dich etwas mit Github beschäftigst, wie dort Code eingepflegt wird und ob man diese Änderungen bemerkt.
Die kurze Antwort lautet: Jedem halbwegs aufmerksamen Anwender sollte auffallen, dass nach einer „Abstimmung“ der Code geändert wurde, bzw. ein neues Release entstanden ist. Man würde demnach nur die Releaseversion verwenden, der man selber auch zugestimmt bzw. validiert hat.
Und nein, man kann bei Github keine Dateien austauschen, so dass es keiner merkt. Spätestens der Hash des Releases wird sich radikal ändern.
Die Zustimmung erfolgt durch die verwendete Node-Software. Je nach dem ob diese eine Funktion unterstützt, zählt das als Zustimmung oder nicht.
In dem Fall von Craig Wright könnte man z.B. ein Softwareupdate veröffentlichen, welches die alten Bitcoin auf eine neue Adresse „Zwangstransferiert“. Jede Node, die dieses Update verwendet, stimmt dieser manipulierten Blockchain zu. Alle nicht aktualisierten Nodes stimmen wiederum nicht zu.
Dies hätte aber zur Folge, dass die aktualisierten Nodes sich nicht mehr mit den nicht aktualisieren einig werden können, welche Blockchain (manipulierte/nicht manipulierte) nun die echte Blockchain ist. Weil beide Blockchains nach unterschiedlichen Regeln entstanden sind. Somit würden sich zwei verschiedene Netzwerke ergeben, die nicht miteinander kompatibel sind. Man spricht dann von einem Hard Fork.