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?
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.
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.
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.
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.
BIP 17 (OP_CHECKHASHVERIFY): Ein neuer Opcode hasht das bereits ausgeführte Skript und vergleicht es einfach mit dem obersten Stapelelement.
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.
DH
Reißer234