BIP-119: Die Entzauberung der Softfork
Gewölbe (Vault) in
der Basilique Notre-Dame. Bild von Patrick via flickr.com. Lizenz: Creative Commons
Die Bitcoin-Szene debattiert gerade erhitzt über BIP-119, das eine neue Funktion in das Bitcoin-Protokoll einführen soll. In der Diskussion sind Politik und Technologie eng verflochten. Wir erklären, worum es geht – und warum es so wichtig ist.
Eine der hervorragendsten Eigenschaften von Bitcoinern ist, dass sie extrem emotional auf technologische Details reagieren können. Dinge, die für den Rest der Welt böhmische Weiler sind, können bei Bitcoinern Stürme der Begeisterung oder Empörung hervorrufen. Nirgendwo sonst wird Technologie so politisch.
Das neueste Schlachtfeld ist BIP-119, das OP_CHECKTEMPLATEVERIFY (CTV) einführt. Seit etwa zwei Wochen erhitzt es die Szene.
Vermutlich versteht ihr nicht, was diese Wörter bedeuten. Und vermutlich versteht ihr noch weniger, warum es so ein Geschieß darum gibt. Daher arbeiten wir uns Stück für Stück durch das Drama durch.
BIP-119
Zunächst einmal ist BIP-119 ein “Bitcoin Improvement Proposal”. Wer Bitcoin verändern will, muss seinen Vorschlag in einem bestimmten Format einreichen, so dass es von den Core-Entwicklern diskutiert werden kann. Nur was ein BIP ist, hat eine Chance, in Bitcoin Wirklichkeit zu werden.
Mit BIP-119 schlägt der Entwickler Jeremy Rubin vor, einen neuen Op_Code einzuführen, nämlich OP_CHECKTEMPLATEVERIFY (CTV). Das BIP wurde Mitte 2020 im offiziellen Repositorium von Bitcoin Core veröffentlicht.
Ein Op_Code meint eine Art Befehl der Skriptsprache von Bitcoin. In jeder Transaktion stecken diverse Op_Codes. Diese definieren Bedingungen, wie die überwiesenen Coins weiter ausgegeben werden können. Im einfachsten Fall bestimmen die OP_Codes, dass man die Folgetransaktion mit einem bestimmten Schlüssel signieren muss. Das ist die Standardtransaktion.
Jeremy Rubin möchte mit BIP-119 also einen neuen OP_Code hinzufügen. Er möchte der Skriptsprache von Bitcoin erlauben, eine Operation auszuführen, die vorher nicht möglich war: OP_CHECKTEMPLATEVERIFY (CTV).
Aber was ermöglicht CTV? Die Antwort lautet „Covenants“.
Covenants
Covenants ist ein Fachbegriff aus dem britischen Rechtswesen. Er bezeichnet laut Wikipedia “ein einseitig bindendes Versprechen, das man in der besonderen Privatbeurkundungsform des deed abgibt.”
Für Bitcoin bedeutet dies: Man kann mit CTV, erklärt das BIP, “Transaktionen bilden, die künftig eine beschränkte Nutzung haben”. Man kann nicht nur definieren, mit welchem Schlüssel die Folgetransaktion zu signieren ist, sondern auch, welche Eigenschaften sie haben soll. Man bestimmt also nicht nur, WER das Geld ausgeben kann – sondern auch WIE.
Auf rein technischer Ebene macht der Op_Code das Folgende: Er lädt ein Objekt von 32 Byte und prüft, ob der Hash der Transaktion diesem Objekt entspricht. Nur wenn er dies tut, ist die Transaktion valide.
CTV erlaubt es, sehr präzise Bedingungen für Folgetransaktionen zu formulieren. Dies kann fast jedes Element einer Transaktion betreffen: Inputs und Outputs, Locktime, die Skripte, den Wert und vieles mehr.
Covenant sind, erklärt Jeremy Rubin im BIP, “Beschränkungen, wie ein Coin außer durch den Besitz des Schlüssels ausgegeben werden kann”. Aber wofür sind sie gut?
Tresorräume, Staukontrollen, nicht-interaktive Channels
Jeremy Rubin erklärt an ein paar Beispielen, was man mit Covenants machen kann:
- Man kann einen Vault bilden (wörtlich: einen Tresorraum): Eine Transaktion ist nur gültig, wenn der Empfänger eine bestimmte Adresse ist oder einem Set an Adressen angehört.
- Man kann “nicht-interaktive Payment Channels” konstruieren. Bisher müssen im Lightning-Netzwerk beide Seiten agieren, damit eine Transaktion durch einen Payment Channel fließt. Mit Covenants ist es möglich, Payment Channels zu bilden, bei der nur eine Seite aktiv sein muss, so dass die andere sogar offline sein kann. Wie genau dies funktioniert, ist komplex, aber wenn es funktioniert, wäre es ein Knüller.
- Eine Börse kann eine „Staukontrolle“ bilden, wie Rubin es nennt: Sie sendet eine Transaktion, die viele Transaktionen bündelt, wartet aber, bis die Gebühren gesunken sind, um sie dann mit einer anderen, kleineren Transaktion zu triggern.
- Man könnte Mining-Pools bilden, bei denen die Auszahlung der Erlöse nicht vom Betreiber abhängt: Pools ohne zentrale dritte Partei, der man vertrauen muss.
- Etwas esoterischer ist der Vorschlag, Wetten auf Softforks abzugeben, oder auf sicherere Weise größere Hashed Time Locked Contracts (HTLCS) zu schaffen (HTLCS sind ein essentieller Bestandteil von Lightning).
Braucht man das wirklich?
Die Offline-Transaktionen für Lightning scheinen ein gewaltiger Gewinn zu sein. Sie wären ein Gamechanger. Ich würde sagen, sie allein reichen aus, um BIP-119 zu wollen.
Bei allen anderen der von Rubin skizzierten Anwendungen ist aber fraglich, ob man sie wirklich braucht.
Die Vaults klingen auf den ersten Blick gut. Aber sind sie wirklich etwas anderes als ein zeitversetztes Multisig? Haben sie wirklich Vorteile gegenüber dem, was bereits möglich ist?
Und brauchen Börsen die von Jeremy skizzierte Staukontrolle? Können sie nicht einfach warten, bis die Gebühren niedrig sind, um eine Transaktion zu bilden?
Mit P2Pool und Braiins von Slush haben wir bereits Modelle von etwas dezentraleren Mining-Pools. Bringt CTV hier wirklich einen nennenswerten Vorteil? Und ist die Veruntreuung von Block-Erträgen durch Pools überhaupt ein Problem?
Und so weiter. Braucht es CTV also wirklich? Vor allem, nachdem Bitcoin erst Taproot erhalten hat, das noch längst nicht in den Wallets angekommen und, wie das brillante Taro zeigt, auch noch bei weitem nicht ausgeschöpft ist?
Und überhaupt: Warum verschweigt Jeremy Rubin die offensichtliche und naheliegendste Anwendung – zweckgebundene Transaktionen? Also Whitelists? Liegt es daran, dass CTV ein mächtiges Instrument ist, um Kontrolle auszuüben – und dass genau dies viele eher erschreckt als begeistert?
Rekursive Blacklists
Der Diskurs zu CTV, der in den letzten Wochen ausgebrochen ist, teilt sich auf eine merkwürdige Weise: Auf der einen Seite diskutieren technisch kompetente Entwickler die Politik, und auf der anderen Seite diskutieren politisch begabte Influencer die Technologie.
Die naheliegendste und vielleicht stärkste Kritik äußert die Mutter aller Bitcoin-Influencer, Andreas Antonopolous. Bei ihm gewinnt sie jene Heftigkeit, mit der nur Bitcoiner auf technologische Details reagieren können.
Andreas befürchtet, dass Covenants Whitelists einführen. Die von Rubin vorgeschlagenen Vaults machen das ja bereits, und von dort aus ist es nur noch ein Sprung dahin, dass Regierungen Banken und Börsen verpflichten, nur noch Überweisungen zu tätigen, die an Adressen auf einer Whitelist gehen.
Schlimmer noch ist, dass auch rekursive Whitelists möglich werden: Eine Folgetransaktion ist nur gültig, wenn sie an eine Adresse auf der Whitelist geht UND wenn sie ebenfalls eine Whitelist setzt. Einmal überwiesen könnten Bitcoins niemals aus diesem „Walled Garden“, diesem ummauerten Garten, entkommen. CTV drohe daher, sagt Andreas dramatisierend, Bitcoin zu töten.
Update-Anmerkung: Offenbar sind rekursive Whitelists nicht möglich. Ob das nun daran liegt, dass sie es niemals waren, oder ob es nach Kritik geändert wurde, weiß ich gerade noch nicht.
Der Blocktrainer dreht diese Kritik noch etwas weiter: Auch er fürchtet, dass BIP-119 Bitcoin zerstören könnte. Dabei tauscht er Whitelists durch Blacklists aus.
Der Unterschied zwischen schwarz und weiß ist fundamental. Eine Whitelist enthält Adressen, an die man senden darf, ein Blacklist Adressen, an die man nicht senden darf. Bei einer Blacklist ist alles erlaubt, was nicht verboten ist; bei einer Whitelist alles verboten, was nicht erlaubt wurde.
Vor allem aber: Soweit ich es sehe, ermöglicht CTV keine Blacklists, da es nur positive, aber keine negativen Bedingungen erlaubt. Das räumt der Blocktrainer in einem nachfolgenden Video auch ein.
„Wenn dich jemand dazu zwingen kann, eine andere Währung zu verwenden, bist du bereits verloren.”
Der Unterschied zwischen White- und Blacklists ist entscheidend. Eine Blacklist ist viel weniger schlimm – und darum viel schlimmer.
Eine Blacklist ist ertragbar und würde vermutlich von den Usern akzeptiert werden. Wie viele Leute sind wirklich davon betroffen, keine Bitcoins an eine Adresse senden zu können, die auf den Blacklists des US-Finanzministeriums stehen? Eine Minderheit. Und selbst wenn – die Betroffenen können einfach eine neue Adresse bilden, die nicht auf einer Blacklist steht.
Mit Blacklists könnten sich onchain-Beschränkungen Stück für Stück und mit dem Wohlwollen der Community in Bitcoin fressen. Es wäre so wie mit dem Frosch im Kochtopf, der langsam aufheizt. Darum wären sie schlimmer als Whitelists.
Whitelists hingegen sind unerträglich. Sie sind wie ein Topf, der sofort aufheizt, so dass derf Frosch heraushüpft. Ein Coin, der durch rekursive Covenants für immer eingeschränkt ist, wird zwingend weniger wert sein als andere Coins. Eine Börse, die ihn verkauft, ohne ihren Kunden zu informieren, macht sich im schlimmsten Fall strafbar und wird in jedem Fall das Vertrauen der Kunden verlieren.
In der Mailinglist bringt dies Darosier perfekt auf den Punkt: “Wie unterscheidet sich das davon, wenn man dich mit einem Altcoin bezahlt? Es kommt mir vor, als sei die Fähigkeit, zu sagen ‘Sorry, dein Geld ist mir hier nicht gut genug’ im Kern von Bitcoins Sicherheit […] Wenn dich jemand dazu zwingen kann, eine andere Währung zu verwenden, bist du bereits verloren.”
Überhaupt fragt man sich, wie das skalieren soll. Wenn man nur 10-20 mögliche Adressen in die Whitelist schreibt, ist der Coin vollkommen unbrauchbar; wenn man beispielsweise 1000 reinschreibt, bläht das die Transaktion um 32 Kilobyte auf, was eine ziemlich teure Übung wird und überhaupt nicht skaliert.
Ohnehin ermöglicht CTV hier nichts fundamental neues. Man könnte mit einfachen Multisig-Transaktionen ebenfalls „Walled Gardens“ einrichten, indem etwa die BaFin oder die FATF jede Transaktion mitsignieren muss. Das wäre in der Praxis ebenso effektiv wie eine Whitelist mit CTV, würde viel besser skalieren und wäre auch viel praktischer, da man die Black- oder Whitelists auch forlaufend aktualisieren kann.
Aus diesen Gründen spielen die rekursiven Whitelists in den Diskussionen der Entwickler so gut wie gar keine Rolle. Heftig ist die Diskussion dennoch.
“Ich verstehe nicht, warum du meinst, CTV sei ‘ bereit für den Einsatz’ in Bitcoin.“
Leicht toxisch wurde die Debatte bereits im Januar 2022. Jeremy Rubin hat zu dieser Zeit versucht, die Core-Entwickler zu überzeugen, die Aktivierung von CTV einzuleiten.
Mehrere prominente Entwickler verpassten ihm daraufhin eine Abfuhr. So schrieb etwa Blockstream-CEO Adam Back am 3. Januar 2022, es seien weitere Analysen des Protokolls und von “gut durchdachten Alternativen” notwendig.
Review of a specific proposal for a part of covenants (CTV) does not need crowd funding. What is needed is protocol analysis and well-thought out alternatives, like more work on TLUV and systematic thinking about the problem space. Cultivating that would be useful.
— Adam Back (@adam3us) January 3, 2022
Schärfer drückte sich Matt Corallo von ChainCodeLabs aus: “Ich verstehe nicht, warum du meinst, CTV sei ‘ bereit für den Einsatz’ in Bitcoin. Zu keinem Zeitpunkt in Bitcoins Geschichte war es ok, Dinge in den Konsens zu bringen […] ohne über Alternativen nachzudenken. Der Push für CTV fühlt sich … falsch an, auf jede erdenkliche Art. Anstatt kollaboratives Entwickeln fühlt es sich an wie ‘Ich habe das gebaut, lasst es uns tun’, während jedes Feedback ignoriert wird. Ehrlich gesagt sollte es allein deswegen beim Versuch eingehen …”
I don't understand at all why you think CTV is "ready to go" into Bitcoin, at no point in Bitcoin's history has it been okay to propose shipping things into consensus (which can then never ever ever be removed from the consensus rules) without considering alternatives.
— Matt Corallo (@TheBlueMatt) January 3, 2022
Dem stimmt Bob McElrath zu: “Ich will sehen, dass CTV die beste und richtige Lösung für ein Problem ist.”
This basically sums up my hesitance around CTV. It's a solution in search of a problem and one man's push to make his work relevant. I want to see that CTV is the best and right solution to a problem, not an arbitrary thingamabob that can be used in lots of different ways. https://t.co/XDOfkiDtji
— Bob McElrath (@BobMcElrath) January 3, 2022
Und auch der Entwickler Mark Erhardt (Murch) ist skeptisch: “Protokoll-Änderungen müssen sicher, nützlich, erwünscht und die beste Variante sein. Die Abwesenheit von Kritik als stille Unterstützung zu verkaufen ist irreführend. Ein Vorschlag muss Interesse hervorrufen, um Reviews zu bekommen. Dieser Vorschlag würde die Philosophie ändern, wie Transaktionen funktionieren, und ich sehe nicht, dass Experten dies unterstützen.”
Protocol changes need to be safe, useful, demanded, and the best choice. Casting absence of criticism as tacit support is misplaced. A proposal needs to garner interest to get review.
This proposal would change the philosophy of how txns work, but I see no support among experts.— Murch (@murchandamus) April 21, 2022
Ähnlich geht es in der Mailing-Liste weiter. Peter Todd nennt BIP-119 etwa eine „unreife Idee“ und Jeremys Implementierung „unzureichend.“ Er beharrt darauf, dass sie mögliche DoS-Angriffe ermögliche.
Man könnte noch lange weitermachen. Es hagelte Kritik und Ablehnung im Januar. Dabei fällt auch, dass es an keiner Stelle darum geht, ob Covenants an sich erwünscht sind oder nicht. Es scheint ein Konsens zu bestehen, dass ihr Nutzen den möglichen Schaden überwiegt.
Auch die inhaltlich-technische Kritik fällt spärlich aus. Es geht weniger um den Inhalt, sondern um die Form – darum, WIE man das Bitcoin-Protokoll verändert.
Jeremy Rubin versuchte in den folgenden Monaten, die anderen Entwickler zu überzeugen. Doch dies gelang ihm offenbar nicht. Und damit erreichte die Debatte die heiße, toxische Phase.
„Das ist, wie es sein muss.”
Auf seinem Blog kündigt Jeremy an, eine Version von Bitcoin Core zu veröffentlichen, die den neuen OP_Code sowie einen Aktivierungsmechanismus enthält.
Man sollte das Folgende wissen: Ein neuer Op_Code stellt eine Änderung des Protokolls dar. Dies ist ein nicht unerheblicher Eingriff, der bei Core gewöhnlich durch eine Softfork stattfindet, wie bei SegWit oder Taproot. Eine Softfork bedeutet, dass ALLE Miner den Code benutzen müssen, da Blöcke, die mit dem alten Code erzeugt werden, ungültig werden.
Um die Softfork zu aktivieren, nutzt Rubin den Speedy Trial Mechanismus. Dieser wurde bereits bei Taproot genutzt. Er funktioniert so: Wenn 90 Prozent der Miner über einen Zeitraum von etwa zwei Wochen (2016 Blöcke oder eine Difficulty-Epoche) Zustimmung signalisieren, wird das Upgrade aktiviert. Vergehen hingegen drei Monate, ohne dass diese Schwelle erreicht wird, gilt der Versuch als gescheitert.
Speedy Trial erlaube es, erklärt Rubin, rasch zu einer Entscheidung zu kommen. Und er will diese Entscheidung. Er halte sich schon lange mit CTV auf, und er habe auch andere Ziele und Pläne (mit Bitcoin). Das Upgrade ist programmiert, und er möchte dieses Kapitel abschließen, anstatt in endlosen Diskussionen stecken zu bleiben.
Rubin ist offenbar frustriert von den Core-Entwicklern: “Ich habe die Maintainer um klare Aussagen gebeten, welche Anforderungen sie an das CTV-Pull-Request stellen, aber ich wurde abgewiesen ohne klare Kriterien, doch mit der Erklärung, dass Diskussionen über Softforks nicht in der Verantwortung der Maintainer liegen.”
Er sei zuerst überrascht gewesen, habe dann aber begriffen: “Es ist nicht die Schuld der Maintainer, dass sie mir keine Führung geben können. Das ist, wie es sein muss.” Denn wenn die Core-Entwickler darüber entscheiden, wie man das Protokoll verändert, bringen sie sich selbst in eine gefährliche Lage. “Der einzige Weg, wie Bitcoin Core apolitisch bleiben kann, ist, indem Softforks unabhängig veröffentlicht und durch die weite Community akzeptiert werden.”
Klingt fair und überzeugend, oder? Doch die Core-Entwickler sehen das anders.
Es geht nicht um die Technik, sondern um die Politik
Matt Corallo findet sehr klare Worte in der Mailinglist: “CTV zu aktivieren oder einen Weg zu suchen, es in Bitcoin zu zwingen, ist in dieser Phase verletzend und kurzsichtig. Schlimmer noch, es setzt einen unglaublich ungünstigen Präzedenzfall darüber, wie wir über Änderungen von Bitcoin und dem Erhalt von Bitcoins Kultur des sicheren und sorgfältigen Designs denken.”
Und Adam Back tritt auf Twitter nach: “Es ist enttäuschend, zu sehen, wie jemand versucht, Reviews und andere rationale Argumente zu übergehen oder zu ignorieren.” Und so weiter. Das ganze heizte sich bis zu den oben genannten Videos auf, in denen Jeremy beschuldigt wird, mit BIP-119 Bitcoins zu zerstören.
Der Entwickler hat offenbar eine rote Linie überschritten. Dabei geht es aber, zumindest bei seinen Kollegen, nicht um das Ziel von BIP-119, und es geht auch nicht um technische Mängel.
Es geht vielmehr – und das ist natürlich frustrierend für Jeremy – um den Prozess. Nicht um Technik, sondern um Politik.
Die Entzauberung der Softfork
In gewisser Weise rächt sich nun, dass die Bitcoin-Community Softforks verherrlicht. Dies begann im Zuge der Blocksize-Kriege, als die Szene eine Hardfork zur Erhöhung der Blockgröße ablehnte.
Softforks wurden dabei als sanfte, harmlose Alternative zu Hardforks dargestellt. Dabei war schon lange klar, dass sie ein sehr gefährliches und auch undemokratisches Instrument sind.
Man muss den Unterschied zwischen Soft- und Hardforks kennen. Eine Hardfork ist ein „nicht abwärtskompatibles“ Upgrade. Jeder Knoten, der nicht mitzieht, verliert den Konsens. Er ist draußen. Um erfolgreich zu sein, benötigt eine Hardfork nicht nur die Unterstützung der Miner, sondern auch der Community und der Full Nodes. Das macht sie in gewisser Weise demokratisch.
Eine Softfork hingegen ist für die Full Nodes „abwärtskompatibel“. Lediglich die Miner müssen mitziehen. Die Full Nodes bekommen gar nichts davon mit, wenn sie das Upgrade nicht mitmachen. Sie bilden sich weiterhin ein, alle Transaktionen zu verstehen und zu validieren, obwohl sie das bei den Transaktionen, die durch die Softfork ermöglicht werden, nicht mehr tun.
Wenn Bitcoiner behaupten, ihr Full Node bewahre die Stabilität der Regeln, dann trifft dies nur auf Regeln zu, die per Hardfork geändert werden. Eine Softfork untergräbt diesen Mechanismus. Sie gaukelt dem Full Node vor, die Gültigkeit einer Transaktion zu verifizieren, während er den wesentlichen Teil in ihr gar nicht versteht. Das, worum es geht, schleicht sich durch den Radar des Ful Nodes. Eine Softfork entzieht dem Full Node das Mitspracherecht. Wenn man Bitcoin angreifen will, etwa durch die Einführung von Onchain-Whitelists, wäre eine Softfork eine sehr viel zielführendere Methode.
Jeremy Rubin hat damit die Diskussion ausgelöst, welche in der Bitcoin-Community schon lange fällig war. Sein Vorstoß hat die Softfork entzaubert, auch wenn dies erst noch in der breiten Szene ankommen muss.
Warum darf CTV nicht das, was Taproot durfte?
Man könnte die Ideologie, gegen die Jeremy rennt, auch so formulieren: Ein Upgrade mit weitreichenden Folgen – jede Protokolländerung – SOLL toxisch sein. Der Dissens SOLL der Standard sein, Konsens für Regeländerungen SOLL hart zu erringen sein.
Nicht Funktionsreichtum oder Flexibilität, sondern Stabilität ist das, worauf es bei Bitcoin ankommt. Das ist die Ideologie. Das Ideal ist das verknöcherte Protokoll, das niemals wieder geändert wird.
Aber warum entzündet sich diese Diskussion an BIP-119? Warum ging Taproot so gut durch, obwohl es ebenfalls eine Softfork ist, die ebenfalls mit Speedy Trial aktiviert wurde?
Die Antwort liegt erneut in der Form: Taproot wurde länger geplant und intensiver diskutiert, einschließlich des Verfahrens, die Softfork zu aktivieren. Taproot wurde zudem von weitbekannten Bitcoin-Veteranen – Gregory Maxwell und Pieter Wuille – erdacht und umgesetzt.
CTV hingegen ist von Jeremy Rubins, einem engagierten, aber viel weniger bekannten Entwickler. Er hat die Diskussion nicht ausgesessen, sondern abgeschnitten, indem er auf die Aktivierung drängt und nun sogar versucht, sie gegen den Konsens der Entwickler zu erzwingen. Das weckt Erinnerungen an Mike Hearn und BitcoinXT …
Die Art und Weise, wie CTV aktiviert wird, wirkt wie ein Angriff. Vielleicht nicht wie ein Angriff per se. Aber sie wirkt wie eine Methode, die man auch für einen Angriff missbrauchen kann. Daher ist Ablehnung, Dissens und Drama die einzige Option, so unangenehm dies für Jeremy und alle ist, die Covenants wollen.
Das Bitcoinblog wird von Bitcoin.de gesponsort, ist inhaltlich aber unabhängig und gibt die Meinung des Redakteurs Christoph Bergmann wieder
Christoph hat vor kurzem sein zweites Buch veröffentlicht: “Das Bitcoin-Kompendium: Netzwerk und Technologie”. Es ist eine überarbeitete Auslese seiner besten Artikel für dieses Blog. Ihr könnt das Kompendium direkt auf der Webseite Bitcoin-Buch.org bestellen – natürlich auch mit Bitcoin – oder auch per Amazon.
Tipps für Stories sind an christoph.bergmann@mailbox.org immer erwünscht. Für verschlüsselte Nachrichten nutzt bitte meinen PGP-Schlüssel — Auf Telegram! könnt ihr unsere News abonnieren.
https://old.reddit.com/r/Bitcoin/comments/uim560/bip_119/
—
Christoph, lies mal bitte die Antworten von nullc bip119 betreffend…ich glaube du hast vielleicht ein paar dinge nicht völlig richtig verstanden…
Die CTV Konditionen könnten sich natürlich auch nur bei einer ctv-softfork-kompatiblen wallet(geschweige denn Fullnode) auswirken.
– Mit der Wahl deiner FullNode (die natürlich auch gleichzeitig Wallet ist, wozu hat man denn sonst eine eigene Fullnode, wenn nicht um sicherzustellen daß man wirklich, der eigenen FullNode-Wahl entsprechend, “echte” Bitcoin erhält.)
bestimmst du auch den Ausgang, die Anwendbarkeit dieses CTV(BIP119)Softforks.
Allerdings ersteinmal nur für dich.
Wenn der Großteil des Netzwerks mitzieht, könnt ihr einen Consens erreichen.
Dies ist im wesentlichen der Prozess der Aktivierung eines (soft)forks auf der User-Seite.
–
Dann muss man noch schauen was die Miner machen….
—
Wow, danke für die Quelle von Greg Maxwell (nullc) auf Reddit.
“Du hälst es nicht richtig” wie beim Apple Antenna-Gate beim iPhone 2/3(?). Fungibilität ist also das Problem der falschen Nutzungsweise – dumm nur, dass über 90% es scheinbar falsch nutzen.
Miner sind zentraler Bestandteil des Bitcoins. Ein non-mining Node wurde im Whitepaper nicht berücksichtigt und ist eigentlich auch unnütz. Ein Netzwerk, das auf den Konsens der Miner setzt, muss auch bei eventuellen Änderungen des Protokolls auf diese setzen, es gibt sonst keinen anderen Konsens.
@Hase: Genau das hat Christoph doch geschrieben. Er hat aber auch darauf hingewiesen, dass es für die Aktivierung der Softfork mittels speedy trial ohne Bedeutung ist, ob “deine” full node den fork unterstützt. Sie wird gar nicht gefragt. Und wenn du deinen Node nicht auf die Regeln der Softfork updatest, wird dieser trotzdem an der Validierung teilnehmen.
@sebastian: Nicht-Miner Fullnodes validieren keine Transaktionen, sie validieren in ihrer Gesammtheit(mehr als 51%, weniger als 51%) Bitcoin Blöcke, welche alle ~10min von den Miner Fullnodes unter gewissen (Energie)Kosten gebildet werden und für die sie vom GesamtNetzwerk bezahlt werden FALLS die überwiegende Mehrheit aller (nichtMiner)FullNodes diese BitcoinBlöcke als valide akzeptiert.
-genau das ist ja das Lösung des vertrauens problems bei Bitcoin, wenn die RechnungsStelle(FullNodeMiner) anfängt zu ihrem Vorteil z.B. einfach mehr geld(Bitcoins) zu drucken( bei der Abrechnung zu bescheissen) können die nichtMiner Fullnodes diese falsche Abrechnung(neue BitcoinBlöcke) einfach in ihrer Mehrheit ablehnen, die blöcke als nicht valide verwerfen und die Miner haben eine menge Geld und Energie für nichts ausgegeben!
…nach dem selben Prinzip können die nichtMinerFullnodes sogar Änderungen im BitcoinProtokol welche die Miner eigenmächtig eingeführt haben(z.B.CTV-BIP119 via speedy trial) wieder rückgängig machen, indem sie mit einem User Rejected Soft Fork(URSF) Blöcke welche Transaktionen mit den eigenmächtigen Änderungen enthalten zurückweisen(Miner erhält keine Bezahlung dafür).
–
Don`t Trust, verify.
…auch bei dir selbst, wenn du sicher glaubst du hättest etwas schon ganz verstanden.
LG, Hase.
Tut mir Leid Ihnen das sagen zu müssen, aber auch Sie wurden Gehirngewaschen. Selbst Milliarden Nicht-Mining Raspi Nodes könnten nichts dagegen tun, wenn die Mehrheit der wenigen Miner neue Spielregeln einbringen. Einfach nur Blöcke ignorieren bringt garnichts. Man muss sie ignorieren und durch einen eigenen Block die valide chain unterstützen. Was wiederum heißt, dass nur Miner etwas zu sagen haben.
Das steht auch klar im Whitepaper:
“Nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash.”
Hase, bei allem Respekt, Du hast Bitcoin nicht verstanden. Ich werbe für Christophs neues Buch, das empfehlenswert ist, bis auf die Krux mit der Fungibilität, die ich nicht teile und dort als nicht abstreitbar dargestellt wird.
Ein Non-Mining Node ist dem Netzwerk komplett egal, ich kann akzeptieren oder ablehnen, was ich will, ich kann auch hunderte Nodes (mit entsprechendem Voting) auf einem einzigen VPS Server für 5$ aufsetzen, muss mir nur ein entsprechendes IPv4 Netz organisieren oder einzelne IPs hinzubuchen. Ich persönlich besitze z.B. ein /24 Netz mit 255 verfügbaren Adressen und könnte damit genauso viele Stimmen im Netzwerk ohne Zusatzkosten haben. Mit IPv6 wird das noch einfacher…
Die Macht haben 1. Miner und 2. Börsen. Auf letztere haben deren Nutzer Einfluss, aber es ist schlichtweg egal, ob man eine Node hat oder nicht.
@sebastian: Du siehst, die Meinungen gehen ausseinander.
Du wirst wohl nicht umhin kommen, eigene weitere Recherchen anzustellen.
–
Don`t trust.
Verify.
@Hase: Vielen Dank für den Hinweis! Tatsächlich bin ich davon ausgegangen, dass jeder Node (egal ob light oder full) Transaktionen propagiert. Jeder Full Node (egal ob Mining oder nicht) validiert Transaktionen (prüft also die Signatur und die ordnungsgemäße Referenzierung des Inputs). Mining full nodes konstruieren Blöcke, welche dann wieder von sämtlichen full nodes geprüft werden. Sollten non-mining full nodes nur Blöcke validieren und keine Transaktionen, muss ich das nochmals bei Mastering Bitcoin nachlesen. Es ändert aber dennoch nichts an Christophs Grundaussage: Es ist egal, ob non-Mining full nodes eine Softfork mitmachen oder nicht. Puh… Ich finde, kein ganz einfaches Thema.
@sebastian: Ja, schon ein komplexes thema.;)
Und ja, es stimmt das NichtMinig-Fullnodes ersteinmal nichts gegen eine softfork-Änderung machen können – ausser du updatest deine NonMining node zu einer URSF-Node.
(siehe oben:
“…nach dem selben Prinzip können die nichtMinerFullnodes sogar Änderungen im BitcoinProtokol welche die Miner eigenmächtig eingeführt haben(z.B.CTV-BIP119 via speedy trial) wieder rückgängig machen, indem sie mit einem User Rejected Soft Fork(URSF) Blöcke welche Transaktionen mit den eigenmächtigen Änderungen enthalten zurückweisen(Miner erhält keine Bezahlung dafür).”)
Dann würde deine Node auch neu geminte BitcoinBlöcke ablehnen, welche “nur” die softfork Änderungen enthalten.
Das Bitcoin Netzwerk würde splitten(sich aufteilen) auch forken genannt(von Gabel wie in Weg-Gabelung).
–
..wenn das Netzwek sich signifikant splittet, also eine nennenswerte Anzahl an z.B neuen URSF-noden ein neues parallel Netzwerk entstehen lässt, muss der Markt, die Börsen(und durch sie die User(Käufer/Verkäufer)) entscheiden welcher der beiden Coins(in den beiden Netzwerken) wertvoller ist.
Damit wird dann auch die Bezahlung, und damit die Profitabilität der jeweiligen Miner der beiden Netzwerke geregelt.
Miner welche keine BitcoinBlöcke mit Transaktionen welche die neuen Softfork Änderungen beinhalten bilden, können beide Netzwerke minen, andere nicht.(Stichwort Profitabilität als Motivation)
Ein gutes Beispiel dafür ist z.B das abforken, absplitten von bitcoin cash – jetzt nach einigen jahren hat der bitcoin cash coin sich auf einem weitaus geringeren Wert eingependelt als Bitcoin – die Profitabilität BitcoinCash-Miner zu sein ist geringer, die netzwerkProtokol Regeln von Bitcoin haben “gewonnen”, sind mehr wert.
–
..ist wirklich ein ein wenig komplexes Thema und das Schlimmste was du tun kannst ist annehmen du hättest jetzt alles verstanden und musst dich nicht mehr weiterbilden, am Ball bleiben..Bitcoin ist immer(mehr oder weniger) in Bewegung, wie alles was “lebendig” ist.
LG, hase.
@Hase:
Dann habe ich das mit der Verifikation der Transaktionen doch richtig verstanden. Christoph hat ja nun in einem ergänzenden Artikel auf die Möglichkeit der URSF hingewiesen. Ja… Man muss immer am Ball bleiben. Wundere mich immer, wie andere es schaffen, nicht nur Bitcoin im Auge zu behalten, sondern auch Ethereum, Solana, Polkadot, smart contracts und NFTs…
@Sebastian: Ja du hast recht, ich habe mich geirrt, sowohl Miner als auch nicht-Miner Fullnodes validieren Transaktionen.
–
Für mich persönlich sind alle anderen Coins, nfts nur Bitcoin Kopien im weiteren Sinne, die geschaffen wurden um die Entwickler zu bereichern und nicht um wie Bitcoin die Nutzer von einem sehr ungerechten Geldsystem zu befreien.
Einzig Monero finde ich daneben noch interessant..und Grin.
🙂
Danke für die differenzierte Meinung zu soft/hard Forks! However…
Ich glaube, Du verstehst das falsch. Es sind keine Offline-Transaktionen für Lightning, sondern nur Channel Openings, die man allemal meist nur beim Setup und ggf. Nachjustierung / Rebalancing benötigt. Einen Channel könnte ich also zu Dir eröffnen, ohne, dass Du online bist, etwa so wie eine normale OnChain Transaktion, der Du nicht zustimmen musst. Für tatsächliche Zahlungen im Channel an sich musst Du trotzdem online sein, oder korrigiere mich, wenn ich falsch liege. Aber immerhin bringt es den “Empfänger” des Channels die plausible Abstreitbarkeit zurück, die durch Lightning genommen wurde. Einer OnChain Transaktion musste ich nie zustimmen, für eine LN muss ich eine Invoice bauen, sogar mit dem Betrag (sonst unsicher mit aktuellen Implementierungen) und ich muss online sein, um sie zu empfangen. Nach meinem Verständnis verschwindet dieser Vorteil aber wie gesagt, sobald man im Channel Transaktionen durchführt, die wieder Interaktion erfordern, denn Bip 119 ändert afaik nichts am LN selbst.
Als Lobbyist für seinen Liquid Shitcoin (Stablecoin zu BTC) und Tether ist Adam Back für mich bei Bitcoin nicht mehr Ernst zu nehmen. Richard Heart ist glaubwürdiger und das will etwas bedeuten.
Du sprichst mir aus der Seele. Ich versuche seit Jahren, noch bevor ich auf Monero gestoßen bin, dagegen anzu”kämpfen”, dass man Änderungen am Protokoll irgendwie in eine Softfork “hackt” statt einen sauberen Strich zu ziehen und eine Hardfork (meist viel effizienter) zu machen. Geht nicht? Irgendwie klappt das bei Monero seit Jahren, aber da gibt es immer einen langen Konsens mit der Community von Usern, Minern und Entwicklern, nicht immer konfliktfrei, aber irgendwann hat man in den wöchentlichen oder bi-wöchentlichen Meetings an denen jeder teilnehmen kann, bisher immer einen Konsens gefunden. Im Gegensatz zu Bitcoin, wo ich mich mit meiner bescheidenen Meinung ein paar Mal im Github geäußert habe und regelrecht von Übermenschen wie Greg Maxwell niedergemacht wurde, bekommt jede Argumentation eine Stimme.
Dezentralisierung und so… Greg Maxwell fühlt sich als König, Adam Back auch. Pieter Wuille ist mir hingegen noch nie negativ aufgefallen, er scheint der Kluge im Hintergrund zu sein, der die Despoten machen lässt… Greg ist übrigens laut eigenen Aussagen schon lange kein Entwickler mehr, was sich im Github bestätigen ließe: https://github.com/bitcoin/bitcoin/graphs/contributors
> Ich glaube, Du verstehst das falsch. Es sind keine Offline-Transaktionen für Lightning, sondern nur Channel Openings, die man allemal meist nur beim Setup und ggf. Nachjustierung / Rebalancing benötigt. Einen Channel könnte ich also zu Dir eröffnen, ohne, dass Du online bist, etwa so wie eine normale OnChain Transaktion, der Du nicht zustimmen musst. Für tatsächliche Zahlungen im Channel an sich musst Du trotzdem online sein, oder korrigiere mich, wenn ich falsch liege. Aber immerhin bringt es den „Empfänger“ des Channels die plausible Abstreitbarkeit zurück, die durch Lightning genommen wurde. Einer OnChain Transaktion musste ich nie zustimmen, für eine LN muss ich eine Invoice bauen, sogar mit dem Betrag (sonst unsicher mit aktuellen Implementierungen) und ich muss online sein, um sie zu empfangen. Nach meinem Verständnis verschwindet dieser Vorteil aber wie gesagt, sobald man im Channel Transaktionen durchführt, die wieder Interaktion erfordern, denn Bip 119 ändert afaik nichts am LN selbst.
Das wäre ziemlich enttäuschend. Bist du dir da sicher?
Für mich liest sich das exakt so…
Quelle: https://en.bitcoin.it/wiki/BIP_0119#Non-Interactive_Channels
Bin aber selbst kein Experte und hab mich nicht in die technischen Details der BIP eingelesen oder irgendwelchen Code gegengecheckt. Ich kann mir aber nicht vorstellen, dass eine OnChain Änderung etwas an den Parametern des LN verändern könnte, welches ab Channel Öffnung komplett abseits des Grundprotokolls abläuft.
Btw. ist P2Pool bei Bitcoin überhaupt noch ein Thema und umgesetzt? Bei Monero gibt es seit ca. einem halben Jahr tatsächlich eine Umsetzung von P2Pool und jeder mit einer CPU kann daran teilnehmen und selbst kleinste Auszahlungen von ca. 0.0002 XMR (was aktuell ca. 4 Cent sind) werden damit realisiert, man sieht also schon nach wenigen Stunden den Effekt seines Minings, ohne irgendwelche Gebühren und Mittelsmänner, realisiert als merge-mined Sidechain von Monero, die P2Pool Miner fortführen. Leider sind bisher “nur” knapp 5% der Miner dabei, aber es werden mehr und die neue GUI wird es direkt implementiert haben… Allerdings ist es komplett dezentralisiert, jeder Miner stellt sich sein eigenen Tx-Set zusammen (was eine Node erfordert, zur Not auch remote) und es keine Zensurmöglichkeit gibt, die bei Monero ohnehin sehr eingeschränkt ist, da weder ein Miner noch sonst jemand Adressen der beteiligten Parteien einsehen kann. Aktuelle Blocks, Statistiken usw. kann man hier einsehen: https://p2pool.observer/
Ein Mining Reward sieht dann so aus: https://xmrchain.net/tx/fa25d597fc083edaf0cf986f26d9f79e8889146a7dffbf75e2505f13462d20f5
Reward Transaktionen sind die einzigen, bei denen man den Betrag einsehen kann, insbesondere damit man die zirkulierende Menge verifizieren kann.
Ich weiß, “unsere” Seiten sehen sehr rudimentär aus in Zeiten von Web2.0 oder dem heiß gehandelten Web3.0. Statt Affenbildern Fakten, damit muss man erstmal klarkommen.
Bei Bitcoin sehe ich aber auch keinen großen Bedarf an einer dezentralen Mining Lösung, denn ich kenne wirklich keinen Bitcoin Miner (mehr), der das irgendwie als Hobby betreibt. Entweder man setzt das professionell auf, investiert in x Geräte, organisiert sich die Location und vor allem billigen Strom und schließt sich einem Pool an oder macht einen eigenen, was ab einer gewissen Hashrate sinnvoll sein kann, obwohl ich weiß, dass die großen Player für großer Miner gerne Rabatte von 90% auf deren Pool Fees gewähren und ein eigener Pool teurer in der Wartung sein kann.
Ich hoffe, Antonopolous veröffentlich demnächst mal eine Klarstellung zu seinem Video, weil so richtig verstanden hat er 119 scheinbar nicht (CTV ist explizit so gebaut, dass es keine rekursiven Covenants erlaubt z.B.). Auch klingt es bei ihm so, als könnte man anderen encumbered coins einfach so “unterjubeln”, was ja auch völliger Quatsch ist (wenn der Empfänger die Adresse erstellt, legt er ja selber die Spending Conditions fest).