Bitcoin privado · Shielded CSV

Pagos privados en Bitcoin
nada legible on-chain

zkCoins aporta verdadera privacidad a Bitcoin. Importes, emisor, receptor e historial permanecen off-chain — demostrados con zero-knowledge, mientras cada transferencia publica en Bitcoin solo un nullifier de ~64 bytes.

Sin soft fork Self-custodial Zero-knowledge Sin coordinator
~16vBon-chain por transferencia
~100tx/stecho de rendimiento
0soft forks
0coordinators
Transferencia Bitcoin habitual
frombc1q7f…3k9
tobc1p2m…q8x
amount0.4218 BTC
~140 vBytes · totalmente público · uno por pago
un orden de magnitud menor
Transferencia zkCoins
un nullifier
de ~64 bytes
~16 vBytes on-chain · datos de monedas off-chain

Los datos de las monedas nunca tocan la chain. Cada transferencia publica en Bitcoin un nullifier de ~64 bytes — unos 16 vBytes, frente a ~140 de una transferencia habitual — constante sin importar cuántas monedas mueva.

"Use the chain for what the chain is good for — an immutable ordering of commitments to prevent double-spending." — Robin Linus, coautor de Shielded CSV
Whitepaper · ePrint 2025/068

Shielded CSV: Private and Efficient Client-Side Validation

Una variante de Client-Side Validation que preserva la privacidad, liquidada directamente en Bitcoin.
Autores
Jonas Nick (Blockstream) · Liam Eagen (Alpen Labs) · Robin Linus (ZeroSync)
Publicado
enero de 2025 (ePrint) · septiembre de 2024 (whitepaper)
Referencia
eprint.iacr.org/2025/068
Predecesor
zkCoins (Robin Linus, 2023) · se basa en el prototipo ZeroSync

Client-Side Validation desacopla la validación de transacciones del consenso de Bitcoin moviéndola al destinatario. Shielded CSV mejora diseños CSV anteriores ocultando por completo el historial de transacciones: cada transferencia solo filtra un nullifier de 64 bytes a la chain, y el resto se verifica client-side mediante succinct zero-knowledge proofs. El protocolo es compatible con Bitcoin tal cual — sin soft fork, sin hard fork — y apunta a aproximadamente un orden de magnitud más de transacciones por segundo que la base layer sola.

zkCoins v1 implementa fielmente el modelo del paper: cada transferencia publica su nullifier de ~64 bytes directamente en Bitcoin como firma semi-agregada, de modo que la propia chain garantiza cada nullifier que un verificador necesita para sus comprobaciones de double-spend — sin datos de batch off-chain, sin supuesto de data-availability. Unos 16 vBytes on-chain por transferencia, del orden de ~100 transacciones por segundo.

Lo que cambia Shielded CSV

Transferencias privadas, un nullifier minúsculo en Bitcoin

Los datos de las monedas permanecen off-chain. Cada transferencia publica en Bitcoin solo un nullifier de ~64 bytes, demostrado con zero-knowledge — así ganan a la vez privacidad y una pequeña huella on-chain.

Huella on-chain
Un nullifier por transferencia

Los datos de las monedas nunca tocan la chain. Cada transferencia publica en Bitcoin un nullifier de ~64 bytes — nada legible sobre importes ni partes.

Grafo de transacciones
Nada enlazable

A diferencia de RGB o Taproot Assets, el historial permanece oculto bajo un zero-knowledge proof. Los destinatarios verifican la validez sin ver nunca el linaje.

Compatibilidad
Bitcoin, sin cambios

Sin soft fork, sin hard fork. Los protocolos CSV usan la chain solo para ordenación y prevención de double-spends.

Coste
Una fracción de una transferencia Bitcoin

Cada transferencia cuesta unos 16 vBytes on-chain — una fracción de una transferencia Bitcoin de ~140 vBytes, aproximadamente un orden de magnitud menor — constante sin importar cuántas monedas mueva.


Cómo funciona

La chain ordena, el destinatario valida

Las blockchains tradicionales piden a cada nodo que valide cada transacción. Shielded CSV invierte eso — la validación pasa al destinatario, y Bitcoin solo hace aquello en lo que es único.

  1. 1

    El emisor prueba

    El emisor crea una transferencia y genera un succinct validity proof de todo el historial de la moneda — un tamaño constante, por antigua que sea la moneda.

  2. 2

    La proof va al receptor

    La proof viaja directamente al receptor, off-chain. Solo emisor y receptor ven alguna vez importes, partes e historial — no se escriben importes ni partes en la chain.

  3. 3

    El nullifier se publica en Bitcoin

    El nullifier de ~64 bytes de la transferencia se publica en Bitcoin como firma semi-agregada. La publicación es permissionless — cualquier wallet puede auto-publicar — y la propia chain conserva cada nullifier que un verificador necesita.

  4. 4

    El receptor verifica client-side

    El receptor re-verifica localmente el zero-knowledge proof completo de la moneda — una sola comprobación en tiempo constante, por largo que sea el historial — y lo acepta sin confiar en terceros.

  5. 5

    Bitcoin previene los double-spends

    Bitcoin registra cada nullifier en orden canónico, y la primera aparición on-chain de la state key de una moneda selecciona su única transición válida. El único trabajo de la chain: garantizar que cada moneda se gasta exactamente una vez — sin necesidad de datos off-chain.


