Transacción entre cadenas sin confianza con Bitcoin: ¿hay algún defecto?

Digamos que Alice quiere enviar a Bob 1 BTC y, a cambio, Bob le enviará a Alice 1 ETH.

La dirección de Bitcoin de Alice es BTC_A y la dirección de Ethereum de Alice es ETH_A. Asimismo, Bob posee las direcciones BTC_B y ETH_B.

BTC_B es una dirección "nueva", sin ningún tipo de historial de transacciones.

Alice crea una sola transacción para ETH_A que contiene un poco más de la cantidad que enviará a Bob y la transmite. El hash de transacción de esto se llamará tx1.

Bob espera a que se confirme esa transacción y luego crea un contrato inteligente con los siguientes parámetros (inmutables):

inputaddr, establecido en BTC_A

inputtx, establecido en tx1_txhash desde arriba

dirección de salida, establecido en BTC_B

minfee, establecida en una tarifa/byte de Bitcoin "razonable", según las condiciones actuales de la red

tiempo de espera, establecido en la cantidad de segundos después de los cuales se confirmará una transacción con minfee en la cadena de bloques BTC, además de un margen significativo para la seguridad

val se establece en una cantidad que representa 1 BTC, o la cantidad que Alice le envíe a Bob

Bob también deposita 1 ETH en el contrato inteligente y no puede retirarlo

Alice envía una transacción, tx2, a la cadena de bloques de Bitcoin con las siguientes propiedades:

  • inputtx es su única entrada
  • outputaddr es su única dirección de salida
  • tarifa > tarifa mínima
  • firmado por BTC_A

También envía toda esta transacción al contrato inteligente, que verifica estas cuatro propiedades. Si se cumplen todos, anote el tiempo como txtime.

Bob monitoreará continuamente la cadena de bloques de Bitcoin, y si Alice intenta duplicar la transacción de entrada, enviará la transacción de doble gasto al contrato inteligente. El contrato inteligente verificará que esta transacción sea legítima y, si no es idéntica a la primera transacción que Alice envió anteriormente, reembolsará el ETH a ETH_B.

Bob también podrá retirar el ETH bloqueado si Alice no envía la transacción de BTC al contrato en un período de tiempo razonable.

Si ha pasado el tiempo de espera desde txtime y Bob no ha presentado prueba de un gasto doble, Alice puede retirar el ETH bloqueado a ETH_A cuando lo desee.

Esto parece el tipo de cosa que alguien ya habría ideado, pero no pude encontrar ningún otro ejemplo confiable de un intercambio BTC-ETH. ¿Hay un defecto fundamental en este sistema?

El problema con su enfoque es que puede enviar transacciones falsas al contrato y el contrato no puede verificar si fueron minadas o no en la cadena de bloques de bitcoin. Es posible que deba usar BTCRelay, pero está muy desactualizado.
@Ismael, ¿no puede Bob enviar esas transacciones ya que fueron firmadas por Alice y ahora son públicas?
La transacción de Bitcoin todavía tiene algunos problemas de maleabilidad, podría ser posible que B manipule tx2 de A y obtenga una transacción válida que tenga las mismas propiedades que tx2 pero no sean las mismas, por lo que parecerá que A está causando un gasto doble.
@Ismael Según lo que estoy leyendo en la wiki de Bitcoin, puede evitar la maleabilidad aceptando solo transacciones que se ajusten exactamente a las especificaciones, y parece que Lightning Network también se basa en transacciones no maleables.

Respuestas (1)

Ha sido implementado por Komodo .

También he desarrollado un contrato de intercambio atómico de cadena cruzada de muestra (para cadenas compatibles con BIP-199). Puedes ver el repositorio aquí

Ok, esa terminología "Intercambio atómico" es lo que he estado buscando. Parece que el proceso es algo similar.
Debe agregar más detalles a su respuesta; de lo contrario, es una respuesta de solo enlace y no brindan mucho valor si el enlace cambia en el futuro o el host desaparece.
Transacción entre cadenas sin confianza con Bitcoin: ¿hay algún defecto?
RespuestasAquíPolítica de privacidad1y, 0v