Mike Hearn es un desarrollador de Bitcoin y coautor de varios BIP, documentos que describen propuestas técnicas. Participó en la biblioteca bitcoinj y en métodos para comprobar conexiones, seleccionar transacciones relevantes e intercambiar mensajes durante un pago. Seguir el recorrido desde el monedero de un teléfono hasta el comercio ayuda a comprender su aportación.
Quien crea un monedero de Bitcoin no necesita programar desde cero toda su comunicación. Puede recurrir a una biblioteca: un conjunto de funciones ya preparadas sobre las que construir su aplicación. bitcoinj es una de ellas. Su archivo AUTHORS incluye a Mike Hearn entre muchos colaboradores y remite al historial de cambios de Git. Así se puede seguir cada aportación concreta. Esto no significa que Hearn escribiera todas las funciones por su cuenta ni que actualmente dirija todo el proyecto. [1]
bitcoinj es una biblioteca en Java que permite gestionar un monedero y enviar o recibir transacciones sin instalar Bitcoin Core localmente. Para un teléfono resulta útil SPV, abreviatura de Simplified Payment Verification: trabaja con cabeceras de bloques y transacciones relevantes para el monedero en vez de comprobar por completo todas las transacciones. Esto ahorra datos y recursos del dispositivo. La documentación también describe una verificación completa experimental. Son modos distintos; funcionar de forma más ligera no equivale a validar todas las reglas igual, pero más deprisa. [2]
Imaginemos un portátil que sale del modo de suspensión. La conexión con otro nodo puede parecer abierta aunque ya no funcione. El BIP 31 de Hearn permite enviar un ping con un nonce, aquí un número que identifica una consulta concreta. El otro nodo devuelve ese número en un mensaje pong. En versiones del protocolo superiores a 60000, esto permite asociar respuestas y consultas y medir el tiempo de respuesta. Se comprueba la comunicación: una respuesta no demuestra por sí sola la honestidad del nodo ni la validez de un pago. [3]
¿Por qué debería descargar el teléfono transacciones que no le conciernen? El BIP 37, de Hearn y Matt Corallo, describe un filtro Bloom: una herramienta compacta para seleccionar posibles coincidencias. filterload establece el filtro, filteradd añade un elemento y filterclear elimina el filtro. Puede pasar una transacción irrelevante; es lo que se llama un falso positivo. Un filtro más preciso reduce el tráfico, pero puede facilitar que el otro nodo relacione transacciones con la dirección IP del monedero. Ahorrar datos no protege automáticamente la privacidad. [4]
El teléfono necesita saber si una transacción recibida pertenece a un bloque determinado. El mensaje merkleblock del BIP 37 aporta datos para una prueba de Merkle: unas pocas huellas de datos, llamadas hashes, permiten comprobar el vínculo de la transacción con la huella conjunta de la cabecera del bloque. No hace falta descargar el bloque entero. Sin embargo, la prueba no descarta que el otro nodo haya ocultado otras transacciones. SPV tampoco sustituye la validación completa. La documentación de bitcoinj explica el peligro de que un atacante controle todas las conexiones del monedero y decida qué puede ver. [4] [5]
Al comprar algo, necesitas conocer el importe y el destinatario. El BIP 70, de Gavin Andresen y Hearn, introduce PaymentRequest para comunicar estos datos. Contiene los detalles del pago: salidas que indican dónde debe asignar los fondos la transacción, el importe y, opcionalmente, una fecha de caducidad. Los certificados X.509 permiten autenticar la identidad del comercio, de manera similar a los servidores web. Pero el protocolo también admite pki_type none, una solicitud sin esa autenticación. El formato de la solicitud no acredita por sí solo la identidad del comercio. [6]
Si la solicitud indica un servidor de pago, tras autorizar la operación el monedero le envía un mensaje Payment. La respuesta PaymentACK puede comunicar que el comercio ha aceptado el pago para procesarlo. Es información útil para el cliente, pero sigue siendo una afirmación del servidor del comercio, no una prueba de confirmación en un bloque. Del mismo modo, refund_to solo indica dónde puede enviar el comercio un reembolso; no devuelve dinero por sí mismo. La aplicación debe distinguir los mensajes sobre un pago del movimiento efectivo de los fondos. [6]
Una guía antigua puede dar la impresión de que su procedimiento funciona en todas partes. El registro marca el BIP 70 como Deployed, es decir, implementado. Sin embargo, las notas de Bitcoin Core 0.20.0 documentan la eliminación completa de su soporte en ese programa. No hay contradicción: una especificación utilizada históricamente no tiene por qué estar disponible en todos los clientes actuales. El trabajo de Hearn ayuda a entender la evolución de los monederos; para usar un procedimiento también hay que comprobar las funciones del programa y de su versión. [6] [7]
Para obtener la imagen más completa, lee esta entrada junto con Jeff Garzik, Gloria Zhao, Merkle Tree. También enlazan con esta entrada Jeff Garzik, Gloria Zhao.