Mythbusting: El tiempo de confirmación de 10 min hace que Bitcoin sea inadecuado como método de pago

Escrito por: Cain

Also available in -English- -Portuguese-

Los partidarios de Bitcoin Core (BTC) dicen que Bitcoin no está destinado a comprar café. Argumentan que el propósito de Bitcoin es ser una reserva de valor, no una moneda. El oro digital, dicen, no el efectivo digital.

Los partidarios de Bitcoin Cash (BCH), por otro lado, creen que Bitcoin está destinado a ser utilizado como un medio de intercambio, así como una reserva de valor. Los defensores del BCH quieren que su moneda se use para pagar el café, las comidas, los viajes en taxi y cualquier otra cosa que puedas imaginar.

Entonces, ¿por qué la diferencia de opinión?

Para responder esta pregunta correctamente, debemos explicar algunas de las diferencias técnicas entre BTC y BCH. El 1 de agosto de 2017, la red de Bitcoin se bifurcó y dio a luz a Bitcoin Cash. Esto significa que tanto BTC como BCH comparten el mismo historial de transacciones idénticas desde el bloque de génesis hasta la altura del bloque 478557, pero cualquier transacción realizada después de eso no se comparte entre las dos redes. El siguiente diagrama es un buen resumen de los principales forks (bifurcaciones) que han sucedido a lo largo de los años:

Además de tener diferentes conjuntos de transacciones después de agosto de 2017, la principal diferencia real entre BTC y BCH es que, si bien BTC mantuvo su límite de tamaño de bloque de 1 MB, BCH aumentó este límite de 1 MB a 8 MB inicialmente, y luego a 32 MB, que es donde se encuentra actualmente.

Entonces, ¿por qué es tan importante el tamaño del bloque? La forma en que funciona Bitcoin es que cuando las transacciones se transmiten por primera vez a la red, permanecen "sin confirmar" y se sientan en una especie de "área de espera" llamada mempool hasta que se incluyen en un bloque minado. Solo después de que se incluyen en un bloque se "confirman" y, por lo tanto, dejan el mempool. Cuantos más bloques se extraen en la parte superior del bloque en el que se incluye una transacción, es menos probable que la transacción pueda revertirse. Esta es la razón por la cual los intercambios generalmente requieren varias "confirmaciones" antes de acreditarle con su Bitcoin.

Dado que BTC tiene bloques más pequeños y, por el momento, más transacciones, es posible que no haya suficiente espacio en el siguiente bloque para todas las transacciones que esperan confirmar. Esto significa que cualquier transacción restante tendrá que esperar un bloque que tenga espacio para incluirlas. Como resultado, los desarrolladores de Bitcoin Core crearon un "mercado de tarifas" mediante el cual las transacciones con las tarifas más altas tendrían prioridad sobre las transacciones de tarifas más bajas. Implementaron un nuevo software conocido como Reemplazar por tarifa (RBF). De esta manera, si envía una transacción BTC durante un período de tráfico de red pesado y la transacción no se confirma, puede enviar las mismas monedas en otra transacción pero con una tarifa más alta con la esperanza de que ingrese en un bloque más rápido.

Desafortunadamente, RBF viene con una falla fatal que esencialmente mata el caso de uso de BTC como efectivo. Esto se debe a que RBF facilita a las personas realizar lo que se llama doble gasto en la red BTC. Digamos que estás en una cafetería y pides café. Realiza una transacción, que es detectada por el sistema de punto de venta, y se le entrega inmediatamente su bebida. Luego, una vez que sale de la tienda, envía una nueva transacción con las mismas monedas pero con una tarifa más alta, no a la dirección de la billetera del café, sino a una que usted mismo controla. Debido a RBF, la transacción de tarifa más alta es la que se incluye en el siguiente bloque, y la transacción de tarifa más baja original se elimina por completo. El café nunca recibe los fondos y puedes quedarte con tu café. Esto es lo que se conoce como doble gasto. Mire el video a continuación para ver qué tan fácilmente se puede explotar en BTC:

