¿Los tres tipos de direcciones de Bitcoin son interoperables (heredado, segwit, segwit nativo)?

¡Absolutamente!

Cada tipo de dirección maneja la generación de transacciones de forma ligeramente diferente, pero todos son interoperables entre sí a nivel de protocolo. Si se encuentra con un problema en el que un tipo de dirección no se envía a otro, esto no es una limitación del código de bitcoin, sino del cliente.

Aún así, es posible que escuche algo como:

"Las direcciones heredadas no son compatibles con SegWit"

Esto simplemente significa que una dirección heredada no puede enviar una transacción SegWit. Cuando se trata de recibir , todo es interoperable. El tipo de transacción y si la dirección de recepción puede o no utilizar todos los beneficios de la transacción depende de la dirección de envío.

Dirección heredada

El formato de dirección original de Bitcoin, Pay-to-Pubkey Hash (P2PKH), genera una transacción utilizando un hash de la clave pública del destinatario. Si una dirección comienza con 1, es heredada. Todavía es de uso común debido a la simplicidad y la integración universal, y aunque P2PKH puede enviar a una dirección SegWit, la tarifa es un poco más alta porque las transacciones heredadas son un poco más grandes.

Dirección P2SH

Estas direcciones comienzan con un 3y están diseñadas para pagar el hash de la secuencia de comandos , agregando la funcionalidad básica de secuencias de comandos a las direcciones. La transacción tiene una lógica adicional que, en el caso de varias firmas, establece que se requieren varias firmas para autorizar la transacción. Siempre que todas las firmas requeridas estén en su lugar, cualquier dirección puede recibir una transacción desde esta dirección.

Si ha escuchado el término "SegWit no nativo" o se pregunta por qué SegWit se llama "SegWit nativo" es por esta dirección. Aunque la dirección de envío no es SegWit, se crea una transacción P2SH que contiene un "Pago para testigos-Pubkey Hash" dentro de ella. Esto imita el formato de SegWit, lo que permite que una dirección nativa de SegWit lo interprete, bueno... de forma nativa.

SegWit y Bech32

Bech32 es el formato de dirección nativo de SegWit y es más eficiente con el espacio de bloques. Una dirección Bech32 se puede identificar por su bc1prefijo. SegWit es un formato de transacción que divide ( Seg regates) una transacción en dos partes: una que contiene los datos de identificación de transacción estándar (a, desde, monto, firmas, etc.) y una parte con guión de esos datos (Testigo) que es 75% más pequeño en la cadena, entre otros beneficios. Dado que el testigo contiene, entre otras cosas, una "versión reducida" de los datos heredados, permite enviar una transacción de SegWit a una dirección heredada (sin costo-beneficio) o a una dirección de SegWit (como una transacción más económica que se basa solo en el testigo). ). Sin embargo, una dirección heredada no sabe cómo generar los datos testigo, por lo que no puede incluirlos en una transacción de SegWit y obtener los beneficios. Sin embargo, está bien, porque una dirección SegWit no necesita los datos testigo, por lo que una dirección heredada no tendrá problemas para enviar tokens a una dirección SegWit.

Beneficiándose completamente de SegWit

No importa qué billetera use, cualquier UTXO puede provenir de cualquier tipo de dirección. Para cualquier moneda en una dirección, la UTXO a la que llegó contiene los datos heredados, los datos testigo o ambos, según el tipo de transacción que se utilizó para enviar las monedas.

Si está utilizando una dirección Bech32 para enviar una transacción SegWit, todos sus beneficios se obtienen cuando se le envía un UTXO como una transacción SegWit, pero siempre se enviará de todos modos.

Transacciones de script mixto

Estas son transacciones en las que los UTXO que pueden provenir de diferentes tipos de direcciones se colocan en una sola transacción. También es una ilustración de lo que sucede cuando las monedas se envían a diferentes tipos de direcciones a lo largo de su ciclo de vida. Ejemplo:

