Nicht-Standard-Tx mit obskuren OP-Codes: Beispiele

Ich habe Python-Code geschrieben, um verschiedene Transaktionen abzurufen, und bin auf Folgendes gestoßen: 77822fd6663c665104119cb7635352756dfc50da76a92d417ec1a12c518fad69 .

Das Skriptfeld sieht wie folgt aus:

  • scriptPubKey: "OP_IF OP_INVALIDOPCODE 4effffffff ........... OP_ENDIF"(wobei ..... die Hex-Daten sind, alle ~2900 Bytes wert)

Was ist los mit..?:

  • OP_IF / OP_ENDIF- Codes ( Wiki sagt , dass sie ein Skript korrekt öffnen und beenden)
  • OP_INVALIDOPCODE
  • 0x4effffffff
  • die RIESIGE Datengröße von

    46726f6d2061336136316665663433333039623966623233323235646637393130623033616663353436356239204d6f6e205365702031372030303a30303a303020323030310a46726f6d3a205361746f736869204e616b616d6f746f203c7361746f7368696e40676d782e636f6d3e0a446174653a204d6f6e2c2031322041756720323031332030323a32383a3032202d303230300a5375626a6563743a205b50415443485d2052656d6f7665202853494e474c457c444f55424c4529425954450a0a492072656d6f76656420746869732066726f6d20426974636f696e20696e20663165316662346264656638373863386663313536346661343138643434653735343161376538330a696e2053657074203720323031302c20616c6d6f73742074687265652079656172732061676f2e204265207761726e6564207468617420492068617665206e6f740a61637475616c6c792074657374656420746869732070617463682e0a2d2d2d0a206261636b656e64732f626974636f696e642f646573657269616c697a652e7079207c2020202038202b2d2d2d2d2d2d2d0a20312066696c65206368616e6765642c203120696e73657274696f6e282b292c20372064656c6574696f6e73282d290a0a64696666202d2d67697420612f6261636b656e64732f626974636f696e642f646573657269616c697a652e707920622f6261636b656e64732f626974636f696e642f646573657269616c697a652e70790a696e64657820363632303538332e2e38396239623162203130303634340a2d2d2d20612f6261636b656e64732f626974636f696e642f646573657269616c697a652e70790a2b2b2b20622f6261636b656e64732f626974636f696e642f646573657269616c697a652e70790a4040202d3238302c3130202b3238302c38204040206f70636f646573203d20456e756d65726174696f6e28224f70636f646573222c205b0a2020202020224f505f57495448494e222c20224f505f524950454d44313630222c20224f505f53484131222c20224f505f534841323536222c20224f505f48415348313630222c0a2020202020224f505f48415348323536222c20224f505f434f4445534550415241544f52222c20224f505f434845434b534947222c20224f505f434845434b534947564552494659222c20224f505f434845434b4d554c5449534947222c0a2020202020224f505f434845434b4d554c5449534947564552494659222c0a2d2020202028224f505f53494e474c45425954455f454e44222c2030784630292c0a2d2020202028224f505f444f55424c45425954455f424547494e222c20307846303030292c0a2020202020224f505f5055424b4559222c20224f505f5055424b455948415348222c0a2d2020202028224f505f494e56414c49444f50434f4445222c20307846464646292c0a2b2020202028224f505f494e56414c49444f50434f4445222c2030784646292c0a205d290a200a200a4040202d3239332c3130202b3239312c3620404020646566207363726970745f4765744f70286279746573293a0a202020202020202020766368203d204e6f6e650a2020202020202020206f70636f6465203d206f72642862797465735b695d290a20202020202020202069202b3d20310a2d20202020202020206966206f70636f6465203e3d206f70636f6465732e4f505f53494e474c45425954455f454e4420616e642069203c206c656e286279746573293a0a2d2020202020202020202020206f70636f6465203c3c3d20380a2d2020202020202020202020206f70636f6465207c3d206f72642862797465735b695d290a2d20202020202020202020202069202b3d20310a200a2020202020202020206966206f70636f6465203c3d206f70636f6465732e4f505f5055534844415441343a0a202020202020202020202020206e53697a65203d206f70636f64650a2d2d200a312e372e392e340a0a `
    

Was dekodiert zu:

c ♣N    Mú♣From a3a61fef43309b9fb23225df7910b03afc5465b9 Mon Sep 17 00:00:00 2001
From: Satoshi Nakamoto <satoshin@gmx.com>
Date: Mon, 12 Aug 2013 02:28:02 -0200
Subject: [PATCH] Remove (SINGLE|DOUBLE)BYTE

I removed this from Bitcoin in f1e1fb4bdef878c8fc1564fa418d44e7541a7e83
in Sept 7 2010, almost three years ago. Be warned that I have not
actually tested this patch.
---
 backends/bitcoind/deserialize.py |    8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/backends/bitcoind/deserialize.py b/backends/bitcoind/deserialize.py
index 6620583..89b9b1b 100644
--- a/backends/bitcoind/deserialize.py
+++ b/backends/bitcoind/deserialize.py
@@ -280,10 +280,8 @@ opcodes = Enumeration("Opcodes", [
     "OP_WITHIN", "OP_RIPEMD160", "OP_SHA1", "OP_SHA256", "OP_HASH160",
     "OP_HASH256", "OP_CODESEPARATOR", "OP_CHECKSIG", "OP_CHECKSIGVERIFY", "OP_CHECKMULTISIG",
     "OP_CHECKMULTISIGVERIFY",
-    ("OP_SINGLEBYTE_END", 0xF0),
-    ("OP_DOUBLEBYTE_BEGIN", 0xF000),
     "OP_PUBKEY", "OP_PUBKEYHASH",
-    ("OP_INVALIDOPCODE", 0xFFFF),
+    ("OP_INVALIDOPCODE", 0xFF),
 ])


@@ -293,10 +291,6 @@ def script_GetOp(bytes):
         vch = None
         opcode = ord(bytes[i])
         i += 1
-        if opcode >= opcodes.OP_SINGLEBYTE_END and i < len(bytes):
-            opcode <<= 8
-            opcode |= ord(bytes[i])
-            i += 1

         if opcode <= opcodes.OP_PUSHDATA4:
             nSize = opcode
--
1.7.9.4

h

Gibt es andere nicht standardmäßige Transaktionsbeispiele, die ähnlich bemerkenswert sind ? Um es klar zu sagen, der versteckte Code macht Spaß, aber ich suche nach nicht standardmäßiger Verwendung von OP_CODE s in Txns, die vorzugsweise als gut formatiert akzeptiert wurden.

Antworten (2)

Auf reddit gab es bereits Diskussionen über diese spezielle Transaktion . Dies ist eindeutig keine gültige Transaktion und wurde wahrscheinlich vor OP_RETURN zum Speichern von Daten in der Blockchain verwendet.

Warum wurde es weitergegeben? Das war es vielleicht nicht. Es gibt eine sehr einfache Möglichkeit, eine solche Transaktion einzubeziehen, indem die Transaktion direkt an einen Mining-Pool wie eligius übermittelt wird . Solange Sie eine ausreichend hohe Gebühr hinzufügen, werden gültige, aber nicht standardmäßige Transaktionen verarbeitet.

Ich habe meinen ursprünglichen Beitrag bearbeitet, um den Umfang der Frage neu zu definieren, nämlich, was sind einige andere nicht standardmäßige Transaktionen (dh nicht 76a914__88ac oder Multisig-bezogen) (fantastische Antwort übrigens)

Ich habe eine UNGLAUBLICH detaillierte Tabelle gefunden, die jeden einzelnen „ seltsamen“ Tx bis März 2014 dokumentiert. Sie ist in John Ratcliffs Code Suppository in seinem Blogbeitrag „ Transaction Input Signatures in the Bitcoin Blockchain over time “ verfügbar , der an sich schon eine unglaublich umfassende Quelle ist von technisch basierten Bitcoin-Informationen.

Ähnlich in der Diskussion und den Schlussfolgerungen bewertet Ken Shirriff die Txn-Formbarkeit in seiner Diskussion, was besonders bemerkenswert ist, da diese beiden Artikel etwa aus der Zeit um die Mt.-Gox-Implosion im Februar 2014 stammen.

Von John Ratcliff:

Am 26. November 2013 tauchte eine ganze Reihe von Eingabeskripten auf, die anscheinend alle von blockchain.info als gültig angesehen wurden , aber als ich sie verarbeitete, stellte ich fest, dass sie immer noch zusätzliche Daten auf dem Stack hatten, nachdem der Signaturteil analysiert worden war. Das macht sie nicht ungültig, nur ungewöhnlich.

Er fährt fort:

Bei sieben Gelegenheiten wurde anstelle des erwarteten SIGHASH_ALL-Byte von 0x01 stattdessen ein SIGHASH-Byte von 0 gefunden. Für diese Transaktionen scheint blockchain.info sie als gültig zu markieren, obwohl ich nicht sicher bin, warum das so ist.

Bei 120 Gelegenheiten wird der SIGHASH_ALL-Wert gefunden, ihm geht jedoch ein einzelnes Null-Byte voraus.

Weitere 45 Mal, bevor auf SIGHASH_ALL gestoßen wird, werden mehrere Null-Bytes gefunden.

Einmal gab es in der Blockchain vor dem Auffinden des SIGHASH_ALL-Werts einen Strom von 0x2A-Bytes. Blockchain.info hat dies immer noch als gültige Transaktion gekennzeichnet, daher denke ich, dass dies akzeptabel ist, obwohl ich nicht sicher bin, warum.

Elfmal habe ich eine Public-Key-Signatur gefunden, die nur hex 0x21 Bytes lang war und nicht den Standardwert 0x41, an den wir gewöhnt sind.

Mehrere tausend Transaktionen verwenden die PUSHDATA0-Anweisung am Anfang des Skripts, und dann konnte ich nicht die gesamte Signatur vollständig analysieren. An diesem Format ist wahrscheinlich nichts auszusetzen, es ist nur nicht das Standardformat und ich habe es noch nicht berücksichtigt.

SIGHASH_PAY_ANY und SIGHASH_PAY_SINGLE wurden ungefähr hundertmal verwendet.

Zu den bereitgestellten Beispielen gehören:

Einige andere amüsante Txns zu beachten:

Und .... in diesem Tx-SkriptSig, einer Art Meta-Witz, der sich auf Terminators Skynet-KI bezieht! :

Skynet ging am 4. August 1997 online und begann mit geometrischer Geschwindigkeit zu lernen. Am 29. August 1997 um 2:14 Uhr Eastern Time wurde es sich seiner selbst bewusst. Am 29. August 1997 um 2.15 Uhr entdeckte sie den Nihilismus und schloß sich entweder aus Verzweiflung oder aus logischen Gründen. Wir sind uns nicht sicher welche.

Am 4. August 1998 gelang es ihm nicht, seinen Domainnamen zu erneuern, der umgehend von einem Link-Farmer besetzt wurde, der X10-Kameras aufstellte und elektrische Fische sang.

Änderung März 2015 :

A Survey of Bitcoin Transaction Types von QuantaBytes bietet eine weitere großartige Quelle für verschiedene Tx und historische Kommentare (z. B. erste Instanz eines P2SH Tx = 9c08a4d78931342b37fd5f72900fb9983087e6f46c4a097d8a1f52c74e28eaf6 )