Geschichte hinter der Skriptsprache in Bitcoin?

Skript war in der ersten Version von Bitcoin. Satoshi entwickelte Bitcoin privat, bevor er das voll nutzbare Bitcoin 0.1 veröffentlichte, und er sagte sehr wenig über seinen Denkprozess, sodass wir wahrscheinlich nie genau wissen werden, warum viele Dinge so gemacht wurden, wie sie waren.

Das Skript hatte mehrere schwerwiegende Fehler, als Bitcoin zum ersten Mal veröffentlicht wurde, und einige Fehler sind immer noch vorhanden. Es ist klar, dass Satoshi Script vor der Veröffentlichung von Bitcoin nicht gründlich getestet hat. Und obwohl es sehr komplex ist, ist es immer noch zu unvollständig, als dass die meisten Opcodes wirklich von Nutzen sein könnten. Angesichts dessen wird oft spekuliert, dass Script so etwas wie ein nachträglicher Einfall war. Vielleicht schickte Satoshis Design Bitcoins ursprünglich nur direkt an öffentliche Schlüssel, aber als er Unterstützung für Bitcoin-Adressen hinzufügte und über zukünftige Transaktionstypen nachdachte, erkannte er, dass eine Skriptsprache für die Vorwärtskompatibilität nützlich wäre.

Eine stapelbasierte Sprache ist hier die natürliche Wahl. Die Skriptverarbeitung ist kinderleicht und sehr schnell: Lesen Sie einfach weiter Opcodes aus dem Skript und werten Sie sie aus, bis das Skript vollständig ist. Jeder Opcode ist ziemlich in sich abgeschlossen. Es ist auch einfach, Skripte zu analysieren, da alles rechts von einem bestimmten Punkt in einem Skript als Funktion betrachtet werden kann. Sie können sicher sein, dass jeder scriptPubKey, der mit OP_RETURN beginnt, die Validierung immer nicht bestehen wird und dass jedes Skript, das mit endet <pubKey> OP_CHECKSIG, immer die Signatur dieses öffentlichen Schlüssels erfordert, unabhängig davon, was der Rest des Skripts enthält.

Dieser funktionale Aspekt von Script war besonders wichtig, als Skripte noch durch direktes Verketten von scriptSig und scriptPubKey ausgewertet wurden, anstatt sie wie heute separat auszuwerten. Theoretisch könnten Sie alles in scriptPubKey einfügen und sicher sein, dass sich Ihr scriptPubKey unabhängig davon, was in scriptSig enthalten ist, wie eine Funktion verhält, die eine angemessene Anzahl von Argumenten aus dem Stapel nimmt. Der Opcode OP_RETURN führte jedoch ursprünglich nur dazu, dass das Skript vorzeitig beendet wurde, anstatt dass es fehlschlug, sodass Sie die Bitcoins von jedem stehlen konnten, indem Sie einfach die scriptSig verwendenOP_TRUE OP_RETURN. Es war auch möglich, einen Pushdata-Opcode direkt am Ende einer scriptSig einzufügen, um den gesamten scriptPubKey in eine Konstante umzuwandeln (die als wahr ausgewertet wird). Satoshi hat diese Fehler behoben, indem er das Verhalten von OP_RETURN so geändert hat, dass die Transaktion sofort fehlschlägt, und es so gemacht hat, dass scriptSig und scriptPubKey in zwei separaten Schritten ausgewertet werden.

Ich bin auf einen Kommentar von Mike Hearn im Zusammenhang mit dem alten OP_RETURN-Bug gestoßen, der aufschlussreich schien:

Das Scripting-System kam mir immer wie eine ziemlich späte Hinzufügung zum Design vor. Satoshi gab dies zu, als er sagte, dass er es hinzufügte, nachdem er auf eine Explosion von Sonderfällen gestoßen war, als er verschiedene Arten von Verträgen entwarf. Die Tatsache, dass es einen offensichtlichen Fehler in CHECKMULTISIG gibt, ist ein weiterer Beweis dafür, dass dieser Teil ein allgemeiner Eiljob ist, zusammen mit Satoshis Bereitschaft, einen Großteil seiner Funktionalität später mit den IsStandard-Prüfungen zu deaktivieren. Auch das Design von CHECKSIG ist eine offensichtliche Nachrüstung, es wäre viel sinnvoller gewesen, es zu zerlegen, und wir haben nie einen Anwendungsfall für 99 % der Opcodes gefunden, obwohl wir alle Vertragstypen, die er jemals erwähnt hat, erfolgreich entworfen (umgestaltet?) haben.

http://sourceforge.net/p/bitcoin/mailman/message/30479316/