IsStandardTx()

¿Qué es una transacción estándar?, ¿y una no estándar?

 

¿Sabías qué?, el bloque 682.482 es el que más «tamaño» (size) tiene, con 2.424.027 bytes, pero curiosamente no es el bloque que más transacciones contiene, apenas tiene 118 transacciones.

Por contra, el bloque que más transacciones tiene es el 367.853, con 12.239 transacciones y un tamaño de apenas 999.956 bytes.

 

Como muchos de los artículos que escribo, este no podía ser la excepción y nace de las dudas que Bitcoin plantea. En este caso también derivado de la curiosidad de entender ¿cómo es que puede darse una situación como la anterior?.

Bloque Tamaño (Size) Entradas (Inputs) Salidas (Outputs) Transacciones (en el bloque)

682.482

2.424.027

6715

278

118

367.853

999.956

13.175

12.917

12.239

Ver esta información me llevó a preguntarme, ¿cómo es posible que el bloque con más transacciones no sea el bloque con mayor tamaño?

Y aunque más o menos sabía la respuesta, he querido hacer este artículo, que no pretende ser un detalle técnico, sino una explicación más «terrenal», orientada, como la mayoría de mis artículos a gente que como yo somos más usuarios que desarrolladores y queremos entender de una forma menos «complicada» el por qué de las cosas dentro de Bitcoin, ¡espero que lo consiga!

 

Importante saber, cuando hablamos del script de una transacción Bitcoin, estamos hablando de un lenguaje que permite poder escribir, ejecutar y validar de forma estructurada una secuencia de gasto Bitcoin. Es decir, permitir gastar el bitcoin involucrado en esa transacción, aunque como veremos, ¡no siempre tiene por qué ser así!

 

Pues bien, entonces, la respuesta corta a por qué se puede dar una situación como la planteada anteriormente, sería que se debe al tipo de script que se utilizó en las transacciones incluidas en cada bloque, aunque como digo es la respuesta corta, ya que en los detalles está el diablo.

 

En el bloque 682.482, encontramos que la mayoría de las transacciones son del tipo P2SH. Este script es llamado Pay to Script Hash (P2SH), las direcciones usadas empiezan por 3. Es un tipo de script que optimiza el espacio mejor que un script tipo Legacy (P2PK), pero peor que un escript de tipo Segwit nativo (P2WPKH).

 

A esto hay que añadir el hecho de que gran parte de estas transacciones contienen muchas entradas, es decir, utilizan muchas “monedas o utxos” dentro de cada transacción. Esto hace que el peso de cada transacción aumente. Hay muchas transacciones que tienen más de 200 entradas. 

 

Sin embargo, lo interesante, al menos para mí, está en el bloque 367.853. Este bloque tiene unas cuantas transacciones que utilizan un tipo de script menos «óptimo» que el utilizado en el bloque 682.482, el P2PKH, el cual es de tipo Legacy – Pay to Public Key Hash. Pero a pesar de ello tenemos una gran cantidad de transacciones que pesan tan solo 62 bytes, esto no debería ser posible usando scripts que no optimizan el tamaño de las transacciones

 

¿Y entonces cómo puede ser?, pues revisando me encontré con que esas transacciones son transacciones no estándar.

Transacciones estándar y no-estándar en Bitcoin

 

Verificar una sola transacción en Bitcoin es bastante sencillo (por no decir barato) y eficiente, pero verificar miles, ya es otra cosa, se vuelve bastante costoso y complejo.

Si a ello le añadimos que las transacciones pueden ser complejas y tener muchos resultados o ser transacciones cuyo único objetivo sea perjudicar a la red (que sean basura simplemente), pues la complejidad puede elevarse.

 

Dado lo anterior y para desalentar el perjuicio de la red de Bitcoin los desarrolladores de Bitcoin Core implementaron una serie de reglas y validaciones que toda transacción debe cumplir, con el objetivo de proteger a la red de ineficiencias en la propagación de transacciones. (Aunque ya desde sus inicios Satoshi implementó la verificación de transacciones no estándar).

 

Esas validaciones se realizan a través de las funciones isStandard() e isStandardTx() de la clase policy.cpp.

Podríamos decir que estas validaciones se han convertido en un estándar de facto, por lo cual cualquier transacción que no las cumpla se considera una transacción NO estándar. Y una transacción no estándar terminará sin ser admitida por la inmensa mayoría de los nodos, lo cual llevaría además, a que no pudiera ser propagada por la red y por ende no llegaría a los mineros.

 

No es objetivo de este artículo entrar a detalles técnicos de una transacción, si quieres hacerlo, te dejo un par de links para que leas más al respecto. Primero este artículo propio de mi blog donde indico cómo funciona Bitcoin de forma genérica y para principiantes. Y este otro de Sergí Delgado en Estudio Bitcoin, un gran artículo donde Sergí desgrana a nivel atómico una transacción estándar de Bitcoin.

 

