Was sind die Auswirkungen von BIP 12 gegenüber BIP 16 und OP_CODEHASHCHECK?

Es gibt eine Diskussion über zwei verschiedene Bitcoin-Verbesserungsvorschläge – BIP 12 und BIP 16, und wahrscheinlich wird nur einer von ihnen in Bitcoin 0.6 enthalten sein (die Miner werden durch eine Mehrheitsentscheidung der Mining-Macht entscheiden, welcher). LukeJr schlug eine Alternative zu BIP 16 namens OP_CODEHASHCHECK vor.

Kann jemand die Kernunterschiede zwischen den drei Vorschlägen und ihre jeweiligen Vor- und Nachteile zusammenfassen?

Warum das "TL;DR" im Titel der Frage?
@DH - Nun, ich habe es ursprünglich dort abgelegt, weil die Antworten, die ich suche, möglicherweise in der langen Diskussion enthalten sind, auf die ich verlinkt habe ... aber Sie haben Recht, die Frage ist ohne dieses Präfix legitim.

Antworten (3)

BIP 12 erstellt einen neuen Skript-Opcode, der es Skripten ermöglicht, mehr in einer Zeichenfolge gespeicherte Skripte auszuführen (wie Eval - Funktionen in anderen Sprachen). Über BIP 12 wird nicht viel diskutiert: Es wird nicht verwendet. Es ist sehr kompliziert, es erlaubt einige Schleifen (die Skripte nicht unterstützen sollten) und macht es schwierig, Skripte zu analysieren, ohne sie auszuführen.

Mit BIP 16 dürfen Skripte einmal (nicht rekursiv) in einer Zeichenfolge gespeicherte Skripte ausführen, und es gibt auch andere Einschränkungen, die alle oben erwähnten Nachteile von BIP 12 beseitigen.

CODEHASHCHECK macht dasselbe wie BIP 16, aber einige technische Unterschiede machen es wohl eleganter.

Alle diese Vorschläge sollen das Problem lösen, wie Empfänger wählen können, welche Beschränkungen sie auf Coins anwenden, die sie an einer Adresse erhalten (Zwei-Faktor-Authentifizierung usw.). Derzeit definieren Versender immer die Beschränkungen für gesendete Coins, was in vielen Fällen unpraktisch ist.

Vielen Dank. Ich habe meine Frage so aktualisiert, dass sie sich auf den Vergleich zwischen allen drei Vorschlägen bezieht. Können Sie bitte die technischen Unterschiede zwischen BIP 16 und CODEHASHCHECK erläutern?
Mit BIP 16 werden auf Skripte, die mit einer bestimmten Vorlage (OP_HASH160- Hash OP_EQUAL) übereinstimmen, zusätzliche Prüfungen angewendet, obwohl diese zusätzlichen Prüfungen nicht explizit im Skript angegeben sind. BIP 16 erzeugt keine neuen Opcodes. CODEHASHCHECK erstellt einen neuen Opcode, um die Überprüfung durchzuführen. BIP 16 wäre der einzige Fall von "vorlagenbasiertem" Verhalten in Script, daher denke ich, dass CODEHASHCHECK konsistenter mit dem Rest von Script ist und bevorzugt werden sollte.
Also ... ist der Unterschied zwischen ihnen nur eine Frage des Stils? Gibt es einen funktionellen Unterschied? Könnten Sie mir das so erklären, als wäre ich ein Zehnjähriger? (Oder nur jemand ohne viel Wissen im Kern-Bitcoin-Protokoll), vielleicht mit einem Beispiel dafür, warum das wichtig ist?
Für mich ist es vor allem eine Frage des Stils. CHC verwendet keine hässlichen Scripts-in-Strings oder Template-Matching. BIP 16 hat eine geringere Datengröße und eine einfachere Implementierung, aber es ist eindeutig ein Hack. Dies wird ein Protokoll definieren, das Jahre dauern kann, daher zählt der Stil. (Ich interessiere mich jedoch nicht so sehr - beides wäre akzeptabel.)
Ich bin absolut nicht der Meinung, dass CHC eleganter ist. Es fügt einen Opcode hinzu, der sich unterschiedlich verhält, je nachdem, ob der Opcode in scriptSig oder scriptPubKey erscheint oder nicht.

Der größte Nachteil von OP_EVAL (BIP 12) bestand darin, das Scripting-System, das für Transaktionsturing verwendet wird, zu vervollständigen und damit jeden Versuch einer statischen Analyse aus dem Wasser zu blasen. Dies wurde als sehr ernstes Problem angesehen und BIP12 wurde ziemlich erschossen und begraben.

P2SH (BIP 16) ist als ein weiterer Ansatz für das gleiche Problem der Einführung von autorisierten Transaktionen mit mehreren Schlüsseln auf Protokollebene gedacht. Es ist speziell darauf ausgelegt (wie es das ursprüngliche Skriptsystem war), nicht vollständig zu sein.

Es gab eine lebhafte Diskussion zwischen den Kernentwicklern und Luke-Jr, der vorschlug, seine eigene Lösung, OP_CODEHASHCHECK, anstelle von P2SH zu verwenden.

Lesen Sie den Beitrag für mehr Details.

Danke für die Information. Ich habe meine Frage aktualisiert, um auch OP_CODEHASHCHECK in den Vergleich aufzunehmen - was ich wirklich wissen möchte, ist, was der große Unterschied zwischen OP_CODEHASHCHECK und BIP 16 ist. Ich könnte gehen und den Beitrag lesen, aber bis ich es tue (und für diejenigen, die es tun nicht), wäre es gut, den Kernunterschied hier zusammenzufassen.

Es gibt drei BIPs, die alle darauf abzielen, die Push-to-Script-Hash (P2SH)-Funktion bereitzustellen:

BIP 12 (OP_EVAL): Ein neuer Opcode nimmt einen Wert vom Stapel (von überall) und führt ihn aus, als wäre er Teil des Skripts selbst.

  • Nachteile: Dies macht Bitcoin Scripting turing-complete (es ermöglicht Schleifen) und nicht statisch analysierbar.
  • Vorteile: Sie können in Skripten Dinge tun, die eine vollständige Sprache erfordern.

BIP 16: Wenn eine Vorlage für ein magisches Skript gesehen wird, müssen ausführende Clients nach Abschluss des Skripts auch das oberste Stack-Element ausführen.

  • Nachteile: Erfordert die Sonderschreibung einer Skriptvorlage und ein anderes Verhalten als die einfache Ausführung als Skript. Kann nicht in Kombination mit dem aktuellen Bitcoin Script-Protokoll verwendet werden, setzt es jedoch nicht außer Kraft.
  • Vorteile: Behält den aktuellen, meist statisch auswertbaren Status von Skripten bei.

BIP 17 (OP_CHECKHASHVERIFY): Ein neuer Opcode hasht das bereits ausgeführte Skript und vergleicht es einfach mit dem obersten Stapelelement.

  • Nachteile: Kann nicht verwendet werden, um Code in irgendeiner Weise auszuwerten.
  • Vorteile: Statisch analysierbar mit genau der gleichen Methode wie jetzt und erfordert nur eine triviale Opcode-Hinzufügung, ohne das gesamte Skriptprotokoll neu zu strukturieren.

Beachten Sie auch, dass BIP 17 nicht ausschließt, dass BIP 12 oder 16 in Zukunft implementiert werden, falls ein anderer Bedarf für ihre komplizierteren Fähigkeiten entstehen sollte.