¿Por que el doble gasto no se ha parchado?

[seoincorporation]

El doble gasto mejor conocido como 'Double spend' en Bitcoin es considerado una vulnerabilidad ya que con esta técnica la gente puede realizar ataques a servicios que validen tu saldo con cero confirmaciones.

El doble gasto consiste en enviar las mismas monedas a diferentes direcciones, la cadena de bloques validará las transacciones y una de ellas quedará verificada dentro de un bloque mientras que la otra se pierde en el limbo y nunca será confirmada.

Es una vulnerabilidad que se conoce desde un principio y hay muchas tesis sobre el tema. Y aquí la pregunta del millón:

¿Por que el double spend no ha sido parchado?

Podríamos pensar que la solución es tan simple como verificar que 'las entradas' no se encuentren gastadas antes de propagar la transacción, pero aquí el problema es que se podría propagar ambas transacciones desde diferentes locaciones así que esto no resuelve el problema.

Si algún día se encuentra una solución el beneficio sería inmenso ya que con esto los servicios podrían aceptar depósitos con cero confirmaciones.

[DdmrDdmr]

No sé si realmente hay manera de resolverlo de una manera a priori – en base a la mempool.  Dado que cada nodo puede tener diferentes recursos alocados (sobretodo RAM) para la gestión de la mempool, no está garantizado que una misma TX se encole en todos los nodos.
 
Si no está resuelto ya, entiendo que se asume como parte de cómo funciona bitcoin (son intentos de doble gasto, pero no doble gastos si no llegan a confirmarse e insertarse en la blockchain), aunque eso requiere conocer lo que se hace como emisor de pagos y receptor (cosa que no siempre sucede ni mucho menos).
 

El tipo de intento de doble gasto más común es el que se aprovecha del RBF como mecanismo. Recuerdo haber leído acerca de comercios que aceptan TXs con 0 confirmaciones siempre y cuando la TX no tenga el flag de RBF. Si no recuerdo mal, eran comercios donde los importes de los pagos eran bajos (tipo refrescos o por el estilo).

Por otro lado, precisamente el RBF, que juega a lomos del intento de doble gasto, seguro que nos ha sacado de más de un apuro para, precisamente, acelerar un pago que vemos va a tardar más de lo previsto o deseado. El RBF en el fondo juega con el doble gasto a favor del pagador, aunque puede ir en contra del receptor del pago si se cambia el destinatario del mismo, y el receptor original no espera a ver la TX confirmada.


Ver tipos potenciales de doble gasto (he visto unos citados que desconocía):
https://es.cointelegraph.com/explained/double-spend-or-double-spend-attack-in-bitcoin-myth-or-reality

[famososMuertos]

Colega, cuento viejo este, pero siempre importante mencionarle como el tema de la seguridad, y ese el punto, quizás la analogía que le conseguí una vez a ese tema en un P2P en persona fue que funciona como un billete falso, si, si no es lo mejor para explicar pero para una persona que tiene poco tiempo en bitcoin o de los que a veces tienen tiempo pero solo saben hacer send y mirar la wallet para check sus depósitos, funciona.

Es obvio que tu manejas en un nivel avanzado en el tema y como programador piensas esto debería ser solucionado, pero realmente con 1 confirmación funciona bien y no es la mejor salida, quizás sea mejor llamarle asì, una alternativa a una real solución, vamos algo de semántica.

Aunque algunos dicen que es un problema de usuario, de hecho como usuario debo esperar no 1 confirmaciòn para estar 100% seguro de mis bitcoin, pues para no dejarlo tipo condón (99% o menos) hay que meterle +2 confirmaciones. Listo. Espera tus confirmaciones.

Eso en el caso de entre usuarios sin malas intenciones o usuarios - empresas, pero hay sin duda casos "avanzados" en donde su mal intencionado uso puede traer serias consecuencias, pero son casos que resultan muy difíciles que sucedan y caemos con seguridad, en temas hashes y esas cosillas de programadores.

En todo caso como usuario yo uso el doble gasto, cuando puedo, asì que tampoco todos son villanos. 

Ah! los del billete, bueno si recibes un billete y tienes dudas, lo revisas bien o consultas a un amigo, pero dependiendo de la frecuencia usas un detector de billetes falsos y/o tu habilidad para reconocer los billetes falsos crece con el tiempo. Bueno con bitcoin ni amigo ni maquina 6 confirmaciones y listo.

[RandyWMizher]

No entiendo el problema.

En todas partes se dice a los usuarios que deben esperar a más de una confirmación/bloque para dar por buena una transacción. Dos es lo mínimo.

Para transacciones de cierta importancia se recomienda de hecho esperar 6 confirmaciones (eso es aproximadamente una hora, a 1 bloque cada 10 minutos.)

RandyWMizher

[seoincorporation]