En cifras

Bitcoin, junto a Shielded CSV

MétricaBitcoin (habitual)zkCoins v1
Datos on-chaintransacción completa (~140 vBytes)nullifier de ~64 bytes por transferencia
Coste por transferencia~140 vBytes~16 vBytes por transferencia
PrivacidadNinguna — totalmente públicoTotal — nada legible on-chain
VerificaciónScript completo por tx1× proof de transferencia
Tamaño de proofN/AConstante, independiente del historial

Límites

Lo que Shielded CSV no es

Aquí la privacidad es estructural, no un añadido. Conviene ser precisos sobre lo que este protocolo deliberadamente no es.

No es una sidechain

Usa Bitcoin L1 directamente — sin consenso separado, sin bridge a una chain ajena.

No es un rollup

Sin sequencer, sin capa de data-availability — los nullifiers viven en el propio Bitcoin. Las validity proofs se mueven peer-to-peer entre emisor y receptor; el nullifier de ~64 bytes de cada transferencia se ancla a Bitcoin L1.

No es un mixer

La privacidad es estructural, no ofuscación — un conjunto de anonimato global de cada moneda, no un pool pequeño por ronda.

No es un token

Sin token nativo de protocolo que bootstrapear. El valor vive en monedas validadas client-side.

No es un soft fork

Funciona en Bitcoin tal como existe hoy — sin cambio de consenso, sin nuevos opcodes.


Roadmap

El camino al mainnet

  1. Phase 01

    Fundamentos

    Q2 2026 Activo

    El stack de proving y el límite wallet–servidor. Todo lo posterior depende de esto.

    • Migración del circuit zero-knowledge.Mover el circuit de transición de estado a un sistema de proving nativo para recursión con un hash SNARK-friendly.
    • Proving en servidor sobre hardware commodity.Objetivo Apple Silicon de un solo host — sin granjas GPU, sin servicio de proving en la nube. El wallet solo guarda la clave privada.
    • Límite del wallet vía BIP-340 Schnorr.El wallet firma un digest SHA-256 del estado calculado en el servidor. Sin zero-knowledge en el navegador.
    • Roundtrip de extremo a extremo en signet.Crear cuenta, mintear, enviar, recibir — el bucle de usuario completo corre en un testnet público de Bitcoin.
  2. Phase 03

    Bridge BTC trustless

    Q4 2026 Planificado

    Mint y burn contra BTC nativo sin confiar en el issuer. La mayor brecha de confianza de cara al usuario se cierra aquí.

    • Bridge al estilo BitVM2 / Clementine.Modelo de confianza 1-of-N honesty. La misma construcción que corre en el mainnet de Citrea.
    • Light client de Bitcoin recursivo.Un succinct proof de que un depósito aterrizó a profundidad ≥ 6 en la chain canónica.
    • Recursión → wrapping Groth16.Llevar nuestras proofs aptas para recursión a un verificador que Bitcoin script pueda comprobar.
    • Escalado de la federation: N=3 → N=100.Empezar con una federation de un solo operador; crecer hasta cien miembros independientes, donde basta una key deletion honesta.
    • Run de integración en signet.Roundtrip completo de peg-in / peg-out incluyendo un escenario de operador deliberadamente malicioso.
  3. Phase 04

    Atomic swap con Lightning

    Q1 2027 Planificado

    Mover valor entre Lightning y zkCoins de forma atómica — sin confianza en el provider, sin bridge custodial.

    • HTLC en la transacción de funding del nullifier.La atomicidad vive en Bitcoin layer 1, no en la capa de monedas privadas. Primitivas estándar, sin soft fork.
    • Flujos LN ↔ zkCoins simétricos.Comprar con sats de Lightning y vender de vuelta a sats de Lightning, ambas direcciones trustless.
    • Liquidez adelantada por providers.Cualquiera puede operar un swap provider; el protocolo impone la honestidad, no el operador.
    • Patrón de swap que preserva la privacidad.Un swap provider conoce el lado LN, nunca el grafo interno de zkCoins.
  4. Phase 05

    Posicionamiento a largo plazo

    2027 + Horizonte

    Sustituir las tecnologías de bridge de hoy por las de mañana — sin cambiar el protocolo.

    • Sistema de proving de nueva generación.Portar a un field más pequeño con un hash más rápido una vez se estabilice el stack upstream. La estructura algorítmica se mantiene.
    • Mejora de la construcción del bridge.Los sucesores drop-in de BitVM2 (Glock, Mosaic) recortan el coste de disputa on-chain en dos órdenes de magnitud. El contract del circuit no cambia.
    • Diversidad de la federation.Reclutar organizaciones independientes como miembros de la federation hasta que one-honest-deletion sea una hipótesis significativa.
    • Trusted setup del verificador del bridge.Una ceremony de 30–60 contribuidores sustituye el conjunto de parámetros Groth16 de un solo contribuidor usado para probar el verificador del bridge — las proofs propias de zkCoins son transparentes (FRI) y no necesitan setup.

