Inwieweit braucht man den die OP Retun Felder um Transaktionen zu verifizieren?
Um das nochmals zu verdeutlichen, eine Antwort der nunchuk Entwickler auf die Frage, ob nunchuk ihre Wallet anpassen könnte, um „BIP110-konform“ zu sein: https://xcancel.com/nunchuk_io/status/2022207185984561540
Miniscript ist eine high-level Programmiersprache auf Basis von Bitcoin Script. Die Entwickler verlassen sich dabei auf den Compiler, der die Übersetzung von high-level zu low-level vornimmt. BIP110 will sozusagen einen Operator einer low-level Programmiersprache verbieten. Miniscript gibt es laut nunchuk seit ca. 7 Jahren und ist seit 2023 spezifiziert.
Daher sind diese Aussagen zu einfach: „These wallets would need to update before activation to stop creating Tapleaves with OP_IF.“ und „Updating is straightforward: split OP_IF branches into separate tapleaves, which is already best practice for Taproot.“ Es müsste eine dedizierte Compiler-Analyse vorgenommen werden und vermutlich Änderungen am Compiler selbst, nicht an den Wallets/Applikationen, die ihn verwenden.
Und falls die Frage nach Anwendungsfällen wieder aufkommt: Miniscript 101: A Technical Guide
Mit dem BIP-110 wird solcher Spam (OP_return Datenblöcke größer 83 Byte) auf dem CONSENSUS Level verhindert, d.h. wenn nach diesem Soft-Fork solche großen Spam-Blöcke geminded werden, werden diese Blöcke nicht mehr angenommen.
2 „Gefällt mir“
Mit BIP-110 wird diese Möglichkeit zukünftig verhindert, da solche Blöcke nicht mehr in der Kette aufgenommen werden, selbst wenn diese gemined wurden. OP_return Spam wird auf max 83 Byte begrenzt.
2 „Gefällt mir“
fairerweise muss man dazu sagen, dass die Spammer ihre Daten auf mehrere Datenblöcke aufteilen werden, ihren Spam trotzdem in die Blockchain schreiben werden und dass der ganze Mist durch BIP-110 am Ende mehr Speicherplatz wegnimmt, mehr schädliche fake-pubkeys produziert und Spam nicht verhindern wird.
1 „Gefällt mir“
Peter Todd hat zum Beispiel aus Spass die BIP110-pdf in einen BIP110-konformen Block bekommen. Einfach nur um mal zu zeigen, dass es einfach nicht funktioniert und nicht funktionieren kann.
1 „Gefällt mir“
Bip-110 ist merged und wird entsprechend dem vorgesehenen Ablauf umgesetzt ( Issue #6: BIP-110 — The Countdown Has Started ).
In Kurzfassung:
- derzeit können die Knots-Knoten ihre Bereitschaft dazu optional anzeigen, derzeit zeigen dies bereits über 7% aller Knoten an,
- die Miner sind aufgefordert ihre Bereitschaft dazu anzuzeigen, ab 55% Minerbereitschaft wird der BIP aktiviert (MASF=Miner aktivated Soft Fork),
- Auch wenn nicht so viele Miner mitmachen, ab September (block 965,664) wird dieser Soft-Fork aktiviert (dies wäre dann ein UASF (User activated Soft Fork),
- Um die damit eingeführten Spam-Beschränkungen noch problemlos anpassen zu können wird diese gesamte Regelung auf 1 Jahr Laufzeit beschränkt, d.h. wenn weiter nichts mehr passieren sollte, wäre nach 52,416 Blocks die Beschränkung wieder aufgehoben.
Da mit dieser Regelung lediglich bestimmte Spam-Regeln umgesetzt werden, d.h. ggf. bestimmte Blöcke ausgeschlossen werden, könnte es ab der Aktivierung zeitweise zu Ketten-Spaltungen kommen, welche aber aller Voraussicht nach von der ‚sauberen‘ BIP-110 Kette wieder ‚eingefangen‘ wird. Denn bei nebeneinander existierenden Ketten wird die ‚Spam-Kette‘ nur solange neben der BIP-110 Kette weitergeführt, bis die BIP-110 Kette länger als die Spam-Kette sein wird. Zu diesem Zeitpunkt wird die Spam-befreite Kette auch von den heutigen Core-Knoten übernommen werden.
Damit dies nicht passiert, enthält die BIP-Regelung mehr als nur die Größenbeschränkung des OP_return.
Genau, der BIP-110 begrenzt die Größe bestimmter Datenfelder um den Spam soweit möglich unmöglich zu machen. Die Größe der Felder ist so gewählt, dass praktisch alle bisher bekannten Bitcoin Anwendungen erhalten bleiben. Im Bereich der Smart-Contracts gibt es einige Grenzfälle von Anwendungen, welche nicht erforderlich sind bzw. auch anders umgesetzt werden können.
1 „Gefällt mir“
Genau sagen kann ich es dir nicht.
Es ist jedenfalls eine falsche Behauptung von Seiten Core, oder sie trifft zumindest derzeit noch nicht zu.
Wahrscheinlich hängt es mit der Block-Hash-Verifikation, oder mit dem Indexing der Blockchain zusammen.
Ich finde dazu nichts. Aber egal, ihr wollt die Gegenargumente offenbar einfach nicht wahrnehmen.
Inwiefern soll das Aufteilen auf mehrere Transaktionen ein Argument dafür sein, dass eine Limitierung nicht funktionieren würde? Es ist offensichtlich ein Unterschied, ob man als Spammer eine Datei direkt und vollständig an eine einzelne Transaktion anhängt, oder ob man sie erst mühsam aus mehreren Transaktionen zusammensetzen muss und dafür alle Transaktions-IDs, die Reihenfolge und die Verknüpfung kennen muss um sie nachher anzusehen.
Nein, wir haben uns den Mund hunderte Zeilen schon x-mal fusselig geschrieben, dass all die gebrachten Gegenargumente halt Quatsch sind. Irgendwann hat man halt keine Lust mehr… auch hier im Forum ist das der 3. oder 4. Thread… die anderen hatten glaube ich 1000 Beiträge.
Nein wird es im Ergebnis nicht sein. Aber es wird z.B. durch Fake Pubkeys schädlicher für das Netzwerk. Bitcoin-Core ist gut wie es ist => running v30.2
1 „Gefällt mir“
Welchen Incentive haben Miner, BIP110 zu aktivieren (außer Ocean natürlich)? Eine Minderheits-Chain mit sehr wenig Rechenleistung ist kein Spaß.
Was soll in diesem einem Jahr passieren? Es gibt weiterhin Spam auf der Blockchain, wenn auch in andere Art und Weise. Also passiert weiterhin „etwas“. Und dann? Wie geht es danach weiter? Erneuter mehrjähriger Spam-Lockdown?
Wieso mühsam? Der Unterschied ist marginal. Ordinals und Stamps haben es gezeigt, dass ein zuvor definiertes Spamprotokoll funktioniert. Ob mein OP_Return größer ist oder mehere Outputs (fake pubkeys oder scripthashes) benötigt, ist für das Spam-Volk irrelevant.
2 „Gefällt mir“
du setzt sie ja nicht einzeln zusammen. das macht ein Programm. Wenn du ne website aufrufst, setzt du die website auch nicht mühselig zusammen, indem du einzeln jeden link, jedes bild, css- und html-Bausteine etc. einzeln zusammensetzt, bis du die website lesen kannst. Für jedes Problem wird eine Lösung geschaffen.
ganz genau.
1 „Gefällt mir“
Ich gab die aktuellen Aussagen der BIP-110 Clique wieder, zu deren Zustimmung ich neige.
Selbst bei Nicht-Erreichen der 55% der Miner wird angenommen, dass spätestens mit Beginn des UASF sich zumindest einige der größeren amerikanischen Miner diesem BIP anschließen, da sie nicht ein Miner sein möchten, welcher die durch die OP-return Freigabe ausgelöste Spam-Flut unterstützt.
Ich erwarte handfeste Diskussionen über die spezifizierten Spam-Beschränkungen, sowohl ob und inwieweit diese zu scharf sind als auch wo diese weiter verschärft werden sollten, z.B. sofern die von den Core-Leuten befürchteten neuen Spam-Arten auftauchen. Nach meiner Erwartung wird das Thema also erst im nächsten Jahr richtig heiß in Bezug auf eine längerfristige Lösung.
ich kann nicht mehr 
1 „Gefällt mir“
1 „Gefällt mir“
Zwei Dumme, ein Gedanke!
Da helfen auch keine Pillen
1 „Gefällt mir“
dann arbeite dich mal durch die Threads, die bereits seit Monaten hier im Forum existieren. einfach mal die Suchfunktion nutzen. wurde alles schon zig mal durchgekaut.
1 „Gefällt mir“