...
Por otro lado, precisamente el RBF, que juega a lomos del intento de doble gasto, seguro que nos ha sacado de más de un apuro para, precisamente, acelerar un pago que vemos va a tardar más de lo previsto o deseado. El RBF en el fondo juega con el doble gasto a favor del pagador, aunque puede ir en contra del receptor del pago si se cambia el destinatario del mismo, y el receptor original no espera a ver la TX confirmada.

Creo que somos varios los que hemos salido de un apuro con RBF, sin embargo esta técnica lo unico que hace es cambiar el fee de la transacción mas no la direccion destino. Así que podríamos decir que es unaestrategia que aprovechó el Double Spend para bien.

...
Aunque algunos dicen que es un problema de usuario, de hecho como usuario debo esperar no 1 confirmaciòn para estar 100% seguro de mis bitcoin, pues para no dejarlo tipo condón (99% o menos) hay que meterle +2 confirmaciones. Listo. Espera tus confirmaciones.

Es importante mencionar que aunque la transacción tenga 1 confirmación aun así puede ser vulnerable a un double spend, pero para que esto pase es necesario un ataque del 51%. Mientras mas confirmaciones tiene la transacción es menor la probabilidad de éxito en un ataque del 51%.

No entiendo el problema.

En todas partes se dice a los usuarios que deben esperar a más de una confirmación/bloque para dar por buena una transacción. Dos es lo mínimo.

Para transacciones de cierta importancia se recomienda de hecho esperar 6 confirmaciones (eso es aproximadamente una hora, a 1 bloque cada 10 minutos.)

Hay 2 problemas, el primero es como tu mencionas, el tener que esperar 1 hora para disponer de nuestras monedas, y el segundo problema es que aun hay servicios que nos permiten disponer de nuestro balance sin confirmaciones y esto los vuelve vulnerables.

[DdmrDdmr]

<...> Creo que somos varios los que hemos salido de un apuro con RBF, sin embargo esta técnica lo unico que hace es cambiar el fee de la transacción mas no la direccion destino. <...>

Eso pensaba yo, pero recuerdo haber leído en algún momento alguna referencia a aprovechar la existencia del flag RBF para generar una segunda TX con los mismos inputs, y remitir los fondos a su propia cuenta a mayor fee.

Mírate la descripción que figura en este hilo:
https://coincodecap.com/what-is-replace-by-fee-in-bitcoin

Mi duda es si lo logra precisamente por haber tenido marcado el flag RBF. Los RBFs que he hecho han sido para desatascar mis TXs, por los que no tengo por la manos estas otras prácticas potenciales …

Este es un caso interesante que he visto hoy (derivado de otra manera supuestamente del RBF):
https://bitcointalk.org/index.php?topic=5391028.msg59617135#msg59617135

[RandyWMizher]

Hay 2 problemas, el primero es como tu mencionas, el tener que esperar 1 hora para disponer de nuestras monedas, y el segundo problema es que aun hay servicios que nos permiten disponer de nuestro balance sin confirmaciones y esto los vuelve vulnerables.

Lo que tengo entendido es que una hora es un buen tiempo para que las transacciones se consideren "finales". Si lo comparas con una transferencia bancaria o una compra con tarjeta de crédito, la posibilidad de rechazar el cargo y que el comercio nunca vea el dinero (y volver a gastarlo en otro sitio, es decir, "doble gasto") se va a 48 o 72 horas por lo menos.

Si se necesita más velocidad está Lightning.

[famososMuertos]

...//...::

Lo que tengo entendido es que una hora es un buen tiempo para que las transacciones se consideren "finales". Si lo comparas con una transferencia bancaria o una compra con tarjeta de crédito, la posibilidad de rechazar el cargo y que el comercio nunca vea el dinero (y volver a gastarlo en otro sitio, es decir, "doble gasto") se va a 48 o 72 horas por lo menos.
...,,,,

Hoy puedes obtener esas >=6 confirmaciones en menos tiempo, mucho menos, es lo que hay que mirar.

Lo otro, amigo, no se a que te refieres, pero un exceso de crédito no es doble gasto, es deuda. 

Una transferencia bancaria no se puede revertir, se puede demorar, o puede ser devuelta, en el caso errado de datos, pero incluso, debes esperar, pero en el caso que nos atañe, si enviaste $100 estos no están disponibles en tu cuenta, y màs aùn en una transferencia común no tienes el control de los fees.

En todo caso hablamos de doble gasto en una transacción de bitcoin.

[d5000]

Si el problema del doble gasto fuera "parchado" no necesitaríamos del PoW, ni de otros mecanismos como el PoS; simplemente podríamos compartir una blockchain entre todos los nodos de la red, como si fuera un "torrent".

El problema tiene su raíz en el problema de los generales bizantinos. De manera muy simplificada, cuando un nodo no cuenta con una conexión estable y fiable con al menos dos tercios de los nodos que están conectados con él, no puede determinar que un mensaje fuera correcto; cada nodo o "general" puede ser un traidor (o simplemente, transmitir un mensaje erróneo).

