LocalCryptos lanza los intercambios con Bitcoin Cash como su 5ta cripto

Ahora los usuarios podrán comprar y vender Bitcoin Cash (BCH) en el cripto mercado peer-to-peer sin custodia más popular.

Ha pasado casi un año desde que agregamos una nueva criptomoneda a LocalCryptos, y muchos de ustedes han estado pidiendo Bitcoin Cash como siguiente ingrediente a nuestra fórmula sin custodia. La espera ha terminado.

Desde hoy, los intercambios peer-to-peer de Bitcoin Cash están disponibles en LocalCryptos.

¿Como funcionará el contrato de garantía sin custodia en Bitcoin Cash?

Bitcoin Cash es una bifurcación de BTC, lo que significa que tiene capacidades de contrato inteligente similares al “Bitcoin script”. A diferencia de nuestros scripts de garantía sin custodia para Bitcoin, Litecoin y Dash, LocalCryptos aprovecha el op-code “OP_CHECKDATASIG, el cual está disponible únicamente en las transacciones de Bitcoin Cash.

Un usuario regular no va a notar la diferencia entre este nuevo tipo de contrato de garantía, pues el resultado final es virtualmente idéntico al script de garantía sin custodia de BTC de LocalCryptos. No obstante, desde el punto de vista de un programador, el script P2SH sin custodia de Bitcoin Cash es más simplista e intuitivo, e incluso trae algunas ventajas.

Al igual que todos los contratos en LocalCryptos, es técnicamente imposible para nosotros gastar los BCH en garantía. Nosotros sólo intervenimos cuando hay una disputa por un pago, y una vez dentro del conflicto, sólo podemos permitir que el BCH sea redimido por el comprador o el vendedor. Clic aquí para aprender más sobre la magia criptográfica que hace esto posible.

Por supuesto, tu cartera Bitcoin Cash en LocalCryptos es también auto-custodia. Tus claves—tus criptos. Los desarrolladores pueden ver nuestras plantillas de Script de Bitcoin Cash al final de este anuncio.

Algunos datos sobre Bitcoin Cash:

  • Bitcoin Cash (BCH) nació en 2017 de una bifurcación de Bitcoin.
  • Fue creada por la necesidad de tener una variante de Bitcoin que procesara una mayor cantidad de transacciones por bloque lo cual, según sus promotores, requeriría incrementar el tamaño de los bloques de la blockchain.
  • Como resultado de este acercamiento al problema de escalabilidad, Bitcoin Cash no tiene soporte para transacciones Segregated Witness (a diferencia de Bitcoin y Litecoin).
  • A pesar de las diferencias, ambas monedas comparten muchas similitudes — ambas se minan bajo el algoritmo de consenso Proof-of-Work, su suministro total de monedas está limitado a 21 millones, y ambas soportan direcciones pay-to-public-key-hash (P2PKH) and pay-to-script-hash (P2SH).
  • La comisión por transacción promedio de Bitcoin Cash suele ser de menos de 1¢ — ¡prácticamente gratis!

Cómo funciona el contrato de garantía (escrow) sin custodia de Bitcoin Cash

Al igual que con los scripts sin custodia que hemos desarrollado para otras criptos, el código de nuestro script para Bitcoin Cash es abierto.

Este Script funciona de forma similar a una transacción multifirma de Bitcoin, con la excepción de que las partes involucradas no necesitan determinar cómo y cuándo las transacciones de salida (outputs) de Bitcoin Cash son gastadas. El oráculo — que puede ser el vendedor, comprador o el árbitro, dependiendo de las circunstancias de la operación — no tiene la capacidad de imponer condiciones en la transacción, a diferencia de las carteras multifirma tradicionales.

Esto se debe a que, con una cartera multifirma tradicional, todas las partes deben firmar una transacción completa incluyendo todas sus salidas y entradas (inputs), mientras que con una transacción escrow sin custodia que utilice el op-code OP_CHECKDATASIG, el oráculo simplemente necesita otorgarle al ganador una firma que pueda usar en cualquier momento para desbloquear los BCH como mejor le parezca.

Este tipo de mecanismo de garantía on-chain le otorga tanto al comprador como al vendedor la habilidad de intercambiar sin permisos, y al árbitro la capacidad de intervenir como un mediador no custodio en caso de una disputa.

El depósito del vendedor en el contrato de garantía

Para mover los Bitcoin Cash al contrato, el vendedor genera una transacción con dos salidas. Una de ellas es el depósito en garantía para el comprador y la otra es una comisión reembolsable. Si el intercambio fracasa, la comisión puede ser recuperada por el vendedor.

En intercambios ordinarios, el vendedor permitirá al comprador gastar la transacción de salida del contrato de garantía. Esto no requiere de nuestra intervención. De forma similar, si el comprador elige cancelar el intercambio por su cuenta, el vendedor puede gastar dicha salida sin nuestra ayuda. El primer escenario es una “liberación” y el segundo un “retorno”.

En el caso de una disputa, un árbitro intervendrá y actuará como mediador. Por diseño, el árbitro sólo puede permitir a una de las partes gastar la salida, es decir, tener el control sobre los fondos disputados. El script de la comisión permite a LocalCryptos colectar una comisión después de liberado el escrow, o al vendedor reclamar un reembolso si el intercambio fue infructuoso.

Plantilla de un output del escrow

OP_DUP # Necesitamos usar el byte de nuevo después
# Obtener las claves públicas hasheadas que necesitamos para compararlas (las nuestras, y las del oráculo)
OP_1
OP_EQUAL
OP_IF
  <hash160(SellerPubKey)> # Clave pública del oráculo
  <hash160(BuyerPubKey)> # Clave pública de quien gasta
