In den letzten Wochen und Monaten kam in mir die Frage auf, was ist, wenn die Entwickler Bitcoin kaputt machen? In der Software-Branche wäre das nichts neues. Ehemals perfekte Produkte werden solange um Features erweitert, bis die Komplexität der Software ihren Nutzen in Frage stellt.
Die Frage kam mir das erste Mal während der Diskussion rund um Ordinals. Seit der Drivechain Diskussion gewinnt die Frage für mich wieder an Aktualität.
Im Rahmen von Bitcoin stelle ich mir vor, dass die Entwickler die Absicht haben, ihn um ein gutes Feature zu erweitern. Die Praxis zeigt jedoch, dass das Feature murks war und Bitcoin schadet (wie auch immer). Hierbei denke ich weniger an einen technischen Schaden, sondern vielmehr in Richtung einer Mechanik, welche die Anreize für die Teilnehmer des Bitcoin-Netzwerkes verschieben/zerstören.
Mit ist klar, dass Bitcoin nur auf Software Forks setzt. Doch ich lese auch immer wieder, dass bestimmte Änderungen (wenn ich mich recht erinnere, gehört die Umstellung / Absicherung vor Quantencomputern dazu) einen Hard Fork benötigen würden.
Ich habe auch keine Fakten zum Bitcoin Netzwerk betont, sondern meine Befürchtung. Im Software Space wurde schon zu viel gute Software schlecht, weil sich die Entwickler nicht bremsen konnten. Wie ist das bei Bitcoin zu vermeiden? Insbesondere, wenn mal ein Hard Fork nötig werden sollte?
Wenn wir heute schon wüssten, welche Probleme wir erst in Zukunft erfahren, gäbe es auch bereits Lösungen. Meine Frage zielt bewusst auf das Phänomen der „Weiterentwicklung“ alias Verschlimmbesserung ab.
Das freut mich für Dich. Es schläft sich besser Aber im ernst, könnte ich Bitcoins konkreten Probleme in der Zukunft schon heute benennen, könnte ich mein Geld auch mit Kursspekulation verdienen Das kann ich nicht. Was ich kann, ist, das bekannte Phänomen der Verschlimmbesserung zur Diskussion zu stellen.
Mir ist dieses Thema in letzter Zeit ebenfalls durch den Kopf gegangen. Die Aussage „Meine Node - Meine Regeln“ ist in bestimmten Fällen nicht haltbar.
Annahme:
CTV wird fester Bestandteil von Bitcoin Core (keine Option, wie damals bei mempoolfullrbf).
UTC Timestamp „Bug“ steht 2038 an
Damit ist die Entscheidung eines Users, CTV nicht zu verwenden an die zukünftige Bug-Freiheit von Bitcoin Core gebunden. Externe Ereignisse, wie Bugfixes, Soft- / Hardforks zwingen Nodebetreiber ihre Altversion zu verlassen und auf neuere Versionen zu aktualisieren, welche die eigentlich ungewollten Features beinhalten.
Oder anderes Beispiel: Feature A (v25) → Feature B (v26) → Feature C (v27)
Software wird (normalerweise) linear gebaut, d.h. in zeitlicher Reihenfolge werden Codestücke implementiert und zu bestimmten Meilensteinen als Release (Binaries) verpackt. Wir nehmen hier an, dass User keine Programmierkenntnisse haben und sich nicht aus einem Github Repo PRs selbst zusammenstellen und kompilieren können. Weiterhin nehmen wir an, dass Features A, B und C als feste Bestandteile in Bitcoin Core integriert werden. Nun möchte ich Features A und C unterstützen, Feature B jedoch nicht. Ich sehe hier keinen Ausweg für Nodebetreiber, ein „eigenes Regelset“ beizubehalten.
Daher halte ich die Aussage „Wenn ihr das nicht wollte, updatet nicht“ für nicht haltbar.
Du meinst das CTV UND der Timestamp Bug im gleichen Hard Fork eingeführt/behoben werden, richtig?
Ich gebe dir vollkommen recht das dies eine unerwünschte Situation wäre.
Ich denke für den Timestamp fix werden alle sein. Bei CTV siehts da schon anders aus. Gerade deswegen sollten diese 2 Sachen nicht teil des selben Forks sein.
Soweit hast du schon recht, aber in der Softwareentwicklung gibt es auch die Möglichkeit von „backports“.
Somit wäre es möglich auf dem Feature Stand A wie in deinem Beispiel genannt, Feature C einzuführen.
Das wäre aber nicht von einzelnen machbar und wäre nur durch einen Fork des originalen Bitcoin Core Repo möglich. Falls sich genug Leute finden lassen, die genau so denken, wird es eben ein neues Bitcoin Core Repo mit Feature A und C aber ohne B geben.
Und dieses neue Bitcoin Core Repo könnte man dann auf seiner eigenen Node installieren.
Natürlich alles sehr theoretisch, aber so sehe ich das.
In folgendem Tweet behauptet jemand ein Bitcoin Exploit (oder ist es eine DDOS Attacke?) gefunden zu haben. Kann das jemand für mich technisch einordnen?
Kleiner Auszug: "The short version is that people who run bitcoin can be remotely charged thousands of dollars. That happens by upstream (upload) overage fees at worst and severe speed throttling at best. This is because bitcoin nodes can be forced to upload data in perpetuity in a way that isn’t rate limited whatsoever.
I suspect that the fundamental nature of the necessity for passing ranges of block data could present a fundamental botnet attack vector in most or all blockchains period. Here’s a demonstration. It’s called „bitdrain“ "
@DeTec Ich meine mich zu erinnern dass du technisch versiert bist
Wenn man einen Server eines Anbieters nutzt, um dort seinen Fullnode zu betreiben, muss man für den Datenverkehr des Servers bezahlen. Bei vielen Anbietern gibt es keine Flatrate oder nur ein begrenztes kostenloses Datenvolumen und man zahlt eine kleine Gebühr pro GB. Zum Beispiel 1 Cent pro GB.
Soweit ich es verstanden habe, besteht der Angriff darin, den Fullnode-Server eines Opfers dazu zu bringen, eine große Menge an Daten an den Server des Angreifers zu senden. Dadurch bekommt das Opfer eine sehe hohe Rechnung ausgestellt und/oder die Bandbreite des Servers wird stark gedrosselt.
Das kann unter Umständen bei einzelnen Fällen teuer und ärgerlich werden aber für die breite Masse sehe ich keine Gefahr. Bei vielen Cloud Anbietern kann man die maximalen Kosten für einen Server durch eine Einstellung begrenzen oder sich informieren lassen. Eventuell kann man den Server dann zwar nicht weiter betreiben aber das schützt aufjedenfall vor unerwartet hohen Kosten.
Es gibt auch andere technische Möglichkeiten um den Upload des Servers zu begrenzen. Beispielsweise könnte man es zeitlich und pro IP auf eine bestimmte Menge limitieren.
Ergänzend:
Innerhalb von Bitcoin Core gibt es zudem jetzt schon Möglichkeiten, dem entgegenzuwirken:
Zum einen gibt es eine ban list, auf die Peers gesetzt werden können, zum anderen gibt es eine Upload-Beschränkung, die ein maximales Traffic-Limit für 24h setzt.
So sehe ich es auch. Selbst wenn auf einmal alle bisherigen Bitcoin Core-Devs verrückt/irrational werden und ein Feature einbauen, was faktisch schädlich ist, wird es möglich sein, Programmierer zu finden, die bisher keine Core-Devs waren, aber dann zu welchen werden und diesen Fork entsprechend bauen. Der normale Endanwender ist dazu technisch nicht in der Lage, aber am Ende ist das auch kein Hexenwerk, sondern benötigt „nur“ bestimmtes Know-How. Und dieses Know-How haben ja nicht nur die aktuellen Bitcoin Core-Devs.
Aber im ernst, könnte ich Bitcoins konkreten Probleme in der Zukunft schon heute benennen, könnte ich mein Geld auch mit Kursspekulation verdienen 
Das kann ich nicht. Was ich kann, ist, das bekannte Phänomen der Verschlimmbesserung zur Diskussion zu stellen.