En el caso de Bitcoin, en el caso que un nodo reciba dos intentos de gastos en conflicto (que gastan el mismo UTXO), no se podría determinar cual de los dos llegó primero si no existiera un mecanismo como el PoW. Este interpone una instancia (el minero) que cuenta con la autoridad de determinar el mensaje correcto (por ejemplo: el que llegó primero es gasto X) y por lo tanto "confirmar" una transacción, solo siendo la potencia computacional el recurso para determinar esta autoridad (por ende BTC es descentralizado). Pero el PoW solo puede aumentar la probabilidad que una de las transacciones sea reconocida por todos los nodos con cada confirmación, nunca llega al 100%. Pero para fines prácticos una probabilidad del 99,999% (sin haberlo calculado) es suficiente.

En otras palabras: si no existiera el doble gasto, no necesitaríamos a Bitcoin (en el sentido de "el invento de Satoshi", y una criptomoneda funcional hubiera sido inventada ~10 años antes probablemente). Pero es extremamente improbable que se "pueda parchar", ya que es una consecuencia de las leyes de la teoría de la información que actualmente estamos usando.

[seoincorporation]

...
En otras palabras: si no existiera el doble gasto, no necesitaríamos a Bitcoin (en el sentido de "el invento de Satoshi", y una criptomoneda funcional hubiera sido inventada ~10 años antes probablemente). Pero es extremamente improbable que se "pueda parchar", ya que es una consecuencia de las leyes de la teoría de la información que actualmente estamos usando.

Muy buena explicación colega, gracias por compartila.

Ahora entiendo que si no se ha parchado es debido a que es parte de esta tecnología y aunque la gente abuse de esto hay formas de evitar ser estafado (Como esperar por cierta cantidad de confirmaciones).

Y como ya comentaron es este mismo hilo, una de las soluciones es la red de rayos, este sería el camino adecuado a seguir para lo que busquen transacciones instantáneas.

[DdmrDdmr]

En relación al tema del doble gasto, es interesante ver el hilo siguiente, donde el OP intenta realizar uno fin de ver lo que sucede: [TESTED IT] Changing the transaction after broadcasting, what happens? . Es un caso de intento de doble gasto puro y duro, y no un RBF.

Según se observa, la propia mempool controló el intento, retornando un error indicativo del conflicto en la segunda TX, siendo así reportado por los mensajes de error mostrados en múltiples exploradores de bloques.

[seoincorporation]

...
Según se observa, la propia mempool controló el intento, retornando un error indicativo del conflicto en la segunda TX, siendo así reportado por los mensajes de error mostrados en múltiples exploradores de bloques.

He leido el hilo y por lo que comentan, si la transaccion se encuentra en la Mempool entonces es cuando marca el error al intentar gastar de nuevo el mismo input. Sin embargo esto no soluciona el double spend ya que si tomamos los mismos imputs, construimos 2 transacciones diferentes con ellos, y los enviamos a la red (broadcast) al mismo tiempo pero desde diferentes nodos, entonces será considerado un doble gasto, ambas pasarán pero solo una se confirmará.

[DdmrDdmr]

De hecho, el OP, según entiendo, creó 2 TXs con los mismos inputs, pero al lanzar las 2 TXs con un minuto de separación, la primera ya se había propagado a (probablemente) todos los nodos, y las mempools tenían fácil mostrar un error al llegar una segunda TX 60 segundos más tarde con los mismos inputs.

Según comentan en el hilo, lanzando las 2 TX con entorno a 1 segundo aprox., tendríamos ambas TXs compitiendo por ser aceptadas. En todo caso, para ser ecuánime, yo haría las TXs con el mismo fee (en el caso referenciado, la segunda tiene x10 el fee de la primera).

[d5000]

Ojo que cuando alguien transmite las dos transacciones al mismo tiempo, puede darse en algunas pocas ocasiones el caso que una de las dos fuera confirmada en un bloque, pero que éste quede huérfano y luego la otra transacción llegue primero al minero que confirme el bloque "canónico" que al final queda registrado en la cadena.

Por eso estaría bueno que alguien intente el experimento de manera continua, para tener una idea cuán probable es este tipo de doble gasto "1-conf" en la actualidad - hay varios servicios que aceptan una sola confirmación de Bitcoin, para los cuales este ataque potencialmente puede ser peligroso. Pero claro, este experimento no sería gratis, al menos en la red principal de BTC (y en testnet, o en una altcoin, el resultado no sería tan interesante porque las características de esta red son muy diferentes).

El doble gasto "peligroso" obviamente es un poco diferente: cuando un minero publica una transacción con un pago, al mismo tiempo mina en secreto dos o más bloques que incluyen su doble gasto, sin propagarlos hasta que esta cadena sea más larga que la cadena "canónica", y luego la propaga, quedando confirmado su doble gasto. Este sería el famoso "ataque de 51%", porque para que tenga éxito el minero debe tener al menos en este momento más del 50% del hashrate.