1. Alice recibe 0,5 BTC en su billetera SegWit de la dirección heredada de Bob.
2. Alice recibe 0,5 BTC de Charlie que se enviaron mediante SegWit.
3. Alice envía una transacción de 1 BTC que utiliza transacciones SegWit heredadas y nativas a una dirección Bech32.

El resultado es una transacción SegWit, aunque no se beneficia por completo de la privacidad o la reducción de costos de transacción si todos los UTXO hubieran sido SegWit. Si se envió a una dirección heredada, cualquier movimiento posterior de las monedas será una transacción heredada, hasta que llegue a una dirección Bech32 que lo envíe como una transacción SegWit, momento en el que se convierte nuevamente en una transacción SegWit.

NOTA: Es posible que algunos clientes de billetera más antiguos, o aquellos que no son compatibles con SegWit, no reconozcan las versiones más nuevas de las direcciones como válidas y no le permitan enviarles: esta es una medida de precaución (en el código de la billetera, no en el código de bitcoin) para evitar que los usuarios de enviar a una dirección que no sea bitcoin.

Raíz principal -Update (Nov 2021)

La reciente actualización de Taproot agregó cambios de transacciones adicionales al permitir la firma de Schnorr además del tradicional algoritmo de firma digital de curva elíptica (ECDSA). Cuando se lanzó originalmente bitcoin, el algoritmo de Schnorr estaba bajo protección de patente. Hay muchos beneficios que vienen con el uso de Schnorr , lo más importante es la capacidad de agregar claves de firma. Si bien una firma múltiple P2SH incluye la clave pública y la firma de cada una de las partes, Schnorr permite agregar las claves, lo que proporciona privacidad y un cálculo más sencillo para los nodos.

Dado que la clave agregada todavía se usa para crear un UTXO firmado con las entradas y salidas necesarias, ¡incluso un nuevo algoritmo es compatible con todos los clientes de bitcoin existentes!

No hay restricciones para enviar desde cualquier tipo de salidas a cualquier tipo de dirección en el protocolo de Bitcoin, pero es posible que algunas billeteras más antiguas no admitan el envío a tipos de direcciones más nuevos.

Echemos un vistazo más de cerca a lo que sucede cuando se realiza una transacción de Bitcoin:

• El destinatario elige una dirección en la que le gustaría recibir los fondos. Este será un formato de dirección del que su billetera sabrá cómo gastar fondos. Es de interés del destinatario elegir un formato de dirección más eficiente para ahorrar costos al gastar los fondos que recibirán más adelante.
• El remitente elige las entradas que quiere gastar. Los scripts de entrada están grabados en piedra por el tipo de dirección en la que se recibieron estos resultados antes. Sin embargo, se incentiva al remitente a elegir un tipo de dirección eficiente para su cambio de salida para ahorrar costos futuros.
• Es posible que el software de billetera más antiguo no pueda enviar a tipos de direcciones más nuevos. Específicamente, las direcciones nativas de segwit solo obtuvieron un estándar de dirección en marzo de 2017 ( BIP-173 ), y no todas las billeteras admiten el envío a estas direcciones todavía. En ese caso, el remitente debe pedirle al receptor que proporcione una dirección de segwit envuelta. Todas las billeteras deberían poder enviar a direcciones de segwit envueltas, ya que utilizan el estándar de dirección Pay to Script Hash (P2SH, BIP-16 ) que se introdujo en 2012.

En cualquier caso, los problemas con el envío a cualquier tipo de dirección específica se deben a la falta de funcionalidad en la billetera del remitente y no están relacionados de ninguna manera con los tipos de entrada utilizados.

A nivel de protocolo, todos son compatibles. Las transacciones pueden pasar cualquiera de ellos, y enviar a cualquiera de ellos.

Por supuesto, el software de billetera puede tener restricciones, pero generalmente no se trata de combinaciones. Por ejemplo, es posible que algunas billeteras no puedan generar una dirección p2sh-segwit para recibir o no puedan enviar a bech32. Sin embargo, no he oído hablar de software que impone restricciones sobre a dónde puede enviar en función de lo que se gasta, por ejemplo.

