Bip110 bei bitcoin Knots ja oder nein?

Also rührt doch eher daher diese ganze Sache weil sich unser Staat so lustige Sachen ausdenkt :see_no_evil_monkey:

Machen wir doch schon. Es gibt schon illegale Bilder in der Blockchain und es gibt auch Viren und Dreck auf der Blockchain, die wir alle nachträglich nicht löschen können, auch mit Knots nicht, hat jemand schon “welche auf den Zopf bekommen”, dass wir alles das weiterleiten? Ich weiß von keinem Fall.

Hier werden ein paar Sachen vermischt.

Knots ist eine Bitcoin-Node Implementierung, so wie Bitcoin Core eine ist. Jede Person kann frei waehlen welche Node Implementierung sie betreibt. Die Konsensus-Regeln sind bei Core und bei Knots die gleichen. Knots bietet im Vergleich zu Core lediglich zusaetzliche Konfigurationsmoeglichkeiten.

Wo ist denn da bitte ein zentrales Komitee?

Die Fork von der vermutlilch die Rede war ist BIP-110. Die Software fuer BIP-110 ist ein modifiziertes Bitcoin Knots. Knots selbst enthaelt diese Soft Fork nicht. Jedem steht es frei diese Fork zu betreiben oder nicht. Es gibt kein zentrales Komitee. Entweder die Community entscheidet sich dafuer oder halt nicht.

Nein hier wird nix vermischt.

Du hast recht es gibt noch keine Fork, das habe ich auch nicht behauptet.

Aber wenn man zukünftigen Spam oder illegale Inhalte aus der Blockchain verbannen will, wie die Knots Befürworter ja wollen, braucht man dafür eine Fork.

Es war zumindest mal im Gespräch.

Und dieser “Leak” (fuer den es uebrigens keinen Beweis gibt) ist wiederum etwas ganz was anderes und hat weder mit Knots noch mit BIP-110 etwas zu tun. Es war meines Wissens unter Bitcoinern keine Hardfork im Gespraech.

vor allem liegen die Daten nicht offen rum sondern sind chifriert und in gepackter Form, wie alle Daten auf der Blockchain.

Ja, sofern blocksxor=1 in bitcoin.conf gesetzt ist. (Wurde in Bitcoin Core/Knots 28 eingefuehrt um zu verhindern dass Virenscanner Alarm schlagen.)

Um klarzustellen: Das BIP hat nichts mit Zensur zu tun. Es legt lediglich fest, wie viele zusätzliche Daten an eine Bitcoin-Transaktion angehängt werden können. Jeder kann weiterhin Transaktionen an jeden senden. Das eigentliche Argument für ein „offenes Netzwerk“ ist, dass Bitcoin auch als Träger für Texte, Informationen und zukünftige Technologien mit höherem Datenbedarf genutzt werden soll.

Das BIP ist die Antwort auf das Argument, dass Filter in Nodes wirkungslos sind, weil man Daten direkt an Miner senden kann. Deshalb wird die Begrenzung auf Konsens-Ebene angesetzt. Ziel ist es, das UTXO-Set, den Speicherbedarf und die Rechenlast für Nodes möglichst klein zu halten, um die Dezentralisierung langfristig zu schützen. Das folgt demselben Grundgedanken wie in den Blocksize Wars. Gleichzeitig wird ein klares Signal gesetzt, dass Bitcoin primär ein Zahlungsnetzwerk ist und kein allgemeines Datennetz.

Wenn eine Node neu startet, sucht sie automatisch nach neuen Peers. Das gilt für Updates und normale Restarts. Deshalb tauchen bei dir warscheindlich häufiger BIP- und v30-Nodes als Peers auf, weil frisch aktualisierte Nodes neue Verbindungen aufbauen und dich auswählen. Nodes, die schon länger laufen, haben meist genügend Peers und suchen nicht aktiv nach neuen. Hat meines Wissens nichts mit dem BIP zu tun

Ach das finde ich interessant :innocent:

Danke dir, ich war nur am Anfang geschockt :innocent:

Und als letztes noch einer aus meiner Sicht wichtigsten Punkte, dass vor der Öffnung von OP_RETURN Daten zwar an Miner geschickt werden konnten, Miner aber klar identifizierbare Dienstleister waren und damit rechtlich wie auch innerhalb der Bitcoin-Community Verantwortung trugen, wenn sie unzulässige, oder dem Netzwerk schädliche Inhalte im Hinblick auf die langfristige Dezentralität in Blöcke aufnahmen. Das Risiko von rechtlichen Konsequenzen, Imageschäden und möglichem Hashrate-Verlust wirkte als natürliche Bremse.

Mit einem vollständig offenen OP_RETURN trägt nun jede Node zur Weiterverbreitung solcher Transaktionen im Netzwerk bei, wodurch sich die Verantwortung vom einzelnen Akteur auf das gesamte Netzwerk verlagert. Was früher einer klaren, verantwortlichen Identität zugeschrieben werden konnte, wird zu einer kollektiven Netzwerksache. Das geplante BIP ist aus meiner Sicht die Antwort darauf, dass viele kein offenes OP_RETURN wollten und die Anreize im Netzwerk neu ausgerichtet werden müssen. Es geht nicht darum, mit einem Fork ohne Zustimmung eine Änderung „aus dem Nichts“ durchzusetzen, sondern darum, dass die Öffnung von OP_RETURN den Fork überhaupt erst notwendig gemacht hat.

