Por lawn
Me gustaría tratar una idea falsa que últimamente está en el centro de muchos debates sobre Bitcoin: la idea de que la seguridad de Bitcoin es binaria. Lo cierto es que la seguridad no es una cuestión que deba juzgarse en términos de «todo o nada». Un nivel adecuado de seguridad surge de un equilibrio entre, por un lado, estar suficientemente seguro dentro de tu modelo de amenaza y, por otro lado, el coste y la viabilidad de tu protección.
Considera, por ejemplo, el hecho de tener tu puerta principal cerrada con llave. Puede que consideres que tu casa es segura si la puerta está cerrada e insegura si está abierta, pero eso no especifica contra qué estás seguro. Falta el contexto. Puede que te proteja contra ladrones oportunistas, pero un atacante con más determinación podría romper una ventana, forzar la cerradura de la puerta o simplemente romper la propia puerta. Tal vez vivas en un vecindario peligroso y en ese caso puede que necesites un sistema de alarma, un perro o barrotes de hierro en las ventanas.
Al mismo tiempo, aun en ese caso podría no ser práctico invertir millones para conseguir la mejor protección posible, si eso implica mudarte a un búnker en el que tus amigos no podrán visitarte.
En la práctica, cerrar la puerta es suficiente para mucha gente. Algunas personas necesitan más que eso y tienen a su disposición muchas opciones, incluyendo costosos servicios de seguridad privada. Eso es lógico, puesto que los modelos de amenaza y la sensación de seguridad no son iguales para todo el mundo. Lo mismo se aplica a Bitcoin. Algunos venden casas a cambio de bitcoins y tienen requisitos de seguridad muy elevados, mientras que otros venden tasas de café. Desafortunadamente, mucha gente, desarrolladores incluidos, no reconocen que las transacciones en la red Bitcoin tienen distintos requisitos de seguridad.
Protección contra el doble gasto y confirmaciones
Una propiedad esencial de Bitcoin es la protección contra el doble gasto (el envío de los mismos bitcoins dos veces). Esto es posible gracias a el uso de la Prueba-de-Trabajo que hace costoso generar cada bloque de transacciones, y cada bloque se agrega al bloque anterior. Si quieres revocar una transacción para hacer un doble gasto, necesitas volver a hacer todo el trabajo de todos los bloques hasta que la encuentres. Es por eso que una transacción más profunda en la cadena de bloques, con más confirmaciones, es más segura que una con menos confirmaciones, ya que a un atacante le llevaría más trabajo revocarla.
Esto permite una buena adaptación a los distintos requisitos de seguridad. Una confirmación es suficientemente buena para bienes de escaso valor, pero los sitios de intercambio podrían requerir seis confirmaciones antes de dar por válida una transacción.
En mayo, alguien llevó a cabo un ataque de doble gasto para revocar transacciones con 22 bloques de profundidad en Bitcoin Gold. Bitcoin no es tán fácil de atacar, puesto que no hay suficiente poder de cómputo minando otras monedas que pueda simplemente desviarse para el ataque, como en el caso de Bitcoin Gold (que, a diferencia de Bitcoin, puede minarse utilizando GPU); pero el ejemplo es útil.
En el momento de escribir estas líneas, un minero obtiene una recompensa de 12,5 BTC por cada bloque que encuentre, aproximadamente unos USD 80.000. Para que merezca la pena un ataque, el doble gasto tiene que ser superior al coste de abandonar los beneficios potenciales de minado. Esto hace que, excepto para transacciones que involucran sumas de dinero muy grandes, sea suficientemente seguro aceptar una única confirmación.
Si quieres aprender más, te recomiendo efusivamente el whitepaper, el cual es bastante fácil de leer.
0-conf
Las transacciones sin ninguna confirmación, a las que nos referimos abreviadamente como 0-conf, por definición no están incluidas en la cadena de bloques y no tienen la protección contra el doble gasto que tienen las transacciones confirmadas. Eso las hace completamente inseguras y no deberían usarse nunca, o eso es lo que algunas personas dicen.
En primer lugar, todos los bienes físicos comprados online tienen un retraso de entrega. Lo peor que puede pasarte si eres el vendedor y aceptas una transacción 0-conf que se gasta dos veces es tener que cancelar el pedido. Como tienes esta posibilidad, no es necesario que requieras una confirmación –que tarda 10 minutos de media pero podría tardar hasta una hora–.
Lo realmente molesto ocurre cuando quieres comprar cosas en tiendas físicas. Es completamente inaceptable tener que esperar 10-60 minutos hasta que tu transacción sea confirmada cuando estás pagando un café.
Alguien podría, sin duda, incurrir en doble gasto y de esa manera robar un café. Pero eso en realidad no es muy diferente de lo que ya tenemos hoy. VISA permite cancelaciones de cargo durante 120 días y el fraude por cancelación de cargo es un problema común para los comerciantes. Por otra parte, si aceptas dinero en efectivo te arriesgas a que te den billetes falsos. Y, por último, siempre corres el riesgo del sencillo y clásico hurto.
Algunos afirman que es muy fácil gastar dos veces 0-conf. Eso es verdad solo si aceptas 0-conf de manera ingenua. Hay estrategias que puedes usar para minimizar el riesgo de un doble gasto. Por ejemplo:
– Probar silenciosamente nodos aleatorios para incrementar la confianza de que la transacción se ha propagado a través de la red.
– Esperar unos pocos segundos y buscar un doble gasto.
– Exigir una tarifa que incremente considerablemente la probabilidad de que la transacción sea aceptada en el siguiente bloque.
– Usar identificación externa, como cámaras de seguridad y tarjetas de identificación (ID) como método de disuación.
– Para transacciones de alto valor o de alto riesgo, esperar confirmaciones.
La investigación sobre cómo mejorar 0-conf continúa. Mira por ejemplo:
– Prevención del doble gasto para las transacciones Bitcoin con cero confirmaciones
– Mala conducta en Bitcoin: un estudio del doble gasto y la responsabilidad
Con esta heurística, aceptar 0-conf es una alternativa viable para algunos comerciantes. No es completamente seguro pero tampoco es completamente inseguro. Esperar un par de segundos versus esperar 10 minutos puede hacer la diferencia entre un negocio viable y uno inviable, y queda completamente a criterio del comerciante la decisión de aceptar o no 0-conf.
A pesar de esto, los desarrolladores de Bitcoin Core han tratado a 0-conf como inseguro per se y han adoptado políticas que lo empeoran deliberadamente. Una situación de bloques permanentemente llenos convierte a 0-conf en poco fiable, porque las tarifas para incluir transacciones en el siguiente bloque no se pueden predecir. En diciembre, las tarifas aumentaron hasta USD 60, pero los desarrolladores de Bitcoin Core consideraron que no era una prioridad aumentar el tamaño de los bloques, así que cabe asumir que los bloques llenos cumplen con el plan para Bitcoin de los desarrolladores de Core, mientras que 0-conf no.
También incorporaron RBF (Reemplazo Mediante Tarifa) en el cliente de referencia Bitcoin Core. Se trata de un método que permite alterar la tarifa de una transacción sin confirmar para volver a propagarla. En otras palabras, hicieron el doble gasto más fácil que antes, en lugar de adoptar políticas que aumentasen la seguridad de 0-conf, «porque ya es inseguro».
SPV (Verificación Simplificada de Pagos) y nodos completos
Jonald Fyookball escribió un buen artículo sobre la seguridad SPV; os animo a leerlo si no lo habéis hecho ya.
En resumen, una cartera SPV evita que sea necesario descargar y almacenar toda la cadena de bloques sólo para poder efectuar transacciones. Todas las carteras móviles funcionan básicamente de este modo. Una cartera SPV es, sin duda, menos segura que un nodo completo, pero no es completamente insegura (de nuevo, hay un espectro de seguridad).
Lo que una cartera SPV hace por ti:
– Se asegura de que tus transacciones estén en un bloque.
– Rastrea la Prueba-de-Trabajo de los bloques. En otras palabras, sigue la cadena más larga.
Lo que no hace por ti:
– Validar las transacciones dentro de un bloque.
Esto quiere decir que un minero puede crear un bloque con transacciones inválidas. Suena mal, pero date cuenta de que:
1. Solo puedes engañar a la cartera SPV si aportas la cadena más larga.
2. El minero debe pagar el coste de la Prueba-de-Trabajo asociado a la creación del/los bloque(s).
Así que, para engañarte, el minero debe, al menos temporalmente, ganarle en poder de cómputo al resto de la red. Esto no es posible a largo plazo si se mantiene el supuesto de seguridad central de Bitcoin: que una mayoría de mineros responde a los incentivos económicos que impone el propio sistema.
Pero es teóricamente posible, por lo que negocios como sitios de intercambio y procesadores de pagos sí podrían estar interesados en la seguridad extra que deriva de mantener nodos completos. Satoshi está de acuerdo:
Los negocios que reciben pagos frecuentes probablemente querrán mantenr sus propios nodos para tener más seguridad independiente y una verificación más rápida.
La mayoría de los usuarios SPV son gente normal que usan carteras más que nada para pagar cosas (para el remitente, las carteras SPV no tienen ninguna desventaja). Si todo el mundo tuviese que descargar toda la cadena de bloques simplemente para usar Bitcoin en el móvil, me temo que Bitcoin nunca llegaría a ser práctico como sistema de pago. A pesar de que las carteras SPV son bastante seguras, hay quienes insisten en que mantener un nodo completo debe ser un requisito para todo el mundo. El desarrollador de Core Luke-Jr ni siquiera considera que los usuarios de carteras SPV sean «usuarios reales»:
«Mantener un nodo completo te convierte en un usuario real de Bitcoin».
Así respondió Luke-Jr en el stackexchange de Bitcoin a la siguiente pregunta: «¿Debería usar un nodo completo como cartera principal?»
«Si no usas un nodo completo para tu cartera, no estás usando Bitcoin, y no tendrás los beneficios que Bitcoin proporciona sobre el dinero fiat. Ya puestos, sería como usar Paypal, salvo que con una persona anónima aleatoria en lugar de una compañía regulada… Así que usa siempre un nodo completo».
Que todo el mundo debería usar un nodo completo se usa como argumento en contra de elevar el límite al tamaño del bloque de 1MB, porque podría haber personas en algún lugar que no puedan almacenar o descargar los datos necesarios. Pero esto impide que Bitcoin pueda procesar más de 7 transacciones por segundo, y las elevadas tarifas que una red congestionada obliga a pagar acaban marginando a las mismas personas que tienen mayores dificultades para mantener nodos completos.
Hard forks y Segwit
Una defensa habitual en estas discusiones es que «es bueno priorizar siempre la seguridad por encima de todo lo demás». Pero quienes sostienen esta postura no priorizan la seguridad de manera consistente.
Os pongo el ejemplo de Segwit, una solución propuesta para el «problema de la maleabilidad» de las transacciones. Jaqen Hash’ghar escribió un genial artículo (2016) sobre el asunto. Lo recomiendo, aunque es un poco largo.
Para abreviar, Segwit fue implementado como soft fork en vez de como hard fork. Un hard fork habría sido más limpio, pero exige actualizar todos los nodos y la gente tiene que estar de acuerdo con el cambio para que la moneda no se divida en múltiples monedas (como la división entre Bitcoin y Bitcoin Cash a partir del hard fork). Esto se consideró muy poco deseable, por las dificultades que suponía llegar a un consenso (tal vez haya algunas similitudes con el enfoque «blanco o negro» en cuestiones de seguridad, pero no es eso en lo que quiero centrarme).
En su lugar, un soft fork elude el problema permitiendo que los nodos continúen trabajando como antes, pero sin reconocer las nuevas funciones. Esto se usó para implementar Segwit como un hack por medio del cual los nodos no actualizados vean las transacciones segwit como transacciones anyone-can-spend «cualquiera-puede-gastar».
Peter R dio una buena charla acerca de por qué esto puede implicar un retroceso en seguridad.
Este retroceso fue señalado por otros también, como Peter Todd:
«En su forma actual, los testigos segregados hacen la minería sin validación más fácil y más rentable que el status quo, particularmente según aumenta la relevancia de las tarifas de transacción».
Está claro que por el momento es solo una debilidad teórica y que probablemente no causará problemas, pero ilustra muy bien las consecuencias de un proceso de pensamiento binario que en este caso, en contra de sus postulados, no prioriza la seguridad.
Conclusión
Hay muchos ejemplos de prestaciones de Bitcoin descartadas como «inseguras» sin un debate matizado sobre riesgos y beneficios. Este pensamiento binario es claramente dañino y debe ser desafiado.