¿Es posible enviar transacciones de ida y vuelta entre los 3 tipos de direcciones (heredada, segwit, native segwit-bech32)?

Sí, claro. Es totalmente normal a nivel de protocolo.

Al igual que lo que Murch había dicho:

No hay restricciones para enviar desde cualquier tipo de salidas a cualquier tipo de dirección en el protocolo Bitcoin

La capacidad de limitar dónde podría ir el bitcoin "desbloqueado" (UTXO) es en realidad una característica faltante de bitcoin, llamada "pactos". Actualmente, las personas solo pueden usar trucos como transacciones prefirmadas con tiempo limitado para lograr objetivos similares. En el futuro, tal vez esto podría hacerse de una manera más intuitiva y poderosa.

Sin embargo, es posible que una billetera antigua (o un intercambio de criptomonedas con un equipo técnico perezoso/conservador) no pueda reconocer las direcciones bech32 nativas, por lo que no podrá enviar bitcoins desde una billetera tan antigua (o retirar dinero de una billetera tan perezosa). intercambio de criptomonedas) a una dirección bech32 SegWit nativa; ese es el único inconveniente significativo.

Para resumir:

Tarifa de minero : (más cara) 1-dirección heredada de inicio> 3-iniciar p2sh-segwit> bc1-iniciar bech32 (más barato)

Compatibilidad : (más compatible) 1 dirección heredada de inicio ≈ 3 p2sh-segwit de inicio (casi tan compatible como la heredada) > bc1-bech32 de inicio (problema potencial de compatibilidad/interoperabilidad)

Además, obviamente no puede generar ninguna dirección de SegWit con una billetera antigua sin ningún soporte de SegWit, por lo que no puede recibir bitcoins con ninguna dirección de SegWit usando dicha billetera; la solución a este problema es simple: simplemente actualice la billetera a Versión compatible con SegWit, o cambie a otra billetera con el soporte adecuado de SegWit.

Si alguien que es demasiado terco para actualizar/cambiar su billetera, no importa, porque (1) aún puede darle una dirección SegWit de 3 inicios; (2) puede enviar transacciones de un lado a otro entre los 3 tipos de direcciones utilizando una billetera con el soporte adecuado de SegWit.

(Una transacción que envía bitcoins desde) Las direcciones heredadas P2PKH de 1 inicio no disfrutan de los descuentos de SegWit, por lo que tiene las tarifas mineras más caras entre esos tres tipos de direcciones. Su recuento de bytes virtuales es exactamente el mismo que el recuento de bytes real/en línea.

(Una transacción que envía bitcoins desde) la dirección Bech32 SegWit nativa que comienza en bc1 tiene el menor tamaño de datos (recuento de bytes), ya sea virtual (vByte) o real/en línea, por lo que disfruta de las tarifas de minero más baratas.

De hecho, SegWit (v0) no reduce tanto el tamaño de los datos de transacción, su tarifa de minero barata es principalmente un descuento artificial. Sin embargo, las transacciones de SegWit tienen una ventaja técnica sobre las heredadas, como evitar el problema del sighash cuadrático .

(Una transacción que envía bitcoins desde) la dirección SegWit "compatible" envuelta en P2SH de 3 inicios en realidad consume más bytes que una dirección heredada de 1 inicio (principalmente porque el "hash de script" de P2SH consume 20 bytes), sin embargo, todavía tiene un minero más barato tarifa que 1 dirección heredada de inicio debido a los descuentos.

Una dirección de inicio 3 es P2SH , que fue creada por Gavin Andresen en una etapa muy temprana de la historia de bitcoin (2012), por lo que ahora es muy improbable ver una billetera que no reconozca las direcciones P2SH de inicio 3.

SegWit utiliza P2SH para "envolver" su guión especial "cualquiera puede gastar" .

P2SH en realidad puede "envolver" cualquier cosa. Su uso típico ha sido multi-sig durante bastante tiempo, mucho antes que SegWit.

