Qué pasó
El 24 de septiembre de 2026, la firma de investigación criptográfica [alloc] init publicó una especificación de 56 páginas para Shielded Bitcoin, un sistema propuesto de transferencias privadas que usa Bitcoin para publicar y ordenar datos sin cambiar el consenso de Bitcoin.
La propuesta no es un soft fork. Añade un sistema separado de transferencias privadas sobre Bitcoin, sin cambiar sus reglas de consenso.
Cómo funcionaría, paso a paso
Hay tres tareas separadas: Bitcoin registra los datos, un indexador reconstruye el registro protegido y una cartera encuentra y gasta las notas de su usuario. Las secciones 4, 15 y 16 de la especificación describen esta división.
1. Publicar una transferencia dentro de una transacción Bitcoin
El emisor reúne notas de salida cifradas, marcadores de gasto y una prueba en un sobre transportado por una transacción Bitcoin. Una nota es un registro privado de valor dirigido a un receptor.
Bitcoin no aprueba cualquier transacción. Siguen aplicándose sus comprobaciones habituales, incluidas las firmas y si las entradas de Bitcoin pueden gastarse. Pero su consenso no interpreta el contenido protegido ni decide si la transferencia privada es válida. Por eso una transacción Bitcoin válida puede contener una transferencia protegida inválida.
2. Reconstruir el registro protegido fuera de Bitcoin
Un indexador busca en el historial de Bitcoin los datos que coinciden con el formato del protocolo y los procesa en orden de bloque. Comprueba la prueba, el estado del registro referenciado y si algún marcador de gasto ya se ha utilizado. Los sobres inválidos no modifican el registro protegido, aunque sus datos permanezcan en Bitcoin.
El diseño permite ejecutar esta reconstrucción localmente en lugar de confiar en un índice ajeno. Implementaciones correctas que partan del mismo estado inicial e historial deberían llegar al mismo resultado. El indexador no necesita las claves de descifrado de los usuarios ni puede gastar sus notas.
3. Permitir que la cartera encuentre sus notas
La cartera recorre las salidas cifradas aceptadas usando su clave de visualización de entradas. Intenta descifrar las notas dirigidas a ella y comprueba que su contenido coincida con los datos del registro aceptado. Descifrar con éxito no basta.
Esto ocurre localmente: la cartera puede detectar un pago sin publicar la identidad del receptor. Ver una nota y gastarla son capacidades distintas; gastarla sigue requiriendo la autoridad correspondiente.
4. Gastar una nota anterior y crear otras nuevas
Para pagar a otra persona, la cartera crea nuevas notas de salida cifradas, incluido el cambio cuando hace falta. Construye una prueba de conocimiento cero que demuestra que controla notas de entrada válidas y conserva su valor, sin exponerlas públicamente. También publica un nullifier, un marcador de gasto único para cada nota de entrada.
La cartera introduce ese nuevo sobre en otra transacción Bitcoin. Cuando un indexador lo acepta, añade los registros de las nuevas notas y los nullifiers a su registro. Una transferencia posterior que presente un nullifier ya registrado será rechazada.
La nota anterior no se borra ni se etiqueta públicamente con su identidad. El nullifier impide gastarla dos veces sin revelar directamente qué nota cifrada anterior se consumió. Bitcoin registra las transacciones; las reglas de reconstrucción protegida aplican esta contabilidad separada.
Informes independientes de Bitcoin Magazine, Decrypt, Cointelegraph y CoinDesk coinciden en esa arquitectura básica y en que no hace falta cambiar el consenso de Bitcoin.
Qué queda privado y qué sigue filtrándose
Para una transferencia aceptada, el objetivo del documento es ocultar el importe, el emisor, el receptor y la posición directa dentro del grafo de transferencias. Quien controla la cartera puede conservar capacidades separadas para ver entradas, recuperar salidas y hacer divulgaciones selectivas sin entregar autoridad para gastar.
Eso no equivale a volver invisible la transacción. Los autores enumeran expresamente como públicos el momento de la transferencia, la cantidad de entradas y salidas, la agrupación de salidas, las comisiones y los metadatos de la transacción portadora. Esas superficies todavía pueden ayudar a correlacionar actividad.
Cointelegraph también recoge críticas sobre un sistema nuevo que comenzaría con un conjunto de anonimato pequeño. Esa preocupación es compatible con el propio modelo de filtraciones del documento: la criptografía puede ocultar campos, pero la privacidad también depende de cuántas personas se comporten de formas difíciles de distinguir.
El límite pendiente: cómo entra y sale el BTC
La pieza sin resolver más importante queda fuera del alcance del documento.
La especificación cubre transferencias después de que el valor ya está dentro del sistema protegido. No especifica peg-in ni peg-out, los mecanismos que moverían BTC ordinario hacia la capa protegida y liberarían BTC al salir. Los autores señalan PIPEs v2 como parte del diseño más amplio, pero reservan esos mecanismos de frontera para trabajo separado.
Ese límite reduce el alcance de la afirmación de no custodia. Los autores dicen que la autoridad para gastar permanece en claves controladas por el usuario dentro de la capa de transferencias del metaprotocolo, mientras excluyen expresamente depósitos y retiros de esa afirmación.
CoinDesk y Decrypt destacan la misma carencia. Tampoco hay una fecha anunciada de lanzamiento. El resultado es una especificación de protocolo y una dirección de investigación, no una función de cartera que pueda desplegarse hoy.
Por qué importa
La propuesta separa la publicación de la contabilidad privada. Bitcoin registra y ordena los datos; un software que puede ejecutarse de forma independiente decide qué transferencias protegidas cuentan. Si Bitcoin reorganiza su cadena, ese software debe reconstruir el estado afectado y las carteras pueden necesitar rehacer pruebas pendientes.
El resultado es un diseño que puede revisarse e implementarse sin modificar el consenso de Bitcoin. Su utilidad práctica sigue dependiendo de la entrada y salida de BTC aún sin especificar, de implementaciones interoperables, de la privacidad durante el uso y del coste de publicar los datos.