Saltar al contenido principal

Consideraciones sobre Bitcoin

Bitcoin es la cadena en la que somos más explícitos con el alcance. La L1 no tiene la expresividad de script necesaria para replicar el patrón de enlace de pago con reparto atómico que usamos en EVM y Solana. Por eso en BTC aplicamos custodia reducida, no custodia cero, y dejamos los pagos recurrentes fuera de alcance hasta que la recurrencia de Lightning BOLT12 esté lista para producción.

Esta página es la referencia que explica el porqué.

Qué significa «custodia reducida» en BTC​

A partir de la Fase 5:

  • Cada nuevo enlace de pago es una dirección multisig taproot 2 de 2.
  • Un firmante es el comercio, con una clave que controla él (xpub registrada al configurar el comercio; derivación por enlace).
  • El otro firmante es la plataforma, mediante un HSM o un servicio MPC (candidatos: Lit, Turnkey, HSM propio). El servidor de la API no guarda la clave en bruto de la plataforma.
  • La liquidación requiere ambas firmas; ninguna de las partes puede mover los fondos de forma unilateral.
  • Cada depósito recibe una PSBT de reembolso prefirmada guardada cifrada off-chain, de modo que el pagador puede recuperar sus fondos si el comercio no está localizable.

Qué cambia respecto a hoy:

  • Ninguna xpub guardada en un único servidor controla los fondos. Comprometer el servidor de la API no da al atacante capacidad de gasto.
  • Los comercios están explícitamente en el circuito de firma. Ninguna liquidación les puede pillar por sorpresa.
  • Los reembolsos siempre son posibles (el comercio difunde la PSBT prefirmada).

Qué se mantiene​

  • La contabilidad del reparto se sigue haciendo en la PSBT de liquidación: salidas hacia el comercio, la plataforma, el referido, la comisión de puente y (si lo hay) el cambio. El reparto es determinista y visible on-chain en la transacción difundida. No está impuesto por script (el script de Bitcoin no puede calcular porcentajes), pero es observable y auditable.
  • La ruta de barrido de api/src/withdrawals/services/bitcoin-withdrawal-transfer.service.ts se mantiene, pero firma mediante la ceremonia del multisig en lugar de con una clave unilateral.

Qué queda fuera de alcance​

Suscripciones / cobro automático en BTC​

La documentación actual de Cobro automático ya indica que las extracciones de suscripción solo se admiten en EVM y Solana. Eso sigue siendo así tras la Fase 5.

No hay un equivalente creíble de extracción por allowance en la L1 de BTC:

  • No hay una primitiva estándar de allowance de tokens.
  • No hay un contrato general que pueda hacer transferFrom en nombre de un pagador.
  • Las secuencias de PSBT prefirmadas (una por periodo) existen en teoría, pero no ofrecen nada de la flexibilidad para cancelar o modificar que los pagadores esperan de una suscripción.

Fedimint, Cashu, statechains​

Investigación interesante; ninguna está en posición de convertirse hoy en un raíl de pagos de producción que podamos ofrecer a todos los comercios. Lo revisaremos cuando cambie la adopción.

La vía de Lightning​

Los pagos recurrentes en BTC tienen un único destino futuro realista: las ofertas BOLT12 de Lightning + la extensión recurrence. Eso daría a BTC un equivalente al approve + pull de ERC-20.

Dependencias (todas externas):

  • Implementaciones maduras de la recurrencia BOLT12 en los principales nodos LN (LND, Core Lightning).
  • Soporte de la recurrencia BOLT12 en las wallets que usan nuestros pagadores (Phoenix, Zeus, Blink, hardware wallets).
  • Liquidez: una flota de nodos LN o una red de socios con capacidad para los volúmenes previstos.
  • UX: la app de pago debe hacer que Lightning recurrente se sienta tan sencillo como approve(cap) en EVM.

Publicaremos un documento de diseño cuando la pila externa esté lista. Hasta entonces, BTC sigue siendo de pago único.

Detalles operativos​

Alta del comercio​

  • El comercio proporciona una xpub (una o dos: principal y, opcionalmente, de respaldo).
  • OrcaRail deriva claves del comercio por enlace a partir de la xpub; el comercio deriva las mismas claves en local para cofirmar.
  • Se recomienda encarecidamente una xpub de respaldo para cubrir la pérdida de la clave del comercio.

Recuperación ante la pérdida de claves​

  • El comercio pierde la clave principal y tiene respaldo: deriva desde el respaldo y continúa.
  • El comercio pierde ambas: los enlaces abiertos existentes no se pueden liquidar por el lado del comercio. Las PSBT de reembolso prefirmadas siguen funcionando (recuperación del pagador). Los enlaces nuevos requieren una xpub nueva.
  • Rotación de la clave de la plataforma (anual): todos los depósitos existentes siguen funcionando porque la clave antigua sigue siendo válida para esas direcciones concretas. Los enlaces nuevos usan la nueva ruta de derivación.

Conmutación por error del HSM o MPC​

  • El HSM de la plataforma se despliega de forma redundante en varias regiones.
  • La alternativa MPC añade un nivel de firmante más, pero también complejidad; la estamos evaluando durante el diseño de la Fase 5.
  • El runbook de conmutación de emergencia está documentado y se ensaya cada trimestre.

Gas / mercado de comisiones​

  • La PSBT de liquidación paga la comisión en el momento de la difusión. La interfaz de cofirma muestra la tasa de comisión actual y señala los valores inusualmente altos.
  • Hay un hook CPFP (child-pays-for-parent) disponible si una transacción de liquidación se queda atascada en la mempool.

Postura regulatoria​

Con firmantes del comercio en cada enlace, los pagos en BTC en OrcaRail se parecen mucho más a un procesador de pagos normal y mucho menos a una custodia:

  • Ninguna parte controla los fondos por sí sola.
  • El pagador siempre puede recuperar sus fondos mediante la PSBT de reembolso prefirmada.
  • La plataforma nunca ve la clave privada en bruto en ningún servidor.

Esto simplifica sustancialmente el cumplimiento normativo en la mayoría de jurisdicciones, pero no elimina los requisitos de registro en todas partes. Consulta con un asesor legal local.

Consulta también​