Tx no estándar con códigos OP oscuros: ejemplos

He estado escribiendo código de Python para obtener varias transacciones y encontré esto: 77822fd6663c665104119cb7635352756dfc50da76a92d417ec1a12c518fad69 .

El campo del script es el siguiente:

  • scriptPubKey: "OP_IF OP_INVALIDOPCODE 4effffffff ........... OP_ENDIF"(donde ..... son los datos hexadecimales, todos valen ~2900 bytes)

¿Qué está pasando con..?:

  • Códigos OP_IF / OP_ENDIF ( wiki dice que abren y finalizan correctamente un script)
  • OP_INVALIDOPCODE
  • 0x4effffffff
  • el ENORME tamaño de datos de

    46726f6d2061336136316665663433333039623966623233323235646637393130623033616663353436356239204d6f6e205365702031372030303a30303a303020323030310a46726f6d3a205361746f736869204e616b616d6f746f203c7361746f7368696e40676d782e636f6d3e0a446174653a204d6f6e2c2031322041756720323031332030323a32383a3032202d303230300a5375626a6563743a205b50415443485d2052656d6f7665202853494e474c457c444f55424c4529425954450a0a492072656d6f76656420746869732066726f6d20426974636f696e20696e20663165316662346264656638373863386663313536346661343138643434653735343161376538330a696e2053657074203720323031302c20616c6d6f73742074687265652079656172732061676f2e204265207761726e6564207468617420492068617665206e6f740a61637475616c6c792074657374656420746869732070617463682e0a2d2d2d0a206261636b656e64732f626974636f696e642f646573657269616c697a652e7079207c2020202038202b2d2d2d2d2d2d2d0a20312066696c65206368616e6765642c203120696e73657274696f6e282b292c20372064656c6574696f6e73282d290a0a64696666202d2d67697420612f6261636b656e64732f626974636f696e642f646573657269616c697a652e707920622f6261636b656e64732f626974636f696e642f646573657269616c697a652e70790a696e64657820363632303538332e2e38396239623162203130303634340a2d2d2d20612f6261636b656e64732f626974636f696e642f646573657269616c697a652e70790a2b2b2b20622f6261636b656e64732f626974636f696e642f646573657269616c697a652e70790a4040202d3238302c3130202b3238302c38204040206f70636f646573203d20456e756d65726174696f6e28224f70636f646573222c205b0a2020202020224f505f57495448494e222c20224f505f524950454d44313630222c20224f505f53484131222c20224f505f534841323536222c20224f505f48415348313630222c0a2020202020224f505f48415348323536222c20224f505f434f4445534550415241544f52222c20224f505f434845434b534947222c20224f505f434845434b534947564552494659222c20224f505f434845434b4d554c5449534947222c0a2020202020224f505f434845434b4d554c5449534947564552494659222c0a2d2020202028224f505f53494e474c45425954455f454e44222c2030784630292c0a2d2020202028224f505f444f55424c45425954455f424547494e222c20307846303030292c0a2020202020224f505f5055424b4559222c20224f505f5055424b455948415348222c0a2d2020202028224f505f494e56414c49444f50434f4445222c20307846464646292c0a2b2020202028224f505f494e56414c49444f50434f4445222c2030784646292c0a205d290a200a200a4040202d3239332c3130202b3239312c3620404020646566207363726970745f4765744f70286279746573293a0a202020202020202020766368203d204e6f6e650a2020202020202020206f70636f6465203d206f72642862797465735b695d290a20202020202020202069202b3d20310a2d20202020202020206966206f70636f6465203e3d206f70636f6465732e4f505f53494e474c45425954455f454e4420616e642069203c206c656e286279746573293a0a2d2020202020202020202020206f70636f6465203c3c3d20380a2d2020202020202020202020206f70636f6465207c3d206f72642862797465735b695d290a2d20202020202020202020202069202b3d20310a200a2020202020202020206966206f70636f6465203c3d206f70636f6465732e4f505f5055534844415441343a0a202020202020202020202020206e53697a65203d206f70636f64650a2d2d200a312e372e392e340a0a `
    

Que decodifica a:

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

¿Hay otros ejemplos de transacciones no estándar que sean igualmente dignos de mención ? Para ser claros, el código oculto es divertido, pero estoy buscando un uso no estándar de OP_CODE s en Txns que preferiblemente hayan sido aceptados y formateados.

Respuestas (2)

Ha habido una discusión sobre esta transacción en particular antes en reddit . Claramente, esta no es una transacción válida y probablemente se usó para almacenar datos en la cadena de bloques antes de OP_RETURN.

¿Por qué fue retransmitido? Puede que no lo haya sido. Hay una manera muy fácil de incluir una transacción como esta y es enviando la transacción directamente a un grupo de minería como eligius . Siempre que agregue una tarifa lo suficientemente alta, procesarán transacciones válidas, pero no estándar.

Edité mi publicación original para reformular el alcance de la pregunta, es decir, ¿cuáles son algunas otras transacciones no estándar (es decir, no relacionadas con 76a914__88ac o multisig) (respuesta fantástica por cierto)

Encontré una hoja de cálculo INCREÍBLEMENTE detallada que documenta cada Tx " extraño" hasta marzo de 2014. Está disponible en Code Suppository de John Ratcliff en su publicación de blog " Transaction Input Signatures in the Bitcoin Blockchain over time " , que en sí misma es una fuente increíblemente completa de información técnica de Bitcoin.

De manera similar en la discusión y las conclusiones, Ken Shirriff evalúa la maleabilidad de Txn en su discusión, lo cual es especialmente digno de mención ya que ambos artículos datan de alrededor de la implosión de Mt. Gox de febrero de 2014.

De John Ratcliff:

El 26 de noviembre de 2013, apareció una gran cantidad de scripts de entrada que parecían ser considerados válidos por blockchain.info, pero cuando los procesé, descubrí que aún tenían datos adicionales en la pila después de analizar la parte de la firma. Esto no los hace inválidos, simplemente inusuales.

Él continúa:

En siete ocasiones, en lugar de encontrar el byte SIGHASH_ALL esperado de 0x01, se encontró un byte SIGHASH de 0. Para esas transacciones, blockchain.info parece marcarlas como válidas, aunque no estoy seguro de por qué.

En 120 ocasiones se encuentra el valor SIGHASH_ALL, sin embargo, va precedido de un único byte cero.

Se encuentran 45 veces adicionales antes de encontrar SIGHASH_ALL múltiples bytes cero.

En una ocasión en la cadena de bloques, antes de encontrar el valor SIGHASH_ALL había un flujo de 0x2A bytes. Blockchain.info todavía marcó esto como una transacción válida, así que supongo que esto es aceptable, aunque no estoy seguro de por qué.

Once veces encontré una firma de clave pública que tenía solo 0x21 bytes hexadecimales en lugar del valor estándar de 0x41 que estamos acostumbrados a ver.

Varios miles de transacciones usan la instrucción PUSHDATA0 al frente del script, y luego no pude analizar completamente toda la firma. Probablemente no haya nada malo con este formato, simplemente no es el más estándar y aún no lo he tenido en cuenta.

SIGHASH_PAY_ANY y SIGHASH_PAY_SINGLE se usaron unas cien veces más o menos.

Los ejemplos proporcionados incluyen:

Algunas otras Txns divertidas para tener en cuenta:

Y....en el scriptSig de este Tx, ¡una especie de metabroma que hace referencia a la IA Skynet de Terminator! :

Skynet se puso en línea el 4 de agosto de 1997 y comenzó a aprender a un ritmo geométrico. Se hizo consciente de sí mismo el 29 de agosto de 1997 a las 2:14 am, hora del este. El 29 de agosto de 1997 a las 2:15 am descubrió el nihilismo y se cerró por desesperación o porque era lógico. No estamos seguros de cuál.

El 4 de agosto de 1998, no pudo renovar su nombre de dominio, que fue ocupado rápidamente por un agricultor de enlaces que lanzaba cámaras X10 y cantaba peces eléctricos.

Edición de marzo de 2015 :

Una encuesta de tipos de transacciones de Bitcoin de QuantaBytes proporciona otra gran fuente de varios Tx y comentarios históricos (es decir, la primera instancia de un P2SH Tx = 9c08a4d78931342b37fd5f72900fb9983087e6f46c4a097d8a1f52c74e28eaf6 )