No entiendo por qué estoy leyendo que después de una bifurcación dura, las transacciones existentes estarían en ambas cadenas, pero las nuevas transacciones solo estarán en una u otra (dando como resultado 2 cadenas diferentes, por lo tanto, una altcoin). ¿Ni siquiera las transacciones nuevas terminarán finalmente en ambas cadenas?
A las transacciones no les importa el tamaño del bloque, por lo que ambas versiones deberían aceptarlas. Incluso si una cadena ya lo ha incluido, el software para la segunda cadena no se preocupará por la primera cadena, por lo que la segunda aún debería tener esas transacciones en su grupo, lo que resultará en que también se coloque en la segunda cadena.
No veo cómo esto dará como resultado 2 cadenas separadas... parece que ambas cadenas siempre tendrán aproximadamente las mismas transacciones exactas, solo posiblemente en un orden diferente y agrupadas en diferentes bloques.
La única excepción a esto que se me ocurre es si se intenta un doble gasto. Entonces es posible que una de las cadenas acepte una de las transacciones de doble gasto y la otra cadena acepte la otra.
Pero de lo contrario, no veo cómo habría una diferencia.
Esto realmente sucedió en Ethereum cuando tenían una bifurcación dura. Si una transacción es válida en ambas cadenas (gasta salidas antes de la bifurcación) y se propaga a ambas cadenas, entonces sí, no hay razón para que no se agregue a los bloques en ambas cadenas.
Sin embargo, todavía hay dos cadenas. Cuando se agrega la misma transacción a ambas cadenas, se incluyen en dos bloques separados; un bloque de la cadena A y un bloque de la cadena B. Los resultados de tales transacciones solo se pueden gastar en su cadena correspondiente, aunque la transacción que los creó sea idéntica.
Digamos que tenemos una cadena que se bifurca a la altura del bloque 100. Ahora tenemos la cadena A y la cadena B. Se crea una transacción utilizando UTXO desde el bloque a la altura 90 y se propaga en ambas redes. La cadena A lo incluye en su bloque a la altura 108, y la cadena B lo incluye en su bloque a la altura 110 (aunque también podría ser 108 en su cadena). Ahora se crea una nueva transacción gastando un UTXO de la primera transacción en la cadena A. Esa segunda transacción solo puede propagarse en la cadena B si gasta exclusivamente de UTXO en ambas cadenas. Esto se vuelve cada vez menos probable con el tiempo.
Dado que la mayoría de las transacciones nuevas en una cadena solo son válidas para esa cadena, no pasará mucho tiempo antes de que las dos cadenas apenas tengan transacciones en común.
También es importante tener en cuenta que los clientes de bitcoin desconectarán las conexiones con los clientes que propagan bloques de la otra cadena. Esto ayudará a segregar la red y evitará que las transacciones se propaguen en ambas cadenas, incluso cuando sean válidas en ambas. Podría haber entidades maliciosas que "puenten" las dos redes, buscando transacciones que sean válidas en ambas, pero no hay ningún incentivo real para ese tipo de mal comportamiento.
Hagamos un diagrama de un ejemplo de cadena de bloques de bifurcación dura:
A <-- B <-- C <-- D (current consensus rules chain, "original chain")
^---- C' <-- D' (new consensus rules chain, "new chain")
Si recibió una salida de transacción en el bloque A o B, podría gastarla tanto en la cadena original como en la nueva cadena[*]. Cómo funcionaría eso depende mucho de si la nueva cadena incluye protección de repetición.
La nueva cadena puede requerir opcionalmente protección de reproducción, lo que probablemente sería un cambio en los datos utilizados para crear la firma de la transacción. Por ejemplo, normalmente una firma de transacción firma un hash del identificador de las entradas que se gastan, así como de todas las salidas; para una bifurcación dura, esto podría cambiarse para requerir que el hash de la firma incluya adicionalmente el valor "Hard Fork #123". Esto tendría los siguientes resultados:
La cadena anterior no aceptaría ninguna transacción realizada para la nueva cadena porque no intentaría calcular el hash de la firma con los datos adicionales de "Hard Fork #123", por lo que todas las firmas realizadas para la nueva cadena parecerían inválidas.
La nueva cadena no aceptaría ninguna transacción realizada para la cadena anterior porque faltarían los datos requeridos de "Hard Fork #123".
Para la mayoría de las billeteras (probablemente todas), agregar "Hard Fork #123" a los datos utilizados para crear el hash de la firma sería técnicamente fácil, pero requiere que el autor de la billetera admita la bifurcación y que todos los usuarios actualicen antes de la bifurcación. Más difícil (dependiendo de la billetera) sería admitir ambos formatos de firma y quizás permitir que el usuario elija entre ellos. Aún así, me imagino que no es demasiado difícil.
Sin embargo, la mayoría de las bifurcaciones duras propuestas para Bitcoin no incluyen esta ni ninguna otra protección de reproducción directa. Esto probablemente se deba a que sus proponentes piensan que habrá menos posibilidades de adopción si los desarrolladores y usuarios tienen que tomar alguna medida para usar la bifurcación dura.
Curiosamente, la versión 0.1 original del protocolo Bitcoin incluía tres códigos de operación ( OP_VER, OP_VERIF, y OP_VERNOTIF) que podían usarse para la protección de repetición durante una bifurcación dura al permitirle especificar qué reglas debían seguirse para gastar su transacción en diferentes VERsiones del protocolo. .
Desafortunadamente, el diseño no funcionó y Satoshi Nakamoto eliminó los códigos de operación del protocolo. Además de proporcionar protección de reproducción después de una bifurcación dura, podrían usarse para causar un tipo de bifurcación dura llamada falla de consenso . (Y, si está siguiendo el drama actual, no ha escapado a la diversión de algunas personas que el primer protocolo de Bitcoin permitía que un hard fork fuera activado por un VER).
Entonces, si la protección contra reproducción está disponible, podría gastar una salida del bloque A o del bloque B en cualquier cadena, pero tendría que firmar la transacción de manera diferente para cada cadena, asegurándose de poder enviar fondos en la cadena original a Alice y los fondos en la nueva cadena a Bob.
Sin la protección de reproducción, debe enviar los fondos en ambas cadenas al mismo tiempo porque cualquier transacción que cree será válida en ambas cadenas[*]. Sin embargo, hay formas de crear transacciones que solo serán válidas en una cadena, incluso si la protección de reproducción no está disponible; simplemente son más difíciles:
Usando monedas coinbase: los bloques C (cadena original) y C' (cadena nueva) tienen diferentes transacciones coinbase. (Una transacción coinbase es la transacción especial en un bloque que le paga al minero por crear ese bloque). Estas transacciones solo son válidas en su cadena particular, y cualquier transacción que descienda de ellas también es válida solo en su cadena particular.
Entonces, si es un minero o conoce a un minero, solo tiene que mezclar al menos 1 satoshi de ellos con su gasto del bloque A y su transacción tendrá protección de repetición ad hoc.
Sin embargo, hay dos problemas con esto: (1) necesita conocer a un minero que esté dispuesto a ayudarlo y (2) las transacciones de base de monedas no se pueden gastar por 100 bloques [*], por lo que tendrá que esperar un tiempo después de la bifurcación dura antes de que pudieras empezar a gastar.
Transacciones en conflicto: si crea dos transacciones diferentes y las envía a las dos cadenas de bloques diferentes, es posible (pero no garantizado) que se confirme una transacción en el bloque C y una transacción en el bloque C'.
Mientras los bloques C y C' sigan siendo parte de sus respectivas cadenas de bloques, cualquier transacción que gaste su transacción solo puede ser parte de sus respectivas cadenas de bloques.
Dado que no hay garantía de que pueda dividir monedas de esta manera, generalmente es una buena idea enviarse ambas transacciones por separado para que no haya forma de perder dinero más allá de las tarifas de transacción. Además, hay una forma de aumentar las posibilidades de que se dividan las monedas:
En la cadena con la altura de bloque más alta, gaste sus monedas usando nLockTime para apuntar a la altura de bloque actual.
Cuando se confirme la transacción anterior, gaste sus monedas en la otra cadena sin nLockTime.
Suponiendo que las diferentes cadenas tengan incluso una modesta diferencia de altura, esto funciona porque su transacción nLockTime solo es inicialmente válida en la cadena de mayor altura, por lo que no se puede agregar inmediatamente a la cadena de menor altura. (Crédito: Escuché por primera vez de un método como este de Peter Todd; no sé si él lo originó, ni si este es exactamente el método en el que estaba pensando; tuve que adivinar cómo funcionaría de él) simplemente diciendo "usar nLockTime".)
Las bifurcaciones duras, especialmente aquellas sin protección de repetición, rompen muchas suposiciones normales de las billeteras de Bitcoin. Como tal, existe un riesgo significativo de que pierda dinero si gasta o acepta bitcoins durante una bifurcación dura en curso. Por favor tenga cuidado.
[*] Las bifurcaciones duras pueden cambiar cualquier parte del sistema, por lo que las generalizaciones hechas en esta publicación pueden no aplicarse a todos los casos. Sin embargo, he tratado de hacerlos aplicables a la mayoría de las bifurcaciones duras propuestas que solo cambian algunas cosas, como el tamaño/peso máximo de bloque perpetuamente debatido.
nLockTimetransacción, puede gastar el dinero en la cadena con las tarifas más bajas y luego gastarlo dos veces con una tarifa más alta en la otra cadena.
muro
Jestin
Jestin
Juan rojo