Nota. Las fechas indican ventanas objetivo del trabajo de ingeniería, no una fecha de mainnet garantizada. zkCoins corre en un entorno de prueba público hasta que termine el endurecimiento pre-mainnet; ningún Bitcoin real está en riesgo antes.


Ecosistema

La familia zkCoins

Inversores

Canal directo para fondos y angels

zkCoins lleva Shielded CSV a un wallet self-custodial — Bitcoin privado en L1, sin soft fork. Mantenemos una línea abierta para venture funds, family offices y angels estratégicos que evalúan el proyecto.

El protocolo se basa en investigación publicada (ePrint 2025/068), el stack es open source y el roadmap es público. No estamos levantando capital de forma activa — pero estamos abiertos a conversaciones antes del mainnet.

[email protected]
FAQ

Preguntas, respuestas

¿Qué es zkCoins?

zkCoins es un wallet self-custodial para Shielded CSV, un protocolo de privacidad para Bitcoin. Importes, emisor, receptor e historial de transacciones permanecen off-chain, demostrados con zero-knowledge y verificados client-side. Cada transferencia publica en Bitcoin solo un nullifier de ~64 bytes.

¿Es zkCoins un token nuevo o un altcoin?

No — zkCoins no es una blockchain separada, un altcoin ni un token nativo de protocolo. Es una capa de client-side-validation anclada a Bitcoin L1; el valor vive en monedas validadas client-side. Mover BTC on-chain dentro y fuera usa un bridge, que está en el roadmap.

¿Requiere zkCoins un soft fork?

No. Shielded CSV funciona en Bitcoin tal como existe hoy — sin soft fork, sin hard fork, sin nuevos opcodes. La chain se usa solo para ordenar commitments y prevenir double-spends.

¿Cómo mantiene zkCoins privadas las transacciones?

Cada spend se demuestra con un zero-knowledge proof y se comparte off-chain. Los datos de las monedas — importes, partes e historial — nunca tocan Bitcoin; solo se publica en la chain un nullifier de ~64 bytes por transferencia.

¿Es zkCoins self-custodial?

Sí. Las claves se generan y almacenan localmente en tu navegador y nunca salen de tu dispositivo. zkCoins es peer-to-peer, sin coordinator ni custodian que pueda congelar fondos o apagar la red.

¿Qué es Shielded CSV?

Shielded CSV (Client-Side Validation) es un protocolo de Bitcoin que preserva la privacidad, del paper de Jonas Nick, Liam Eagen y Robin Linus (ePrint 2025/068). zkCoins v1 lo implementa fielmente: cada transferencia publica en Bitcoin un nullifier de ~64 bytes, y todo lo demás se verifica client-side.

¿El rol de publisher está realmente descentralizado?

La publicación es permissionless, y cualquier wallet puede auto-publicar sus propias transferencias a Bitcoin a un coste trivial — eso limita lo que puede cobrar un publisher dominante. La economía competitiva favorece al operador más rápido y mejor capitalizado, así que se espera cierta concentración. Solo es un riesgo de liveness: un publisher nunca tiene custody y como mucho puede censurar o retrasar una transferencia, nunca robar o falsificar monedas. Análisis completo en la página Risks de las docs.

¿Dónde viven los nullifiers?

En Bitcoin. Cada transferencia publica su nullifier de ~64 bytes directamente en la chain como firma semi-agregada, de modo que el propio Bitcoin garantiza la disponibilidad de cada nullifier que un verificador necesita para comprobar los double-spends — sin datos de batch off-chain y sin una capa de data-availability separada en la que confiar. Los datos de las monedas — importes, partes e historial — siguen off-chain, demostrados con zero-knowledge, y nunca hacen falta para reconstruir la vista pública de double-spend.

Prueba Bitcoin privado hoy

El wallet de zkCoins corre en tu navegador. Las claves se generan y almacenan localmente — nunca salen de tu dispositivo. Actualmente en una red de prueba pública; ningún Bitcoin real está en riesgo.