Cuando una billetera antigua envía bitcoins a una dirección de inicio de 3, al pagador no le importa en absoluto qué tipo de cosas están "envueltas dentro" de esa dirección. Puede ser un multi-sig heredado, SegWit o cualquier otro, lo que sea, no importa.

(¡Incluso podría ser una dirección totalmente indiscutible!)

Entonces es responsabilidad del beneficiario asegurarse de que todavía pueda gastar los bitcoins en esa dirección de 3 puntos de partida.

Entonces, ¿qué es "cualquiera puede gastar"?

Las versiones antiguas (anteriores a la 0.13) de los nodos completos de bitcoin no saben nada sobre SegWit, por supuesto, por lo que obviamente no pueden validar las transacciones de SegWit (o los bloques que contienen transacciones de SegWit) de acuerdo con las reglas de SegWit recién definidas.

Sin embargo, todavía aceptarían bloques SegWit como si esos bloques fueran válidos, a pesar de que no pueden validarlos por completo: la compatibilidad con versiones anteriores (generalmente llamada "compatibilidad con versiones anteriores" por muchos desarrolladores) aún se conserva, en el sentido de que los nodos antiguos que no son SegWit-aware todavía puede funcionar normalmente.

En cuanto a las transacciones de SegWit , esos nodos antiguos no aceptarán/reenviarán/minarán ninguna transacción de SegWit (excepto el envío a una dirección de SegWit envuelta en P2SH de 3 inicios). Solo aceptarían transacciones SegWit confirmadas , en otras palabras, solo bloques SegWit. Por lo tanto, si desea romper las reglas de SegWit, al menos debe convertirse en un minero (individual) usted mismo, un intento casi gratuito como enviar una transacción de "robo" no válida desde algunas direcciones de SegWit no funcionará en absoluto. (Aquí viene la desventaja menor de SegWit de que los nodos completos antiguos que no son conscientes de SegWit no pueden ver las transacciones de SegWit de confirmación 0)

SegWit fue cuidadosamente diseñado para lograr esto. En realidad es bastante similar a lo que había hecho P2SH.

Hay un concepto llamado "reglas de estandarización" en bitcoin, que tales reglas son solo autodisciplina, por lo que solo restringen el comportamiento de un nodo completo en sí . Las "reglas de estandarización" no se aplican a la cadena de bloques, que contiene bloques extraídos por varios tipos de otros nodos.

Solo se aplican "reglas de validez" o "reglas de consenso" a la cadena de bloques.

La dirección de SegWit en realidad significa que "cualquiera puede gastar bitcoins en esta dirección" de acuerdo con las reglas de validez anteriores , por lo que los nodos antiguos aún aceptarían bloques de SegWit. (Por lo tanto, de hecho existe un riesgo teórico e inevitable de que se produzca una división de la cadena, si algunos mineros maliciosos insistieran en minar/extender una cadena de bloques no válida "robando" direcciones de SegWit; sin embargo, aún sería claramente distinguible entre la cadena válida y la no válida cadena Los nuevos nodos conscientes de SegWit solo aceptarían la cadena válida) Viola las reglas de estandarización anteriores , por lo que los nodos antiguos no extraerán ninguna transacción de SegWit en sus propios bloques.

De acuerdo con las nuevas reglas de validez , gastar bitcoins desde la dirección SegWit (normalmente) debe proporcionar firmas válidas, sin firmas válidas sería una transacción no válida, por lo que los nuevos nodos rechazarían una transacción no válida o un bloque (por lo tanto, no válido). incluyendo cualquier transacción inválida. Por supuesto, los nuevos nodos tampoco extraerán ninguna transacción no válida en sus propios bloques. Sin embargo, de acuerdo con las nuevas reglas de estandarización , las transacciones SegWit (válidas) también son estándar (no violan las nuevas reglas de estandarización), por lo que los nuevos nodos felizmente extraerían transacciones SegWit válidas en sus propios bloques.