393 / 736SIPA

Pieter Wuille

Desarrollador conocido como sipa

Pieter Wuille contribuyó a diseñar cómo las carteras de Bitcoin crean claves, representan direcciones y firman pagos. Quizá utilices su trabajo sin haber oído nunca el nombre sipa.

Pieter Wuille, conocido como sipa, es desarrollador de Bitcoin y autor o coautor de BIP 32, SegWit, Bech32, Bech32m y Schnorr/Taproot. Un BIP es una propuesta técnica pública. Su aportación consiste en soluciones concretas desarrolladas con otras personas, no en el derecho a decidir por toda la red.

Cuando una cartera ofrece una dirección nueva o prepara la firma de un pago, detrás de ese sencillo botón está el trabajo de muchos desarrolladores. Uno es Pieter Wuille. En GitHub usa el nombre sipa, y su perfil vincula ese nombre con su actividad. Pero para atribuir una idea concreta hay que consultar la historia y la documentación del proyecto, no solo un nombre de usuario. Las siguientes propuestas muestran qué ayudó a resolver y con quién. [1]

Imagina una tienda que quiere una dirección de pago distinta para cada pedido. BIP 32, de Wuille, describe cómo derivar un árbol de claves a partir de una semilla: los datos secretos iniciales. Una clave pública extendida, llamada xpub, permite obtener nuevas claves públicas de la rama correspondiente sin conceder permiso para gastar. Una clave privada, en cambio, permite firmar. Hay una excepción importante: combinar el xpub con una clave privada descendiente filtrada, derivada sin pasos hardened, puede revelar la clave privada del padre. La derivación hardened interrumpe esa vía. Por eso hay que cuidar el xpub; compartirlo también revela relaciones entre pagos. [2]

Otras transacciones pueden depender de una anterior, así que su identificador importa. BIP 141, de Eric Lombrozo, Johnson Lau y Pieter Wuille, separa los datos de verificación llamados witness, incluidas las firmas, de la parte que determina el identificador original txid. El nuevo identificador wtxid también incluye el witness. Así, cambiar los datos de firma no tiene por qué cambiar el txid al que se refiere otra transacción. Las firmas siguen verificándose: un compromiso criptográfico en la transacción coinbase, la primera del bloque, protege el witness. [3]

Al copiar una dirección es fácil equivocarse en un carácter. Wuille y Greg Maxwell describieron Bech32 para direcciones nativas de SegWit en BIP 173. Su suma de comprobación contiene caracteres que ayudan a detectar una escritura dañada. Es útil, pero tiene un límite: comprueba la codificación, no la identidad del destinatario previsto. Si alguien sustituye la dirección por otra válida, la suma de comprobación no detectará que se trata de un engaño. [4]

Los formatos de dirección también se revisan. BIP 350, de Wuille, modifica la suma de comprobación para corregir una debilidad concreta relacionada con insertar o eliminar caracteres. El resultado es Bech32m. La cartera debe comprobar que la versión de witness coincide con la codificación: la versión 0 sigue usando Bech32; las versiones 1 a 16 usan Bech32m. El usuario no debería tener que elegir el algoritmo manualmente. Crear y comprobar las direcciones corresponde al software; no basta con aceptar cualquier suma de comprobación válida. [5]

Una firma digital permite verificar la autorización de un pago sin que el propietario revele su clave privada. BIP 340, de Pieter Wuille, Jonas Nick y Tim Ruffing, especifica Schnorr signatures con firmas de 64 bytes y claves públicas de 32 bytes. El byte es una unidad de tamaño de datos. Sus propiedades matemáticas permiten construir sistemas donde varias personas generan una firma conjunta. Pero sumar claves sin más no basta: hace falta un protocolo específico para coordinar a los participantes de forma segura. [6]

Una cartera puede tener una vía habitual para gastar y otras condiciones de respaldo. Pieter Wuille, Jonas Nick y Anthony Towns describen Taproot en BIP 341. Al gastar por la vía de clave, key path, puede bastar una firma sin revelar siquiera que existen scripts alternativos. Un script es un programa que expresa condiciones para gastar. Si se necesita la vía de script, script path, se publica el script utilizado y la prueba de que estaba incluido; las alternativas no utilizadas no tienen que mostrarse completas. Eso ahorra espacio y oculta parte de la configuración de la cartera, pero no vuelve anónimos todos los pagos automáticamente. [7]

Estas mejoras resuelven problemas concretos y permiten que otros examinen el diseño y el código. Bitcoin.org explica que un BIP se debate públicamente y que su adopción depende de los participantes de la red. Un nodo es un ordenador que verifica transacciones y bloques según su software. Ser autor o mantener un repositorio no otorga autoridad para cambiar las reglas de consenso unilateralmente. La importancia de Wuille está en sus aportaciones y su colaboración, no en ser el jefe de Bitcoin. [8]

Para obtener la imagen más completa, lee esta entrada junto con Craig Wright, Gregory Maxwell, Satoshi Nakamoto. También enlazan con esta entrada Craig Wright, Gregory Maxwell.

DOC · 001GitHub — Pieter Wuille (sipa)Documentación DOC · 002BIP 32 — Hierarchical Deterministic WalletsDocumentación DOC · 003BIP 141 — Segregated WitnessDocumentación DOC · 004BIP 173 — Bech32Documentación DOC · 005BIP 350 — Bech32mDocumentación DOC · 006BIP 340 — Schnorr signaturesDocumentación DOC · 007BIP 341 — Taproot spending rulesDocumentación DOC · 008Bitcoin.org — FAQDocumentación
Revisado: Fuentes primero · No es asesoramiento financiero