Como acaba de presenciar, debido a la activación de RBF, BTC ya no es adecuado como método de pago en efectivo. Un atacante podría fácilmente gastar el doble de un comerciante prácticamente a voluntad. Si es un comerciante que acepta BTC, sería aconsejable esperar al menos una confirmación para asegurarse de que sus fondos estén asegurados, aunque, por supuesto, nadie está dispuesto a sentarse en una tienda durante diez minutos (o más) solo esperando un pago para pasar.

Pero hay buenas noticias. Bitcoin Cash conserva el caso de uso de Bitcoin como efectivo porque BCH no tiene RBF. En cambio, la red sigue la regla de "primer visto" donde los mineros aceptan la primera transacción que ven en lugar de la transacción con la tarifa más alta. Esto significa que intentar realizar con éxito un doble gasto en la red BCH es significativamente más difícil. Los comerciantes pueden aceptar transacciones que aún no se han confirmado en un bloque de manera relativamente segura, ya que no tienen que preocuparse de que los clientes abandonen la tienda y realicen una transacción con una tarifa más alta para reemplazar la que acaban de hacer. Las transacciones que aún no se han confirmado se conocen como transacciones de confirmación cero (0-conf). Con 0-conf habilitado, los usuarios pueden enviar y recibir BCH al instante sin tener que esperar a que se confirme la transacción en un bloque.

Pero espera, ¿qué pasa con las estadísticas en doublespend.cash? Buena pregunta.

Técnicamente hablando, todavía es posible realizar una doble inversión en BCH. Es mucho más difícil. Debería enviar dos transacciones prácticamente al mismo tiempo y esperar que la transacción fraudulenta termine siendo la que se confirma. Pero si el intento de transacción de doble gasto se envía incluso un par de segundos después del original, las posibilidades de que se incluya en un bloque disminuyen drásticamente debido a que la primera transacción probablemente ya se ha propagado a través de la red.

Aquí hay un tweet del creador de doublespend.cash que establece que cuando un intento de doble gasto no se transmite simultáneamente, las posibilidades de éxito eran solo 1 de 3992.

Por lo tanto, el sistema de punto de venta de un comerciante solo tiene que esperar un par de segundos para verificar la red y asegurarse de que otra transacción con las mismas monedas no se transmitió posteriormente. Si se ve otra transacción, simplemente pueden rechazar la venta. Si está vendiendo tazas de café por $ 5, ¿está dispuesto a arriesgarse a que un mal actor tenga una probabilidad de 1 de cada 4,000 (.025%) de estafarlo? Suponiendo que la mayoría de sus clientes son personas normales que no intentan estafarlo con un software altamente técnico, la probabilidad de ser engañado será de órdenes de magnitud inferiores al 0,025%.

Quizás esto no es lo que querías escuchar. Quizás lo que quería escuchar es que 0-conf en BCH es absolutamente seguro, pero la realidad es que nunca puede estar 100% seguro de que cualquier transacción sea segura. Incluso con transacciones confirmadas, es teóricamente posible que la red se pueda revertir, deshaciendo bloques previamente extraídos. Por lo tanto, la verdadera pregunta es ¿cuánto riesgo está dispuesto a aceptar en su negocio? Si está tratando de vender una casa por $ 1 millón, probablemente sea una buena idea esperar varias confirmaciones antes de finalizar la venta. Pero si está hablando de vender tazas de café, las transacciones instantáneas 0-conf no deberían presentar ningún riesgo.

Dicho esto, los desarrolladores del protocolo BCH continúan trabajando en formas de mejorar la seguridad 0-conf para que, en el futuro, el riesgo de aceptar pagos no confirmados sea aún menor.

En resumen, si bien el tiempo de confirmación de 10 minutos puede hacer que BTC sea inadecuado como método de pago en efectivo, las mismas reglas no se aplican a BCH, que se creó para usarse como efectivo para pagos diarios, como una reserva de valor, y un día, como una unidad de cuenta.

Gracias por leer.

Gracias a la gente en el canal de telegram Coinspice por ayudarme a responder algunas de mis preguntas sobre 0-conf y doble gasto, así como al ilustre Jonald Fyookball que fue lo suficientemente generoso como para ofrecer leer mi presentación y asi asegurarse de que no hubieran errores evidentes.

Creditos: Cain