Entonces, una transacción estándar sería aquella que cumple con las reglas y validaciones impuestas en Bitcoin Core, que a día de hoy, los scripts de salida estándar serían los siguientes:

  • PubKey
  • PubKeyHash
  • Scripthash
  • Multisig
  • nulldata
  • Witness version 0 keyhash
  • Witness version 0 Scripthash
  • Witness version 1 Taproot
  • Witness unknown

Cualquier otro script no será estándar y toda la transacción será rechazada por no ser estándar.

 

Tipos de salidas de una transacción estándar
Tipos de salida estándar en el código de Bitcoin Core

 

Si deseas conocer más a cerca de los diferentes tipos de scripts, este artículo puede ser de utilidad, pero como comenté, este artículo no tiene ese objetivo.

 

Sin embargo, por otro lado, no se trata de prohibir el uso de transacciones más complejas, costosas y menos comunes, se trata de normalizar la validación de la gran mayoría de ellas. Si bien Bitcoin Core es el cliente más usado, no es el único, por lo que podría existir algún otro cliente de la red que pudiera aceptar otro tipo de transacciones diferentes del estándar impuesto por Bitcoin Core.

 

Incluso, transacciones que no pasen por las validaciones de los nodos pueden ser directamente entregadas a mineros, los cuales podrían incluirlas en bloques que sean sellados (minados) por ellos e incluirse en la cadena.

De lo anterior, la duda que surgiría inmediatamente sería: ¿Y con esto no se estaría rompiendo la seguridad de Bitcoin?

 

La respuesta es no.

El que una transacción no sea considerada como estándar (en términos de las validaciones que implementa Bitcoin Core), no significa que esa transacción pueda «romper» las reglas de consenso y que pueda por ejemplo, provocar un doble gasto o que gaste más de lo que se tiene de saldo.

 

El que sea llamada no estándar es porque tiene una composición distinta pero no puede romper la seguridad de la red, ya que una vez incluida en un bloque, todos los nodos la revisan y validan, no que sea o no estándar, si no que cumpla con lo que es una transacción de Bitcoin: Una operación en la red que permite a los usuarios gastar satoshis sin incurrir en doble gasto o falta alguna a las reglas de la red.

Todos los nodos aceptarán la transacción no estándar una vez que esté en un bloque (si pasa las validaciones). Por lo tanto, si bien se pueden realizar transacciones no estándar, deben enviarse directamente a un minero en lugar de transmitirse como una transacción normal por los motivos ya explicados anteriormente.

 

Entonces, ¿las transacciones no estándar qué uso pueden tener?

Pues la respuesta exacta es que pueden tener infinidad de usos, desde los meramente de pruebas, pasando por la creación de transacciones complejas, como por ejemplo aquellas que puedan requerir muchas firmas (la validación de muchas firmas es costosa en los nodos), hasta llegar a transacciones que intenten perjudicar a la red.

 

Volviendo al caso del bloque 367.853, las transacciones que pesan tan solo 62 bytes, son todas transacciones no validas como podemos ver en este ejemplo de la imagen, las cuales por cierto en este caso NO generan ningún tipo de salida que pueda gastarse, es decir no tiene bitcoin en su salida, pero sin embargo sirven para guardar en 40 bytes, información en la cadena de bloques. Lo que no encontré fue cuál era la finalidad de guardar la información de esas salidas, tal vez simplemente pruebas.

 

Transacción no estándar: 94f08a8ef6f48922052e1d2855ef5a7eca0b1648a4868da923cd5b2aafbd8882

 

En resumen, el bloque 367.853 llego a tener muchas más transacciones y tener un tamaño (size) menor debido a que usaron un tipo de script que permitía reducir mucho el tamaño de la transacción, pero no eran transacciones estándar y que además, no generaban salidas que pudieran gastarse.

Y el bloque 682.482, tenía un tamaño mucho mayor, sin contener una gran cantidad de transacciones, debido a que el script usado en la mayoría de ellas no optimiza el espacio, sumado a que las entradas y salidas de muchas de esas transacciones eran también muchas, lo que ocasiona que la transacción crezca.

 

Si llegaste hasta aquí, como siempre, muchas gracias por leerme, y espero que esta información te resulte interesante y útil para entender el funcionamiento de Bitcoin desde un punto de vista menos técnico, pero si quieres profundizar, el artículo incluye links al sustento técnico y a otros artículos que entran a mayor detalle, espero también te sean de ayuda.

 

Si te gusta lo que hago, te agradeceré una donación, siempre es gratificante saber que otras personas valoran el trabajo y tiempo invertido, pero si no puedes, no pasa nada, compartir la información también ayuda a que otros vayan conociendo sobre Bitcoin, el cual es mi objetivo.

¡Muchas gracias!

 

5/5

Puedes dejar una propina con el botón «Invítame un café».

O mediante Lightning network:

⚡[email protected]

También puedes hacerlo onchain, vía Paynyms de Samourai Wallet:

PayNym: +decentralized