Dirección de Bitcoin

Alice quiere pagar a Bob. Bob abre Recibir en su cartera, comprueba la dirección y se la envía como texto o código QR. Alice la carga en su cartera y verifica el destinatario y el importe antes de enviar. No necesita interpretar cada carácter: la aplicación se encarga de ello. A partir de la dirección, la cartera construye la condición que permitirá gastar el dinero más adelante, normalmente mediante una firma con la clave privada correcta. La transacción registra esa condición en un script llamado scriptPubKey. Guarda el importe y el script, no el texto habitual de la dirección. La dirección sirve para comunicar los datos de pago; no es un recipiente que contenga monedas. [1] [3]

Copia la dirección o escanea su QR en lugar de teclearla. Pero no termines ahí: un programa malicioso puede sustituirla en el portapapeles. Compara la dirección completa con la que has obtenido del destinatario por un canal fiable; si utilizas una Hardware Wallet, compruébala también en la pantalla del propio dispositivo. No basta con el principio y el final, que una dirección fraudulenta puede imitar. Las direcciones incluyen una suma de comprobación para detectar errores de escritura, pero esta no confirma que una dirección bien escrita pertenezca a la persona correcta. La cartera también debe admitir el formato y la red. Un pequeño pago de prueba puede ayudar, pero no sustituye la comprobación en la siguiente transferencia. El protocolo no permite cancelar sin más un pago confirmado a una dirección equivocada pero válida. [2] [7] [8] [18]

La próxima vez que Bob pulse Recibir, puede aparecer otra dirección. Eso no significa que su dinero haya desaparecido. Una dirección nueva ayuda a proteger la privacidad: quien conoce una dirección publicada puede seguir sus pagos en la cadena, pero no debería obtener automáticamente una visión de todos los ingresos de la cartera. Reutilizarla facilita esa conexión. Las direcciones nuevas tampoco garantizan anonimato: transacciones posteriores pueden revelar otras relaciones. Puedes compartir una dirección para recibir un pago, aunque no conviene publicarla sin pensar. Además, una dirección no equivale a una persona: varias personas pueden gestionar fondos conjuntamente, o un servicio puede hacerlo para sus clientes. [1] [14]

La cartera gestiona claves, localiza pagos que puede gastar y muestra su suma. Por eso, el saldo puede proceder de muchas direcciones. Una HD Wallet habitual genera familias de claves desde un origen común: obtener otra dirección no implica abrir otra cartera. Al pagar, la aplicación también puede devolver el importe sobrante a una dirección propia, llamada Change Address. Sin embargo, las direcciones no bastan para recuperar la cartera. La copia de seguridad debe permitir recuperar las claves necesarias y sus reglas de uso. Muchas carteras utilizan una Seed Phrase, un conjunto de palabras de recuperación; las configuraciones más complejas pueden requerir otros datos. Quien te paga nunca necesita esas palabras ni tus claves privadas. [10] [14]

Un código QR solo representa información. Puede incluir una dirección o una solicitud que empiece por bitcoin: y añada importe, etiqueta del destinatario o mensaje. BIP21 describía este sistema y BIP321 lo amplía. Antes de confirmar, comprueba qué ha leído la cartera. Las solicitudes de Lightning Network, como una invoice para un pago o un offer que permite solicitar nuevas invoices cada vez, siguen otro procedimiento; Lightning Address facilita solicitar ese tipo de pago. Algunas solicitudes ofrecen varias formas de pagar. Tampoco una firma digital de un mensaje identifica automáticamente a una persona: BIP322 permite demostrar que se pueden cumplir las condiciones de un script, pero por sí solo no acredita identidad legal ni la aprobación de cualquier factura. [15] [16] [17]

Base58Check combina un byte de versión con los datos llamados payload. Añade los primeros cuatro bytes de SHA256(SHA256(version || payload)) y codifica el resultado en Base58. En mainnet, 0x00 indica P2PKH y 0x05 indica P2SH; de ahí los comienzos habituales 1 o 3. Las redes de prueba usan otras versiones. El alfabeto omite los caracteres fáciles de confundir 0, O, I y l. Este checksum de 32 bits detecta muchos errores, pero no acredita al destinatario. [2] [3]

La representación nativa de SegWit incluye el prefijo bc para mainnet o tb para testnet, el separador 1, la versión witness y los datos en grupos de 5 bits. Termina con 6 caracteres de comprobación. BIP173 introdujo Bech32; tras descubrir una debilidad ante ciertas inserciones y eliminaciones, BIP350 mantuvo Bech32 para la versión 0 y estableció Bech32m para las versiones 1–16. Las letras pueden ser todas minúsculas o todas mayúsculas, nunca mezcladas. El límite de codificación es de 90 caracteres. Incluso un código válido puede pertenecer a otra red o a una versión no compatible. [7] [8]

P2PKH y P2WPKH remiten al HASH160 de 20 bytes de una clave pública. P2SH usa HASH160 de redeemScript, mientras P2WSH usa SHA256 de witnessScript. SegWit v0 reconoce así P2WPKH de 20 bytes y P2WSH de 32 bytes. P2TR según BIP341 es distinto: su programa de versión 1 contiene una clave de salida Q ajustada, x-only y de 32 bytes, no el hash de una clave receptora corriente. Q también puede incorporar la raíz de un árbol de scripts adicionales, vinculando criptográficamente la clave con esas condiciones de gasto. La dirección no revela por sí sola todas las opciones de gasto. [6] [9]

Las primeras salidas de Bitcoin solían pagar directamente a una clave pública. P2PKH retrasó su revelación hasta el gasto. BIP13 y BIP16 permitieron transmitir con P2SH el hash de un script más complejo. BIP141 añadió programas witness versionados, BIP173 Bech32, y BIP341 con BIP350 el formato Taproot con Bech32m. El aspecto distinto responde a distintas condiciones de verificación. No «conviertas» una dirección cambiando a mano el prefijo: puedes crear otra salida o una imposible de gastar. Algunos scripts no estándar y las primeras salidas pay-to-pubkey no tienen una dirección canónica habitual. [4] [5] [6] [7] [8] [9] [3]

Una HD Wallet según BIP32 deriva muchas claves de una raíz común. Las rutas distinguen tipos de salida: BIP44 usa el propósito 44' para P2PKH, BIP84 el 84' para P2WPKH y BIP86 el 86' para P2TR de una sola clave. Después vienen el tipo de moneda (coin type), la cuenta, la rama de recepción o change y el índice de la dirección. La Seed Phrase sola puede no definir todas las rutas, cuentas y reglas Multisig. Un Output Descriptor también conserva el origen de las claves y la construcción del script. Recuperar significa encontrar los fondos reales, no solo volver a mostrar una dirección conocida. [10] [11] [12] [13] [14]

En P2PKH y P2WPKH normalmente se ve primero el hash de la clave; al gastar se revela la clave pública. P2SH y P2WSH revelan el redeemScript o witnessScript utilizado. Taproot ya incluye una clave pública ajustada en la salida. Un key-path spend suele añadir una Schnorr Signature, mientras un script-path spend revela el script elegido, el control block y la ruta Merkle; las ramas no utilizadas pueden permanecer ocultas. Por tanto, no toda dirección esconde la clave pública. [6] [9]