OP_ELSE
  OP_DUP
  OP_2 # = liberar desde el árbitro
  OP_EQUAL
  OP_IF
    <hash160(ArbPubKey)> # Clave pública del oráculo
    <hash160(BuyerPubKey)> # Clave pública de quien gasta
  OP_ELSE
    OP_DUP
    OP_3 # = regresar desde el comprador
    OP_EQUAL
    OP_IF
      <hash160(BuyerPubKey)> # Clave pública del oráculo
      <hash160(SellerPubKey)> # Clave pública de quien gasta
    OP_ELSE
      OP_DUP
      OP_4 # = regresar desde el árbitro
      OP_EQUALVERIFY # debe ser cierto, de lo contrario el mensaje es desconocido
      <hash160(ArbPubKey)> # Clave pública del oráculo
      <hash160(SellerPubKey)> # Clave pública de quien gasta
    OP_ENDIF
  OP_ENDIF
OP_ENDIF
# Colocar las claves públicas hasheadas en el alt stack
OP_TOALTSTACK
OP_TOALTSTACK # El stack es reseteado efectivamente a la entrada (input)
# En el alt stack tenemos: [ hash160(SpenderPubKey), hash160(OraclePubKey) ]
<EscrowKey> # Anexar el nonce a la clave del escrow para hacer el mensaje
OP_CAT # El stack es [ ..., <OraclePubKey>, <0x01 || EscrowKey> ]
OP_SWAP # Usar esto más tarde; verificar el hash de la clave pública del oráculo primero
OP_DUP
OP_HASH160
OP_FROMALTSTACK # Tomar la clave pública hasheada del alt stack
OP_EQUALVERIFY # Se verifica la clave pública; ahora verificar la firma del oráculo
OP_CHECKDATASIGVERIFY # Ahora verificar al emisor
OP_DUP
OP_HASH160
OP_FROMALTSTACK
OP_EQUALVERIFY
OP_CHECKSIG

Plantilla de un output de comisión

Esta es la parte de la comisión del intercambio. Si el mismo es infructuoso, la comisión puede ser reclamada por el vendedor; en caso contrario, el output de comisión será recolectado por LocalCryptos.

OP_DEPTH # Contar el tamaño del stack
OP_2
OP_EQUAL # ¿El stack de inputs solo tiene dos ítems?
OP_IF # Si es cierto, esta es la comisión que reclamará el dueño; simple PKH
  OP_DUP
  OP_HASH160
  <hash160(ArbPubKey)>
  OP_EQUALVERIFY
  OP_CHECKSIG
OP_ELSE # El vendedor está gastando un escrow "retornado" (p.ej. cancelado)
  OP_DUP
  OP_3 # = retornar desde el comprador
  OP_EQUAL
  OP_IF
    <hash160(BuyerPubKey)> # Clave pública del oráculo
  OP_ELSE
    OP_DUP
    OP_4 # = retornar desde el árbitro
    OP_EQUALVERIFY # debe ser cierto, de lo contrario el mensaje es desconocido
    <hash160(ArbPubKey)> # Clave pública del oráculo
  OP_ENDIF
  <hash160(SellerPubKey)> # Clave pública de quien gasta
  # Colocar las claves públicas hasheadas en el alt stack
  OP_TOALTSTACK
  OP_TOALTSTACK # El stack es reseteado efectivamente a la entrada (input)
  # En el alt stack tenemos: [ hash160(SpenderPubKey), hash160(OraclePubKey) ]
  <EscrowKey> # Anexar el nonce a la clave del escrow para hacer el mensaje
  OP_CAT # El stack es [ ..., <OraclePubKey>, <0x01 || EscrowKey> ]
  OP_SWAP # Usar esto más tarde; verificar el hash de la clave pública del oráculo primero.
  OP_DUP
  OP_HASH160
  OP_FROMALTSTACK # Tomar la clave pública hasheada del alt stack
  OP_EQUALVERIFY # La clave pública se verifica; ahora verificar la firma del oráculo
  OP_CHECKDATASIGVERIFY #VerificarElEmisor
  OP_DUP
  OP_HASH160
  OP_FROMALTSTACK
  OP_EQUALVERIFY
  OP_CHECKSIG
OP_ENDIF

Firma del script

Para gastar un output del escrow, quien lo gasta debe proveer el scriptSig de su transacción de Bitcoin Cash:

<Sig> <SpenderPubKey> <OracleSignature> <OraclePubKey> <ActionByte>
# Ejemplo: <Sig> <OwnPubkey> <SignatureFromSeller> <SellerPubKey> OP_1
  1. <ActionByte> es un byte correspondiente con la situación que está siendo ejecutada.
    • 1: El escrow está siendo liberado por el vendedor
    • 2: El escrow está siendo liberador por el árbitro
    • 3: El escrow está siendo regresado por el comprador
    • 4: El escrow está siendo regresado por el árbitro
  2. <OraclePubKey> es la clave pública de la persona firmando el mensaje de liberación/retorno.
    • 1: <OraclePubKey> = <SellerPubKey>
    • 2: <OraclePubKey> = <ArbPubKey> (controlado por LocalCryptos)
    • 3: <OraclePubKey> = <BuyerPubKey>
    • 4: <OraclePubKey> = <ArbPubKey> (controlado por LocalCryptos)
  3. <OracleSignature> es una firma del oráculo de ECDSA(<ActionByte> || <EscrowKey>). El <EscrowKey> es único, de modo que la firma no puede ser reutilizada en otros escrows.
  4. <SpenderPubKey> es la clave pública del comprador si hay liberación, de lo contrario es la clave pública del vendedor.
  5. <Sig> es la firma de transacción de quien gasta.