Die Aussage stimmt so leider nicht. BIP110 limitiert nicht nur den Datenbereich.
Es limitiert auch:

  • bestimmte Witness Versionen
  • Länge von scriptPubKeys
  • Taproot Annexe, große Control Blocks und weitere Op-Codes (OP_IF/OP_NOTIF und OP_Success in Tapscripts)

Das betrifft v.a.

  • erweiterte BitVM Konstrukte
  • Wallets, die Miniscript (Tap-Zweige mit OP_IF) verwenden,
  • und andere Softforks: Da OP_Success und andere Witness-Versionen in dieser „temporären“ Zeitspanne nicht mehr zur Verfügung stehen, kann kein anderer Softfork durchgeführt werden

Es können zwar weiterhin Daten-Chunks in Fake-Pubkeys mit kleinerer Schlüssellänge integriert werden; die Autoren behaupten jedoch, dass hier der Gebührenmarkt das Gefüge regeln wird.

Quelle: https://bip110.org

Ob Miner diesen BIP gut finden, werden wir sehen: https://filters.watch

Denn, wenn Miner BIP110 nicht folgen, Nodes aber auf BIP110 laufen. Entsteht ein persistenter Chain-Split:

  • Alte Nodes kümmern sich nicht um die BIP110-Regeln und akzeptieren wie gehabt alle Blöcke der Miner.
  • BIP-110 Nodes verwerfen Blöcke, deren Transaktionen gegen die neuen Regeln verstoßen und folgen damit der kürzeren Chain → ein persistenter Soft Fork (Chain Split)

Das ergibt theoretische Angriffsmuster z.B. im Lightning Netzwerk für zeitkritische Transaktionen, wenn zwei Netzwerke unterschiedliche Blockschritte aufweisen, zeitlich verzerrt sind.

  • ReOrg auf Justice-Transaktionen
  • Kanal-Confirmation
  • CLTVs unterschiedlich

Also nicht leichtfertig auf den Zug aufspringen. Vor allem, wenn ihr eine Lightning Node betreibt.

Nach meinem Wissensstand:

-BitVM ist noch nicht im Mainnet.

-Wallets sind praktisch nicht betroffen, ausser in extremen Sonderfällen mit sehr komplexen Konstruktionen.

-Annex wird aktuell nicht genutzt.

-große Control Blocks kenne ich nicht

Deswegen habe ich zukünftige Technologien hingeschrieben

Meiner Meinung nach sollte Bitcoin Layer 1 so schmal, stabil und dezentral wie möglich bleiben. Solche „Experimente“ gehören auf Layer 2. Sie machen Nutzer abhängig von Entwicklern, erhöhen das Risiko für das Protokoll und werden in der Praxis kaum verwendet.

@utxo Was denkst du zu dem Argument?

Ich verstehe nicht, warum dieses Thema im Forum kaum ernsthaft diskutiert wird. So eindeutig, wie es hier teilweise dargestellt wird, ist die Situation aus meiner Sicht nicht. Gerade deshalb würde ich mir wünschen, dass sich auch der Blocktrainer noch einmal fundiert und kritisch damit auseinandersetzt. Das verlinkte Video fasst die aktuelle Lage meiner Meinung nach gut zusammen.

Mich interessiert konkret: Was an den darin geäusserten Argumenten ist sachlich falsch? Und warum sollten wir innerhalb von Bitcoin nichts gegen Core v30 unternehmen, wenn die langfristigen Folgen für Dezentralität (schnelleres wachsen UTXO, Blockchaingrösse) und Anreizstrukturen (Miner lieber Blöcke mit OP_Return füllen als Blockchain klein zu halten) zumindest diskutabel sind?

Bin ich bei dir und das erledigt für mich der Konsensus.

Welche Lage soll das sein? Was willst du hier diskutieren?

  • die Richtigkeit der Epstein Files bzw. der Publikationen daraus auf X?
  • die Kontaktschuld von Back mit Epstein?
  • dass Isreal die Kontrolle über Bitcoin übernahm durch Funding einer Dach-Organisation?
  • dass es viele Commits seit der Epstein Email gab und Epstein damit als „CEO of Bitcoin“ unter der Führung des Mossads galt?
  • dass es Backdoors geben würde?

:exploding_head: Da bin ich raus. Ich bleibe bei dem, was ich an Code sehen und reproduzierbar auf meinem System builden kann.

Ja, mach doch. Es gibt Settings dafür, die Policy nach Belieben zu ändern oder „Run Knots“ oder „Run Knots 110“. Dein Node, deine Regeln (Policy). Dennoch bleibt übergreifend der Konsensus.

hier ist eine gute kurze Beschreibung zu BIP110 und was es eig. macht
ab Minute 11:00 ist es dann interessant zu hören was es eig. macht
und ich denke das du dafür wärst

Wenn wir schon bei Videos sind, habe ich auch eines:

Lustigerweise auch ab Minute 11:00, nur von jemanden der nicht nur für ein Thema bekannt ist, seriös aussieht und selbst denken kann anstatt irgendwas abzulesen.

Sorry aber da hab ich jetzt jetzt irgendwie 0 verstanden. Also ich bin da nicht so Knie tief im Thema aber das war er irgendwie erzählt hat war zwar viel aber am Ende irgendwie garnichts außer das Core User die besseren sind :man_shrugging: aber warum? hab ich jetzt nichts verstanden und was dieser bip macht und warum das schlecht ist auch nicht wirklich. Ist schon so ein bisschen wie mit einem Politiker zu reden​:see_no_evil_monkey: