Die Frage ist ja nicht:
Ist das gut oder schlecht?
Sondern kann man das überhaupz verhindern ohne dem Netzwerk zu schaden?
Ein bereits konkreter Anwendungsfall ist CITREA, andere stehen aber auch schon in den Startlöchern. Der Bitcoin Speicherplatz mit seiner gesicherten Qualität wird mit dieser massiven Erhöhung im Prinzip auf dem Markt für fremde Anwendungen absolut unter Preis verschleudert. Der Speicherplatz-Verbrauch belastet die Knoten-Betreiber und fördert damit eine Verringerung der Anzahl der Knoten, sprich eine Zentralisierung des Bitcoin. Außerdem werden die Transaktionskosten erhöht was ebenfalls schädlich ist.
das Gesetz ?
Ich nehme mal am das du https://citrea.xyz/
meinst?
Das ist ein Bitcoin Rollup und für die Skalierung gedacht. Gerade diese Projekte sind der Grund warum wir OP Return NICHT klein halten wollen.
Damit zeigst du wieder das die meisten keine Ahnung haben wodrum es geht.
Die Blockgröße wird NICHT erhöht.
Es werden nur Policy Regeln, (KEINE Konsensus Regeln) in den Clients geändert, bezüglich was in Transaktionen rein darf.
1 „Gefällt mir“
Ich habe auf der Web-Seite nicht nachgesehen, aber mit Citrea, als ein erstes Beispiel für Shipcoin-Applikationen von denen weitere grenzenlos aufgesetzt werden könnten, trennen sich hier unsere Auffassungen fundamental, was zum System Bitcoin gehört (ggf. noch gehören sollte) und was NICHT. Bitcoin basiert auf der Dezentralität und Vielzahl der Knoten, und diese wird durch eine Verschwendung des von den Knoten-Betreibern kostenlos bereitgestellten Speicherplatzes untergraben.
1 „Gefällt mir“
Weißt du was Skalierung im Kontext von Bitcoin bedeutet?
Weißt du was ein Rollup ist?
Der Speicherplatz ist nicht kostenlos, wie kommst du darauf?
Für die Anwendungen, die auf Bitcoin bauen, wird dieser Speicherplatz völlig unter Wert vergeben, und dabei werden die BTC-Transaktionen verteuert bzw. verknappt. Die angebotenen Anwendungen werden überhand nehmen und massiv Speicherplatz beanspruchen. Im übrigen, es werden bis zu 10 Op-return pro Transaktion erlaubt, also insgesamt bis zu 1MB pro Tx, aber mit oder ohne dies, bei der vorgegebenen Öffnung unseres Speicherplatzes wird demnächst die Blockgröße in Angriff genommen werden, das ist absehbar.
Hast du Referenz Preise um diese Aussage zu untermauern?
Woran bemisst du was unter Wert ist?
Der Sinn eines Rolluos ist es mehr Transaktionen im gleichem Speicherolatz unterzubringen.
@Bitcoin_Maximalist Hilf mir doch bitte weiter:
a) Wieso braucht es deiner Meinung nach mehr Transaktionen im Mainlayer?
b) Wie so nicht in Second und Third-Layer weiter skalieren?
c) Was ist so wichtig an Citrea?
d) Wie stehst du zu den Risiken, die nicht Transaktionsbezogene Daten, insb. illegale Inhalte, mit sich bringt?
1 „Gefällt mir“
Danke für deine atrukturierte Nachfrage
Rollups sind ein 2ter Layer der dafür sorgt das man weniger Transaktionen im Main Layer braucht.
Um Gültigkeit zu haben muss es aber immer eine Verbindung zwischen den verschiedenen Layern geben.
Lightning braucht ja auch Settlement im Main Mayer, genauso brauchen Rollups ein Settlement im Main Layer.
Hast du Präzidensfälle die belegen das es bei anderen Blockchains ohne OP Return Limit rechtliche Konsequenzen für die Node Betreiber gab?
Es gibt keinen “Dashjr-Coin“.
Das BIP ist nicht mal von Luke Dashjr, sondern von Dathon Ohm.
Es ist Vorschlag für einen temporären Soft Fork, so wie es 2013 bereits einen gab: BIP 0050 - Bitcoin Wiki
Done: Release a version 0.8.1, forked directly from 0.8.0, that, for the next two months has the following new rules:
Reject blocks that would probably cause more than 10,000 locks to be taken.
Limit the maximum block-size created to 500,000 bytes
Release a patch for older versions that implements the same rules, but also increases the maximum number of locks to 537,000
Create a web page on bitcoin.org that will urge users to upgrade to 0.8.1, but will tell them how to set DB_CONFIG to 537,000 locks if they absolutely cannot.
Over the next 2 months, send a series of alerts to users of older versions, pointing to the web page.
Richtig. Aber es gibt auch andere Möglichkeiten Daten in die Blockchain einzubetten: z.B. Inscriptions. Und diese sind in den letzten Jahren für das enorme Aufblähen des UTXO Set verantwortlich gewesen. Insbesondere die BRC-20 Tokens. Das vorgeschlagene BIP würde Inscriptions komplett unterbinden.
Das vorgeschlagene BIP würde Konsensus Regeln ändern bzw. einschränken.
Das war mehr lustig gemeint.
Nichtdestotrotz bleibe ich bei Core v30.0
Konsensus ändern….. ich glaube es hackt!
Werden wir früher oder später aber sowieso müssen. Es gibt Bugs im Bitcoin-Konsensus. Siehe BIP54: bips/bip-0054.md at master · bitcoin/bips · GitHub
Des weiteren gibt es noch das Problem, dass die 32-Bit im Jahr 2106 nicht mehr ausreichen um die Unix-Zeit darzustellen.
Genau 
DANN machen wir das. Nicht jetzt wegen anderem Kram.
1 „Gefällt mir“
Ja, das wird ja durch OP Return in den technisch praktischeren Bereich verschoben.
Ich möchte anmerken das auch wenn ich dem BIP nicht zustimme, finde ich es gut das es dieses gibt das es so eindeutig ist was nötig wäre wenn man das einschreiben beliebiger Daten verhindern möchte.
So wird die Debatte klarer.
Für OP Return spricht das starke Argument der Skalierung über Rollups und außerdem das wir Bitcoin eigentlich nicht zensieren wollen.
Das stärkste Argument dagegen sind illegale Inhalte, bis jetzt habe ich aber noch keine Juristischen Präzedenzfälle dazu gesehen die das unter mauern.
1 „Gefällt mir“
Das einzige mir bekannte Bitcoin-Rollup, das von OP_RETURN Nachrichten größer als 80 Bytes in Ausnahmefällen gebrauch machen würde, ist Citrea mit 144 Bytes. Sonst ist mir kein anderer Fall bekannt.
Man sollte aber auch bedenken das
Rollups eine sehr neue Technologie im Bitcoin Bereich sind (woanders schon länger in Gebrauch)
Aber BIP-444 fordert ja Begrenzungen die schon aktuell nicht mit allen Rollups kompatibel sind.
Und da man den Bitcoin Konsens nicht ständig ändern kann, würde ich nicht unter 200bytes gehen
Valider Punkt, ein Limit von ein paar hundert Bytes an OP_RETURN-Daten könnte Sinn machen. Allerdings haben wir aktuell ein Konsensus-Limit von völlig anderen Dimensionen: fast 1MB an OP_RETURN-Daten.
Und ein noch größeres Problem sind Inscriptions welche aktuell fast 4MB groß sein können und nur ein Viertel der Gebühr zahlen.
1 „Gefällt mir“