Construyendo el futuro con Bitcoin

Lo último de Strike

Hoy estamos emocionados de anunciar el lanzamiento del renovado programa de referidos de Strike, que es simple, gratificante y está enfocado en ayudarte a aprovechar al máximo Bitcoin. Ahora, cuando tu amigo se une a Strike y compra Bitcoin, ambos reciben $500 (o €500) en stacking sin comisiones.

Los referidos ahora están disponibles para clientes en EE. UU. y la UE. Actualiza tu aplicación a la última versión o [descarga Strike](https://strike.me/es/download) para comenzar.

## Más Bitcoin, Menos Comisiones
En Strike, creemos en hacer que Bitcoin sea accesible para todos, en todas partes. Con nuestra nueva experiencia de referidos, estamos emocionados de permitir que nuestros clientes lleven a más personas a Bitcoin mientras son recompensados en el proceso.
Nuestro programa de referidos se enfoca en darte la mayor cantidad de Bitcoin, ahorrándote comisiones con cada referido exitoso para que puedas acumular más sats y compartir Strike con otros. 

**Así es como funciona:**

Cuando un amigo se une a Strike con tu código de referido y compra bitcoin, ambos reciben $500 (o €500) en stacking sin comisiones, que se puede aplicar a compras únicas, compras recurrentes o pedidos específicos.

¿La mejor parte? No hay límite en el número de referidos. Puedes invitar a tantos amigos como quieras y seguir ganando stacking sin comisiones.

![](https://www.datocms-assets.com/99305/1728428108-blog_better-referrals.png)

## Invita a un Amigo
Referir es fácil, simplemente sigue estos pasos:

1. Ve a la pantalla de Cuenta y presiona “Invita a amigos, intercambia sin comisiones.”
2. Comparte tu código de referido
3. Tu amigo se registra con tu código de referido
4. Tu amigo compra bitcoin con efectivo depositado o mediante un método de pago vinculado
5. Ambos reciben $500 (o €500) en transacciones de bitcoin sin comisiones

Puedes rastrear el estado de tus referidos en cualquier momento desde la pantalla de Cuenta.

Consulta nuestras Preguntas Frecuentes para obtener más detalles sobre nuestro [programa de referidos](https://strike.me/es/faq/what-is-the-strike-referral-program/) y cómo [usar un código de referido](https://strike.me/es/faq/how-do-i-use-a-referral-code/).

## Gracias

Gracias por tu continuo apoyo y confianza en Strike. Nos dedicamos a desarrollar funciones que aporten valor real a nuestros clientes. Con este nuevo programa de referidos, creemos que estamos creando una experiencia más fluida y centrada en Bitcoin, ayudándote a acumular más sats mientras compartes la experiencia de Strike con tus amigos.

Estamos emocionados de seguir construyendo y haciendo crecer la comunidad de Strike. ¿Tienes una idea para una función? ¡Nos encantaría saber de ti!

Presentamos nuestro nuevo programa de referidos para clientes en EE. UU. y la UE

Anunciamos el Programa de Referidos de Strike

Yo! Hoy estoy emocionado de anunciar nuestro nuevo y mejorado sistema de límites. **Hoy presentamos una experiencia de límites rediseñada, permitiéndote enviar y retirar todos tus bitcoin en tus propios términos, y mucho más**.

https://www.youtube.com/watch?v=h7JCxuBTmQQ

Estos cambios están comenzando a implementarse ahora y estarán disponibles para todos los usuarios en el próximo mes. Estarán activos en tu aplicación cuando el botón "Saldo de Bitcoin" aparezca debajo del monto de bitcoin en tu pantalla de inicio. ¡Échale un vistazo!

![](https://www.datocms-assets.com/99305/1711560516-image.png)

## La Historia
Mejores Límites. Eso es todo lo que los clientes de Strike quieren. Te escuchamos fuerte y claro.

Como una empresa enfocada exclusivamente en Bitcoin, nuestro objetivo es simple: empoderar a nuestros clientes para que tengan propiedad de su dinero. Queremos ayudarte a entrar y salir de bitcoin y no queremos interponernos con barreras innecesarias.

En los últimos meses, hemos estado trabajando arduamente en rediseñar nuestro sistema de límites desde cero con tus comentarios en mente. Queríamos construir una experiencia fluida para mover moneda fiduciaria a Strike, intercambiarla por bitcoin y mover tus bitcoin a auto-custodia mientras navegamos por las deficiencias de las vías de pago tradicionales. Para ser sinceros, esto no fue fácil. El sistema fiat está roto, lo que hace que sea un desafío hacer que la infraestructura de pago heredada sea interoperable con la tecnología de Bitcoin, especialmente a escala global. Pero estábamos listos para el desafío. 

![](https://www.datocms-assets.com/99305/1711417030-better-limits-launch-03-tweets.png)

## Renovando Nuestro Sistema de Límites
Anteriormente, los límites de envío y retiro eran fijos en una base diaria y semanal (como $2,000 por semana) y había una visibilidad limitada sobre cuáles eran tus límites reales en un momento dado. Esto era un gran dolor de cabeza, especialmente para los usuarios que transaccionaban grandes cantidades de bitcoin, retirando a auto-custodia o enviando a otras plataformas.

Además, había preguntas sobre las transferencias bancarias: cuánto tiempo toma para que los fondos se depositen o "liquiden" en tu cuenta de Strike, y cuándo puedes enviar o retirar los bitcoin que compraste con esos fondos.

Los períodos de liquidación son una de las muchas ineficiencias con la infraestructura de pago heredada. Las transferencias bancarias pueden tardar varios días hábiles en depositarse o liquidarse en tu cuenta de Strike, dependiendo del banco. Por ejemplo, cuando compras bitcoin con una transferencia bancaria, puede tomar hasta varios días hábiles para que los fondos se liquiden en tu cuenta de Strike. Mientras Strike te permite comprar bitcoin inmediatamente con tu depósito bancario, debemos recibir realmente los fondos de tu banco antes de que puedas enviar o retirar tus bitcoin.

Para abordar estos puntos de dolor, hemos renovado completamente nuestro sistema de límites para darte más claridad, acceso y control sobre tu dinero, sin importar dónde te encuentres en el mundo y qué moneda uses. 
 
## Mejores Límites
Nuestro nuevo sistema de límites está diseñado para permitirte enviar y retirar todos tus bitcoin tan pronto como tus fondos estén disponibles. ¡Dile adiós a todos los límites semanales de envío y retiro!

Los límites ahora se determinan por dos factores clave:
* Saldos pendientes y disponibles
* Métodos de pago

### Saldos Pendientes y Disponibles

Ahora puedes enviar, gastar y retirar todos tus fondos disponibles por completo, ¡inmediatamente! Los fondos pendientes pueden ser enviados, gastados o retirados por completo una vez que estén disponibles. Mientras tanto, puedes comerciar bitcoin con depósitos pendientes.

**¿Qué son los saldos "pendientes" y "disponibles"?**

Tu "saldo pendiente" muestra los depósitos que están pendientes de disponibilidad. Estos depósitos generalmente tardan unos días hábiles en liquidarse y pueden estar sujetos a días adicionales de retención según el historial de depósitos de tu cuenta, saldos y estado. Puedes usar los fondos inmediatamente para comprar bitcoin dentro de la aplicación. Una vez que los fondos estén disponibles, también tendrás la opción de enviarlos o retirarlos de la plataforma. Es nuestra forma de mantener las cosas fluidas y seguras, mientras te damos acceso inmediato a tus fondos para comprar bitcoin.

Tu saldo disponible es la cantidad que puedes enviar, gastar o retirar de inmediato. Es tu saldo, menos tus depósitos pendientes que no están cubiertos por los fondos en tu cuenta. Una vez que tus depósitos pendientes se hayan liquidado, tus fondos estarán completamente disponibles para todas las transacciones, incluyendo comprar, retirar y enviar bitcoin.

Ahora puedes ver claramente tus saldos pendientes y disponibles en tus pantallas de Saldo de Bitcoin y Saldo de Efectivo. Ahora siempre sabes el estado de tu depósito, qué fondos están disponibles o pendientes, y tus límites totales.

![](https://www.datocms-assets.com/99305/1711417048-better-limits-launch-05-strike-instant.png)

**Así es como funciona:**
* Deposita fondos en Strike.
* Compra bitcoin instantáneamente desde tu "saldo pendiente" mientras tu depósito en efectivo se está procesando.
* Envía y retira la cantidad que quieras de tu bitcoin desde tu "saldo disponible" tan pronto como los fondos de tu depósito en efectivo estén disponibles.

Ten en cuenta que los bitcoin recibidos de otras plataformas se pueden retirar instantáneamente.

Puedes aprender más en nuestras [Preguntas Frecuentes](https://strike.me/es/faq/what-are-my-available-and-pending-balances/)

### Métodos de Pago

Si quieres comprar bitcoin y retirarlo o enviarlo instantáneamente, recomendamos usar métodos de pago que se liquiden rápidamente, como tarjeta, transferencias bancarias y depósitos directos. Las transferencias bancarias y depósitos directos no tienen límites: puedes comprar tanto bitcoin como desees, y retirar o enviar la cantidad completa tan pronto como Strike lo reciba.

![](https://www.datocms-assets.com/99305/1711560835-image-1.png)

Las transacciones asociadas con transferencias bancarias están sujetas a un período de liquidación y típicamente están disponibles para retiro dentro de varios días hábiles, tan pronto como los fondos se hayan liquidado, y pueden estar sujetas a días adicionales de retención según el historial de depósitos de tu cuenta, saldos y estado.

Como siempre, házmelo saber si necesitas algún apoyo con tus límites en Strike. ¡Estoy feliz de ayudarte a comprar y mover tanto bitcoin como desees! Puedes enviarme un mensaje directo en Twitter/X [@jackmallers](https://twitter.com/jackmallers) o enviarme un correo electrónico a private@strike.me.

## Strike Instant

Como Bitcoiners, creemos que las transacciones deberían ser instantáneas y que deberías tener acceso a tu dinero cuándo y cómo lo desees. Esperar transferencias bancarias y períodos de liquidación, un producto de la infraestructura de pago anticuada, es increíblemente frustrante. Pero no hacemos las reglas. Bueno, en cierto modo.

Con Strike Instant, podemos dar a nuestros usuarios más leales acceso instantáneo para comprar, enviar y retirar todos tus bitcoin instantáneamente, mientras el dinero está en camino desde el banco. Es simple. Cuando depositas efectivo, puedes usar inmediatamente los fondos para cualquier transacción, incluso mientras el depósito aún está pendiente, basado en la buena fe de que tus transferencias serán completadas.

Es nuestra forma de agradecer a nuestros leales usuarios de Strike, dándote acceso a tus bitcoin más rápido.

Strike Instant está disponible para usuarios cuyas cuentas están en buen estado, incluyendo el historial de depósitos de tu cuenta, saldos y estado. La cantidad de bitcoin que puedes enviar y retirar instantáneamente puede estar sujeta a límites y variar según la actividad de tu cuenta y la cantidad de fondos depositados. Puedes aprender más en nuestras [Preguntas Frecuentes](https://strike.me/es/faq/what-is-strike-instant).

![](https://www.datocms-assets.com/99305/1711417039-better-limits-launch-04-better-limits.png)

## Gracias
Gracias por ser un cliente, gracias por el apoyo y gracias por los comentarios honestos. Estamos muy agradecidos de estar trabajando en Bitcoin y hacer que Strike sea lo mejor posible para todos ustedes.

Hay mucho más por venir. Si necesitas algo mientras tanto, no dudes en contactarnos.

Hablamos entonces. Mucho amor.

Jack

Compra, vende, envía y retira bitcoin en tus propios términos

Anunciando Mejores Límites

Strike tiene la misión de integrar al mundo a un mejor sistema monetario. Los servicios que hemos creado están diseñados para pagos rápidos, de bajo costo y sin complicaciones a través de la red Bitcoin. Una de las técnicas principales que utilizamos para lograr esto es la agrupación de pagos de bitcoin on-chain.

![](https://www.datocms-assets.com/99305/1721871514-batching-on-chain-sends-hero.png)

En este artículo, exploraremos cómo funciona nuestro sistema de agrupación on-chain, los matices que lo hacen efectivo y algunos de los desafíos técnicos que hemos superado para asegurar que nuestros usuarios reciban un servicio de primera calidad.

## Servicios de Pago On-chain por Niveles<a id="tiered-on-chain-payment-services"></a>

En Strike, ofrecemos un [servicio por niveles](https://strike.me/es/faq/can-i-speed-up-my-bitcoin-send/) para enviar pagos on-chain:

* **Nivel Flexible (Gratis):** Para aquellos dispuestos a esperar de 12 a 48 horas
* **Nivel Estándar:** Para envíos más rápidos, pero asequibles
* **Nivel Prioritario:** Para transacciones que no pueden esperar, buscando confirmación en el próximo bloque

Este enfoque por niveles nos permite atender diferentes necesidades y preferencias de los usuarios, equilibrando efectivamente el costo y la velocidad. Ofrecer tanto envíos on-chain ilimitados y gratuitos como transacciones para el siguiente bloque a todos nuestros usuarios plantea una serie de desafíos técnicos. Necesitamos un sistema que pueda escalar a un número muy grande de usuarios, realizar pagos on-chain a volúmenes empresariales, mantener los costos de las comisiones asequibles y utilizar inteligentemente la liquidez en nuestras billeteras calientes.

## La Eficiencia de la Agrupación<a id="the-efficiency-of-batching"></a>

![](https://www.datocms-assets.com/99305/1721871507-batching-efficiency-visualization.png)

Agrupar múltiples pagos en una sola transacción grande reduce significativamente nuestra huella on-chain y mitiga algunos de nuestros desafíos de escalado. Este enfoque beneficia no solo a nuestros usuarios, sino también a la comunidad de Bitcoin al minimizar el uso de datos de nuestras transacciones, reduciendo así la congestión de la red y las comisiones. También significa que uno de nuestros [UTXOs](https://strike.me/es/learn/what-is-a-utxo/) (salidas de transacciones no gastadas, a veces denominadas "monedas") puede usarse para facilitar varios pagos on-chain para nuestros usuarios, lo cual es crucial para escalar nuestras operaciones.


## Ahorro de Costos a Través de la Agrupación<a id="cost-savings-through-batching"></a>

Al agrupar pagos, podemos ofrecer envíos on-chain más baratos en comparación con lo que los usuarios pagarían si enviaran transacciones individualmente. En la red Bitcoin, se paga por el tamaño de datos de tu transacción, en lugar de su valor financiero. Los ahorros de la agrupación provienen del tamaño reducido en bytes de las transacciones agrupadas en comparación con la publicación de múltiples transacciones individuales. Todas las transacciones on-chain contienen tanto datos fijos como variables. Los datos fijos incluyen información estándar para todas las transacciones, mientras que los datos variables incluyen las entradas de transacción (monedas a gastar en la transacción) y salidas (destino de las monedas), que pueden variar en número y tamaño. Al combinar múltiples transacciones individuales en una sola transacción agrupada grande, todas las salidas pueden compartir los mismos datos fijos y monedas de entrada, amortizando así sus costos.


## Mejorando Nuestro Sistema de Agrupación<a id="upgrading-our-batching-system"></a>

Strike ha estado agrupando pagos on-chain en nombre de nuestros usuarios durante bastante tiempo, y esto nos ha permitido ofrecer envíos on-chain a precios muy competitivos (¡incluyendo un nivel gratuito!). Sin embargo, recientemente hicimos una gran mejora en nuestro sistema de agrupación, que creemos reforzará nuestra posición como líder en Bitcoin. Al compartir nuestra nueva estrategia de agrupación contigo, queremos establecer las expectativas de lo que puedes esperar cuando usas Strike para realizar un pago on-chain, así como ayudar a otros desarrolladores compartiendo algunas lecciones que hemos aprendido mientras iteramos en nuestro servicio de pagos on-chain.


### Añadir Salidas a Transacciones No Confirmadas
<a id="append-outputs-to-unconfirmed-transactions"></a>

La actualización más reciente de nuestro sistema de agrupación proporciona la capacidad de añadir más salidas (receptores/destinos) a transacciones agrupadas no confirmadas existentes cuando sea posible. Esto se logra aprovechando una característica nativa de Bitcoin llamada Replace-By-Fee (RBF). RBF nos permite "reemplazar" transacciones no confirmadas aumentando la comisión que pagan. Lo importante es que las salidas no tienen que ser las mismas que en la transacción original, lo que nos permite agregar más salidas a transacciones no confirmadas existentes cuando sea necesario.
Aquí hay algunos enlaces para aquellos interesados en aprender más sobre RBF:
* [Wiki de RBF](https://en.bitcoin.it/wiki/Replace_by_fee) (Información general e historia)
* [Preguntas Frecuentes de Opt-In Full RBF](https://bitcoincore.org/en/faq/opt-in-full-rbf/)
* [BIP 125: Señalización de Opt-In Full Replace-by-Fee](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki)

Esta actualización nos permite manejar un aumento en las solicitudes de "Envío Prioritario" (nuestro nivel que apunta al próximo bloque descrito anteriormente) sin crear constantemente nuevas transacciones agrupadas. En su lugar, agregamos más salidas a nuestras transacciones agrupadas existentes que han sido transmitidas pero aún no confirmadas. Aquí está por qué esto es un cambio de juego:
1. **Reducción de la Huella On-chain:** Al minimizar el número de nuevas transacciones creadas, reducimos aún más la congestión en la red Bitcoin.
2. **Ahorro en Costos de Comisiones:** Menos transacciones agrupadas para la misma cantidad de pagos generalmente significa aún más ahorros en las comisiones on-chain de Bitcoin; generalmente vemos entre un 30 y 50% de ahorro de costos por transacción.
3. **Mejorada Calidad de Servicio (QoS):** Las transacciones agrupadas no confirmadas existentes se incrementan a la comisión de mercado actual como parte de la operación RBF. Esto asegura que nuestros usuarios experimenten una mejor calidad de servicio, ya que sus transacciones tienen más probabilidades de ser incluidas en el próximo bloque, independientemente de los picos de comisiones en la red.

*Ejemplo de una transacción agrupada on-chain, usando RBF para añadir salidas adicionales hasta que sea confirmada:*

![](https://www.datocms-assets.com/99305/1722324278-engineering_09-batching-on-chain-sends_txn.png)



## Desafíos Técnicos y Soluciones<a id="technical-challenges-and-solutions"></a>

Implementar este sofisticado sistema de agrupación requirió superar varios obstáculos técnicos:


### ¡Prevenir el Envío Doble!<a id="prevent-double-send"></a>

Usar RBF para añadir salidas extra requiere un manejo cuidadoso para evitar problemas de envío doble y asegurarse de que todas las salidas añadidas se contabilicen correctamente. Hay varias razones por las cuales el envío doble podría convertirse en un problema cuando empiezas a añadir salidas a transacciones a través de RBF. Esto no se debe a problemas en el protocolo Bitcoin, sino a que hay algunas trampas conceptuales que pueden surgir. Uno de los puntos principales es que necesitas manejar el caso donde los mineros confirmen una versión no más reciente de tu transacción agrupada. Cualquier candidato que hayas añadido después de esa versión necesita ser transferido a un nuevo lote. Pero si cometes un error aquí, podrías terminar enviando doblemente.


### Garantizar el Seguimiento de Transacciones<a id="guaranteeing-transaction-tracking"></a>

Asegurarnos de que no enviamos doblemente implica llevar un seguimiento meticuloso de qué transacciones han sido publicadas y monitorear qué versión de una transacción agrupada es confirmada. Este seguimiento cuidadoso nos permite transferir candidatos de versiones no confirmadas a nuevos lotes con precisión.

Pero, ¿qué pasa si tu software de billetera falla exactamente en el momento de publicar una nueva transacción RBF en la red Bitcoin? ¿Cómo sabrás si la transacción fue publicada?

Algunos software de billetera te darán el nuevo TxId como respuesta tras publicar exitosamente una nueva transacción. Este enfoque no es suficiente aquí, ya que podría resultar en que nunca aprendamos el TxId de una transacción que podría haber sido publicada y confirmada on-chain. Podríamos no recibir la respuesta que contiene el nuevo TxId debido a errores a nivel de red, fallos de software, etc., incluso si de hecho se transmitió una nueva transacción. Dado que todas nuestras versiones de transacciones contienen un conjunto diferente de salidas, es crucial que sepamos qué versión es confirmada para que podamos decidir si alguna salida añadida NO fue confirmada y por lo tanto necesita ser transferida a un nuevo lote.

Este problema general puede resolverse mediante un enfoque de 2 pasos:
1. Construye tu transacción y almacénala en tu base de datos.
2. Si el paso 1 tuvo éxito, intenta transmitir la transacción a la red Bitcoin.

Con este enfoque, el paso 2 se puede intentar nuevamente si encuentras algún problema. También tendrás la capacidad de monitorear la red Bitcoin para el TxId, para ayudar a determinar si la transacción fue publicada o no. La forma en que funcionan las transacciones de Bitcoin es que construir la transacción también significa construir el TxId. Este es un proceso completamente offline que puede ser realizado por tu software sin comunicación con el resto de la red Bitcoin.

### División de Cadena y Reorganización<a id="chain-split--reorganization"></a>

Otro caso a tener en cuenta es cuando las versiones de tu transacción agrupada están involucradas en [Divisiones de Cadena de Bitcoin](https://developer.bitcoin.org/devguide/block_chain.html#block-height-and-forking) (bifurcaciones temporales de la blockchain) y potencialmente la posterior reorganización de la blockchain. Sin entrar en detalles, esto podría significar que una versión de tu transacción agrupada inicialmente sea confirmada on-chain, pero poco después sea anulada y superada por otra versión de tu transacción agrupada.

Dado que todas las versiones de nuestras transacciones agrupadas contienen un conjunto diferente de salidas, y tomamos decisiones sobre qué salidas transferir a un nuevo lote en función de qué versión fue confirmada, este fenómeno también tiene el potencial de hacernos enviar doblemente. Las Divisiones de Cadena y Reorganizaciones son una parte importante del funcionamiento de la blockchain para garantizar el consenso, por lo que nuestros sistemas deben poder manejar esto. Una solución simple es hacer lo mismo que normalmente se hace para las recepciones on-chain; esperar hasta que la transacción tenga X (¡más de una!) confirmaciones on-chain antes de considerarla como final. En Bitcoin, ocasionalmente verás divisiones de cadena con una profundidad de un bloque, pero si tu transacción fue confirmada hace 6 bloques, generalmente se considera seguro contarla como "final".

### Estimaciones de Comisiones Apropiadas<a id="appropriate-fee-estimations"></a>

Usar [estimaciones de comisiones basadas en el mempool](https://strike.me/es/blog/blended-bitcoin-fee-estimations/) en lugar de estimaciones basadas en la blockchain es crucial para la QoS y la eficiencia de costos. Este enfoque asegura que las transacciones puedan entrar en el próximo bloque sin sobrepagar. Nuestro sistema monitorea continuamente nuestro mempool para elegir una comisión adecuada para cada transacción agrupada y cada RBF.


## Escalando Operaciones On-chain<a id="scaling-on-chain-operations"></a>

Nuestro sistema mejorado de agrupación nos posiciona para escalar nuestras operaciones on-chain a un nivel donde realmente podamos crecer para ser una empresa global con millones de usuarios activos. Nuestro sistema ahora nos permite manejar grandes aumentos en el volumen de nuestros usuarios sin comprometer la velocidad, el costo o la calidad del servicio.

### UTXOs: Un Recurso Escaso<a id="utxos-a-scarce-resource"></a>

Uno de los mayores desafíos con la escalabilidad de un servicio de envío custodial on-chain, mientras se sigue ofreciendo la opción de "Envío Prioritario", es la necesidad de mantener un stock de UTXOs que puedan usarse como entradas en tus transacciones para facilitar los pagos on-chain. Imagina tener que atender una solicitud de "Envío Prioritario" de tus usuarios cada segundo, mientras hay un mayor intervalo (por ejemplo, 1 hora) entre los bloques que se minan en la red Bitcoin. Si necesitas publicar instantáneamente todas estas transacciones, agruparlas no sería posible.

Sin embargo, supongamos que somos inteligentes y añadimos un ligero retraso de solo 5 segundos entre cada una de nuestras transacciones agrupadas. Esto significa que podemos agrupar 5 solicitudes juntas cada 5 segundos. Entonces, durante una hora en la que no se mina ningún bloque, necesitaríamos publicar 720 transacciones para facilitar las solicitudes de nuestros usuarios en este ejemplo. Dado que ninguna de estas transacciones se confirmaría durante esa hora, las salidas de cambio de estas transacciones no estarían disponibles para un uso seguro, lo que requeriría un stock de 720 UTXOs de tamaños apropiados en nuestra billetera caliente. Sin esto, nuestro servicio simplemente se detendría hasta que se mine un nuevo bloque. Esta situación se vuelve aún más complicada durante los picos de comisiones, que podrían hacer que las transacciones permanezcan no confirmadas por un período aún más largo.

Además, mantener UTXOs de un "tamaño apropiado" añade otra capa de complejidad. Por ejemplo, si todas las solicitudes de envío son de 1 BTC cada una, necesitaríamos mantener 720 BTC en nuestra billetera caliente, desglosados en UTXOs de 1 BTC cada uno. Esto no solo se vuelve complejo de gestionar, sino también ineficiente desde el punto de vista operativo y difícil de escalar. Por supuesto, es imposible predecir con 100% de precisión lo que harán tus usuarios, por lo que tu stock de UTXOs necesita ser aún más grande que esto para estar preparado para picos de demanda imprevistos. El problema fundamental aquí es que terminamos con muchas transacciones no confirmadas en el mempool simultáneamente, bloqueando numerosos de nuestros UTXOs.


### ¿Ejecutando el Sistema en un Solo UTXO?<a id="running-the-system-on-a-single-utxo"></a>

En lugar de publicar nuevas transacciones agrupadas cada 5 segundos como en el ejemplo anterior, nuestro nuevo enfoque añade más salidas a nuestra transacción no confirmada existente, si es que hay alguna. Esto proporciona una solución increíblemente eficiente al problema mencionado anteriormente. Añadir más salidas reutiliza la entrada UTXO existente de la transacción no confirmada, siempre que el UTXO sea lo suficientemente grande. Esto significa que, en teoría, todo nuestro sistema de agrupación podría ejecutarse en un solo UTXO.

Cada vez que una de nuestras transacciones agrupadas se confirma on-chain, recibimos la salida de cambio de vuelta como un nuevo UTXO, que luego puede usarse para financiar el siguiente lote. Este enfoque esencialmente escala infinitamente (¡o al menos hasta el límite de tamaño de bloque de Bitcoin!), permitiéndonos manejar un creciente volumen de solicitudes de envío on-chain sin estar limitados por el número de UTXOs en nuestra billetera caliente. También mitiga el riesgo asociado con los picos de comisiones, asegurando una operación continua incluso durante la congestión de la red.

A través de este sistema, logramos un nivel sin precedentes de escalabilidad y fiabilidad en nuestras operaciones on-chain. Esto posiciona a Strike para crecer y servir a una base de usuarios global con millones de usuarios activos, ofreciéndoles el mejor servicio posible en términos de velocidad, costo y fiabilidad.


## Superior QoS (Calidad de Servicio)<a id="superior-qos"></a>

Nuestro compromiso de proporcionar a nuestros usuarios el servicio de mayor calidad en la industria es evidente en nuestro enfoque hacia la agrupación de pagos on-chain. Los usuarios pueden confiar en que sus pagos serán manejados con el mayor cuidado, eficiencia y seguridad, ya sea que opten por un envío Flexible, Estándar o Prioritario.

Los picos de comisiones en la red Bitcoin son un problema común que afecta la calidad de otros proveedores. Es común publicar transacciones con una comisión lo suficientemente alta como para apuntar a una confirmación en el próximo bloque solo para ver luego que el mercado general de comisiones sube significativamente. En estos casos, es probable que las transacciones publicadas no se confirmen durante varias horas y podrían potencialmente quedar atascadas mucho más tiempo o ser podadas. El protocolo Bitcoin tiene soluciones para permitirte "incrementar comisiones" en tu transacción para resolver esto, pero no es algo ubicuo para todas las aplicaciones y billeteras, y no es común que las billeteras aumenten automáticamente la comisión de tu transacción en tales casos sin cobrarte más por ello. ¡Strike simplifica todo esto para ti y proporciona flexibilidad para usuarios con diversas preferencias de tiempo!

## Conclusión<a id="conclusion"></a>

En Strike, continuamente nos esforzamos por innovar y mejorar nuestros servicios. Nuestro sistema avanzado de agrupación para envíos on-chain es un testimonio de nuestra dedicación a la eficiencia y el servicio de alta calidad. Nuestro objetivo es ser los mejores en Bitcoin, y eso significa proporcionar a nuestros usuarios la mejor experiencia posible que los pagos de Bitcoin pueden ofrecer. Realmente creemos que nuestra experiencia de envío on-chain está bien encaminada hacia cómo los pagos on-chain funcionarán y deberían funcionar en el futuro. Sin embargo, siempre continuaremos iterando en nuestras soluciones para mejorarlas aún más y mostrarle al mundo todo lo que Bitcoin tiene para ofrecer.

No dudes en ponerte en contacto si tienes alguna pregunta o necesitas más detalles sobre nuestro sistema de agrupación on-chain y sus beneficios. Siempre estamos aquí para ayudar y proporcionar el mejor servicio posible a nuestros usuarios.


Calidad del servicio (QoS), eficiencia y seguridad

 Agrupación de Envíos On-chain 

Hoy, estamos anunciando [Strike Business](https://strike.me/es/business), la nueva plataforma líder para que las empresas compren y gestionen bitcoin. Strike Business ofrece custodia de clase mundial, servicios Lightning y on-chain, integraciones para desarrolladores y mucho más. En su núcleo, es un servicio enfocado en proporcionar a tu empresa un socio confiable para comprar bitcoin de manera asequible, confiable y sin límites.

![](https://www.datocms-assets.com/99305/1710435557-image-2.png)

Strike Business es para empresas de todos los tamaños e industrias. Servimos a operaciones de una sola persona, pequeñas empresas, oficinas familiares y compañías a escala empresarial por igual. Es para cualquier empresa que reconozca el valor de mantener y operar con Bitcoin como una forma de evitar la inflación arbitraria, acceder a pagos sin fronteras y tomar el control de sus finanzas.

Es tu solución para construir tu propia estrategia de Bitcoin.

Ya sea para transacciones, mantener bitcoin como activo de tesorería o para realizar pagos globales usando bitcoin, Strike Business proporciona a las empresas la misma experiencia de primer nivel que ofrecemos a nuestros clientes individuales. 

[Comienza](https://strike.me/es/business)

![](https://www.datocms-assets.com/99305/1710435582-image-5.png)

## Presentando Strike Business

Nuestros clientes empresariales tendrán acceso al nuevo Panel de Control de Strike Business para facilitar todos los servicios de Bitcoin. Los clientes de Strike Business pueden transferir dólares, comprar o vender bitcoin en segundos, enviar o recibir bitcoin a través de transacciones on-chain o Lightning, y luego mantener o retirar a su propia custodia. También puedes rastrear tu actividad comercial y de transacciones, así como generar y exportar informes detallados para fines contables.

Lo que tu empresa necesite hacer con bitcoin, está todo aquí. Creemos que somos uno de los servicios solo de bitcoin de menor costo y mejor calidad que ofrece capacidades Lightning y retiros on-chain gratuitos, y apenas estamos comenzando.

![](https://www.datocms-assets.com/99305/1710435573-image-4.png)

### Panel de Control de Strike Business

Nuestros clientes empresariales tendrán acceso al nuevo [Panel de Control de Strike Business](https://dashboard.strike.me/) para facilitar todos los servicios de Bitcoin. Los clientes de Strike Business pueden transferir dólares, comprar o vender bitcoin en segundos, enviar o recibir bitcoin a través de transacciones on-chain o Lightning, y luego mantener o retirar a su propia custodia. También puedes rastrear tu actividad comercial y de transacciones, así como generar y exportar informes detallados para fines contables.

Lo que tu empresa necesite hacer con bitcoin, está todo aquí. Creemos que somos uno de los servicios solo de bitcoin de menor costo y mejor calidad que ofrece capacidades Lightning y retiros on-chain gratuitos, y apenas estamos comenzando.

![](https://www.datocms-assets.com/99305/1710435565-image-3.png)

Puedes obtener más información sobre lo que Strike Business tiene para ofrecer en nuestras Preguntas Frecuentes en nuestro [sitio web](http://strike.me/es/businses). Si tienes alguna pregunta sobre asociarte con nosotros, contáctanos en onboarding@strike.me para una conversación sin compromiso sobre cómo podemos ayudar a tu empresa a acceder a bitcoin.

### Comisiones por Niveles
Las empresas necesitan servicios transparentes y asequibles. Nuestros clientes empresariales obtienen precios de alta calidad con una estructura de comisiones escalable, diseñada para reducir tus costos cuanto más bitcoin compres. Puedes obtener más información sobre las comisiones por niveles [aquí](https://strike.me/es/blog/from-spreads-to-fees-simple-transparent-and-cheap-pricing-for-bitcoiners/).

![](https://www.datocms-assets.com/99305/1710435589-image-6.png)

### Comienza
Nuestro proceso de incorporación está diseñado para ser simple, rápido y fácil. Completa el formulario en nuestro [sitio web]((https://strike.me/es/business)) o envía un correo electrónico a onboarding@strike.me y comenzaremos el proceso.

En Strike, estamos comprometidos a ser los mejores en Bitcoin y nuestro objetivo es dar a tu empresa acceso al mismo servicio de alta calidad que brindamos a nuestros clientes individuales. Estamos increíblemente emocionados de asociarnos con tu empresa en tu viaje con Bitcoin y aprender más sobre cómo podemos satisfacer todas tus necesidades relacionadas con Bitcoin.

Presentando la plataforma líder de Bitcoin y Lightning para que las empresas compren bitcoin

Anunciando Strike Business

En Strike, estamos innovando constantemente para ampliar los límites de Bitcoin y la Lightning Network (LN) y mejorar la experiencia de nuestros clientes. Hoy, estamos emocionados de anunciar nuestro soporte para [BOLT 12 Offers](https://bolt12.org/), una tecnología revolucionaria que permite una forma más privada, versátil y fácil de usar para enviar y recibir sats a través de la red Lightning de Bitcoin.

Esta publicación del blog profundiza en nuestro viaje de integración de BOLT 12 en Strike. Es una exploración técnica dirigida tanto a entusiastas de Bitcoin como a nuestros valiosos clientes.


## ¿Qué es BOLT 12?

Introducido en septiembre de 2020 por [Rusty Russell](https://x.com/rusty_twit), la [especificación BOLT 12](https://github.com/lightning/bolts/blob/f150782106ac604b8bb056dcd0c0cbe757274e1d/12-offer-encoding.md) proporciona una versión mejorada del actual estándar [BOLT11](https://www.bolt11.org/) para pagos en LN. Si estás familiarizado con [LNURL](https://github.com/lnurl/luds), ¡que Strike también admite! - entonces BOLT 12 debería sonarte familiar en la superficie. Habilita características que mejoran significativamente la experiencia en LN:

* **Códigos QR reutilizables:** A diferencia de las facturas BOLT11, que generalmente son de un solo uso, las ofertas BOLT 12 se pueden escanear y pagar múltiples veces. Esto los hace ideales para exhibiciones estáticas como en sitios web, volantes o carteles, eliminando la necesidad de generar y distribuir constantemente nuevas facturas.
* **Mayor seguridad para el usuario:** BOLT 12 utiliza mensajes onion, una técnica criptográfica que oculta el camino seguido por los pagos dentro de LN. Esto mejora la privacidad del usuario al dificultar el seguimiento del flujo de sats.
* **Funcionalidad avanzada:** BOLT 12 abre puertas a nuevas funcionalidades nativas como reembolsos o retiros estilo cajero automático que anteriormente eran imposibles en la Lightning Network sin el uso de capas complementarias como LNURL.


## Nuestro Viaje de Implementación de BOLT 12

Nuestra exploración de BOLT 12 comenzó con un documento de investigación interno que escribimos en septiembre de 2021. Nos intrigaron los posibles beneficios que BOLT 12 podría ofrecer para mejorar las experiencias de pago en LN.

Elaboramos planes para integrar la funcionalidad BOLT 12 en Strike, pero la naturaleza temprana de la propuesta en ese momento, el hecho de que pasaría mucho tiempo antes de que se [implementara en LND](https://github.com/lightningnetwork/lnd/issues/5594), combinado con varios otros factores nos obligó a reenfocar esfuerzos en otras funciones principales y jugar un juego de espera para dar tiempo a que las cosas evolucionen aún más.

Entre 2021 y 2022, los miembros de la comunidad Bitcoin continuaron iterando sobre las propuestas de BOLT 12, desarrollando implementaciones y promoviendo la tecnología. Mientras que algunas implementaciones de nodos Lightning fueron rápidas en integrarse, [LND](https://github.com/lightningnetwork/lnd), la implementación principal del nodo que usamos en Strike, adoptó un enfoque más cauteloso y deliberado, enfocándose más en la estabilidad del sistema central. El equipo de Lighting Labs desarrolló una hoja de ruta integral por fases para implementar BOLT 12, integrando algunos de los componentes fundamentales poco a poco durante un período de tiempo más largo. Hasta el día de hoy, LND todavía no admite BOLT 12 aunque ahora admite muchos de los componentes principales y está bien encaminado hacia el soporte completo nativo de BOLT 12.

Con la llegada de [LNDK](https://github.com/lndk-org/lndk) en marzo de 2023, una herramienta liderada por [Carla Kirk-Cohen](https://github.com/carlaKC) y desarrollada junto con el equipo de [Spiral](https://spiral.xyz/), nuestro interés en BOLT 12 se reavivó. Descrita como "un intento experimental de usar [LDK](https://lightningdevkit.org/) para implementar características de BOLT 12 para LND”, básicamente se conecta a las API existentes de LND para brindarnos la capacidad de aprovechar el soporte BOLT 12 integrado de LDK con LND, sin una revisión completa de nuestros sistemas.


## Profundización Técnica

La integración involucró varios componentes clave:

* **LND:** La API gRPC expuesta por el nodo LND de destino construido con los subservidores rpc apropiados.
* **LDK:** Importado como una dependencia en nuestra capa de aplicación para proporcionar capacidades de procesamiento y reenvío de mensajes onion.
* **LNDK:** Aunque la [visión general arquitectónica](https://github.com/lndk-org/lndk/blob/master/ARCH.md) de LNDK se refiere de manera lúdica a LNDK como "el monstruo de Frankenstein", en realidad es una solución muy ingeniosa. LNDK actúa como un [shim](https://en.wikipedia.org/wiki/Shim_$computing$), aprovechando la biblioteca modular lightning de LDK y conectándola a la API gRPC de LND. Esto nos permitió reutilizar la implementación BOLT 12 existente dentro de LDK.


## LNDK de un Vistazo

LNDK, el puente ingenioso que permite a Strike aprovechar la funcionalidad BOLT 12 dentro de nuestra infraestructura LND existente, merece una mirada más cercana. Aquí hay una descripción general de alto nivel de su arquitectura y algunas funcionalidades clave que lo hicieron una herramienta tan valiosa para nuestro proceso de integración.


## Diseño Modular para la Flexibilidad

Como se mencionó anteriormente, LNDK actúa como un shim, conectando la API gRPC de LND con la biblioteca modular Lightning de LDK. Este diseño ofrece varias ventajas:

* **Reutilización de Componentes:** Al aprovechar la implementación BOLT 12 existente de LDK, LNDK evita la necesidad de reinventar la rueda. Esto agiliza el desarrollo y garantiza la compatibilidad con el ecosistema más amplio de Lightning Network.
* **Separación Clara de Preocupaciones:** La separación entre la funcionalidad central de LND y el soporte BOLT 12 de LDK proporciona una implementación relativamente limpia que simplifica algunos elementos del mantenimiento.


## Mensajería Onion y Pagos de Ofertas

Una de las funcionalidades principales de BOLT 12 es el uso de [mensajes onion](https://rusty-lightning.medium.com/onion-messaging-in-depth-d8e384ee4184). Estos mensajes criptográficos permiten que dos nodos en la Lightning Network se comuniquen de forma segura y privada.

El siguiente diagrama muestra cómo interactúan los diversos componentes desde un alto nivel:

![](https://www.datocms-assets.com/99305/1722267398-engineering_09-02-onion-diagram.png)

Aquí tienes un desglose simplificado de cómo Strike utiliza LND, LDK y LNDK para facilitar el enrutamiento de mensajes onion y el protocolo BOLT 12:

1. **Solicitud de Pago:** El usuario de Strike inicia un pago escaneando un código QR de Oferta BOLT 12 o ingresando una dirección DNS legible por humanos desde donde se puede obtener una Oferta BOLT 12 usando [BIP 353](https://github.com/bitcoin/bips/blob/master/bip-0353.mediawiki).
2. **Análisis de Oferta LDK:** LDK se utiliza para analizar la Oferta BOLT 12 y extraer detalles del pago.
3. **Construcción de Mensaje Onion:** LNDK utiliza las bibliotecas de LDK y las API gRPC de LND para construir mensajes onion que contienen los detalles de la solicitud de factura.
4. **Reenvío del Onion:** El mensaje onion construido se retransmite a través de la Lightning Network por LND, atravesando varios nodos hasta llegar al nodo de destino especificado en la Oferta, donde el mensaje onion se desempaqueta, revelando la solicitud incrustada en el mensaje.
5. **Recuperación de una Ruta Ciega:** El nodo de destino utiliza mensajería onion para enviar una factura que incluye una ruta ciega que detalla cómo puede ser pagada.
6. **Envío del Pago:** LNDK interactúa con la API gRPC de LND para iniciar el proceso de pago.

El siguiente diagrama muestra el flujo de pagos desde un alto nivel:

![](https://www.datocms-assets.com/99305/1722267427-engineering_09-03-offers-flow.png)


## Plan de Implementación por Fases (3 Fases):

Dado el número de partes móviles, comenzamos delineando un enfoque en tres fases para implementar la funcionalidad BOLT 12 dentro de Strike. A grandes rasgos, el plan fue el siguiente:

1.** Pruebas e Implementación de LNDK:** Establecer la infraestructura y funcionalidad central de BOLT 12 para pruebas internas y observación.
2. **Integración de Plataforma y API de LNDK:** Extender la plataforma y las API de Strike para exponer la funcionalidad BOLT 12 en todo nuestro entorno.
3. **Integración de Aplicaciones de Strike:** Integrar las funciones de pago BOLT 12 en los productos de Strike.

Al seguir este enfoque por fases, combinado con conocimientos de nuestras investigaciones anteriores, sentimos que podríamos garantizar una integración controlada y eficiente de la funcionalidad BOLT 12 dentro de Strike.


## Implementación del Concepto de Prueba

El primer paso fue pasar del concepto a la prueba de concepto, y tuvimos que superar varios obstáculos técnicos en el camino.

**Área de Pruebas BOLT 12**
Establecimos un entorno de desarrollo para probar pagos BOLT 12 utilizando diversas combinaciones de nodos (LND, CLN, Eclair y LNDK) y canales (directo, salto único, multi-salto, saltos entre implementaciones). Elegimos hacer de código abierto nuestro nuevo [Área de Pruebas BOLT 12](https://github.com/LN-Zap/bolt12-playground) para ponerlo a disposición de la comunidad de desarrollo más amplia. Este área de pruebas resultó invaluable para agilizar el proceso de pruebas y facilitar la colaboración entre Strike y la comunidad de desarrollo de Bitcoin.

**Integración de API**
Trabajamos estrechamente con el equipo de Spiral y los contribuyentes de LNDK para mejorar LNDK con un servidor gRPC e implementación TLS que proporcionara una interfaz bien definida y segura para que nuestra aplicación interactúe con la funcionalidad subyacente BOLT 12 expuesta por LNDK.

**Decodificación Nativa de BOLT 12**
Aprovechamos las [bindings de C# generadas por LDK](https://github.com/lightningdevkit/ldk-garbagecollected) para habilitar la decodificación de Ofertas y Facturas BOLT 12 directamente dentro de nuestra base de código .NET, lo que nos permitió limitar nuestras interacciones con el daemon LNDK a favor de rutas de código nativas donde fuera posible.

**Desafíos y Soluciones Alternativas**
Trabajando estrechamente con los desarrolladores de LDK y LNDK, pudimos abordar cualquier problema que encontramos en el camino para llevar estas bibliotecas a un estado más estable. Se lanzaron múltiples nuevas versiones de LNDK, LDK y las bindings de C# de LDK en el camino, hasta que tuvimos toda la funcionalidad necesaria funcionando como necesitábamos.

**En Adelante...**
En pocos días, teníamos un concepto de prueba funcional que demostraba la capacidad de pagar Ofertas BOLT 12 directamente desde nuestros sistemas backend de Strike. Con este éxito, nos sentimos seguros para avanzar en la producción de la solución.


## De Prueba de Concepto a Producción

El siguiente desafío, ciertamente más lento, involucró transformar la prueba de concepto en un sistema robusto y seguro listo para su uso en el mundo real dentro del entorno de producción de Strike. Aquí proporcionamos algunas ideas sobre el esfuerzo de ingeniería:

**Producción de LNDK**
Participamos activamente en dar forma a muchas características de LNDK para asegurarnos de que cumpliera con nuestros requisitos de seguridad y tuviera la flexibilidad necesaria para ser utilizado en nuestro entorno de producción. Esto implicó varias iteraciones en el diseño, que finalmente resultaron en una interfaz gRPC asegurada por TLS y aprovechando un LND macaron con alcance limitado para autenticación. También agregamos puntos finales más granulares para cada fase del flujo BOLT 12.

**Despliegue de Infraestructura**
Desplegamos nodos LNDK en toda nuestra infraestructura utilizando un enfoque multifacético:

* Empaquetamos las dependencias y configuraciones necesarias para ejecutar LNDK dentro de un contenedor Docker.
* Creamos un gráfico Helm para facilitar el despliegue y gestión de nodos LNDK dentro de nuestro entorno Kubernetes.
* Aprovechamos Terraform para aprovisionar los recursos de infraestructura necesarios para ejecutar los nodos LNDK.
* Desplegamos un pod LNDK para cada uno de nuestros nodos LND existentes, asegurándonos de que cada instancia de LND tenga un contraparte dedicado de LNDK para manejar BOLT 12.

**Soporte de Mensajería Onion en LND**
Nuestros nodos LND estaban ejecutando la versión 0.17, que carecía de soporte integrado para mensajería onion, un componente crítico para la funcionalidad BOLT 12 de LNDK. Como no estábamos listos para actualizar a LND v0.18 en ese momento, optamos por retroportar el conjunto de cambios relevante de v0.18 a v0.17. Esto aseguró la compatibilidad con BOLT 12 mientras mantenía la estabilidad dentro de nuestra infraestructura existente. En el proceso, pudimos ayudar a dar forma al lanzamiento de LND 0.18, (que estaba en su fase RC final en ese momento), asegurándonos de que se lanzara con [todo lo necesario para admitir mensajes onion](https://github.com/lightningnetwork/lnd/pull/8744) desde el principio.

**Código de Aplicación Listo para Producción**
Nuestro código monolítico de prueba de concepto experimentó una transformación significativa. La base de código se dividió en componentes más pequeños y enfocados. Esto mejoró la capacidad de mantenimiento y facilitó una integración más fluida con la arquitectura existente de Strike. A un alto nivel, esto comprendió:

* Agregar bibliotecas de soporte como un Analizador BOLT 12, una implementación de [DNSSEC](https://http-dns-prover.as397444.net/) para búsquedas DNS seguras y una fachada gRPC para interactuar con el servidor gRPC de LNDK.
* Integración con nuestro grupo de nodos LND existente para gestionar las conexiones de nodos LND y distribuir la carga a través de nuestros sistemas.
* Finalmente, integrar toda la solución con nuestros sistemas principales, API y productos empresariales y de consumo para habilitar pagos BOLT 12 desde Strike.


## El Futuro de BOLT 12 en Strike

Aunque hemos logrado con éxito nuestro objetivo de habilitar pagos BOLT 12 básicos dentro de Strike, esto es solo el comienzo. Nuestra integración inicial de BOLT 12 admite el flujo de pago de ofertas más básico, pero allana el camino para características BOLT 12 más emocionantes y avanzadas con el tiempo.

* **Experiencia de Usuario Mejorada:** Los usuarios pueden beneficiarse de códigos QR reutilizables, privacidad mejorada a través de mensajes onion hoy, y en el futuro esperamos habilitar funciones más avanzadas como reembolsos y retiros a medida que el ecosistema BOLT 12 madura.
* **Innovación Continua:** Estamos comprometidos a permanecer a la vanguardia de la innovación de la Lightning Network. Continuaremos trabajando con la comunidad más amplia para ampliar los límites de LN e integrar tecnologías emergentes como BOLT 12 para brindar a nuestros usuarios la mejor experiencia posible.

Esperamos que esta publicación del blog proporcione una mirada interesante detrás de escena de nuestro viaje de integración de BOLT 12. Como puedes ver, en nuestro caso la implementación requirió una cantidad considerable de trabajo dado que estábamos abriendo camino y ayudando a desarrollar LNDK en el proceso. Sin embargo, con gran parte de este trabajo preliminar ya hecho y disponible en el universo de código abierto, hemos demostrado que existe un camino viable para implementar BOLT 12 para los usuarios de LND. Y para los usuarios de otras implementaciones de nodos como CLN y Eclair, estas capacidades también están disponibles.

Estamos emocionados de ver la evolución continua de BOLT 12 a medida que más servicios y operadores de nodos actualizan en los próximos meses y años.

Si tienes alguna pregunta, ¡no dudes en ponerte en contacto con nosotros!

Una mirada detrás de escena

Integrando BOLT12 en Strike

Haz tu movimiento hacia Bitcoin.

Blog

### 

As software engineers, we continuously evolve how we build. This is as true in the age of AI as it was in the past. As underlying models become more capable, our relationship with AI is shifting - from using it as a tool to write code, to building software factories that build features for us. We are promoting agents to a first-class core part of the team.

The core challenge is simple: how can we drastically reduce effort and do more with less? By isolating early experiments, we create sandboxes to refine this factory model without disrupting existing workflows.

> **The Core Shift:** What we’re finding is a fundamental shift in where we spend our time. We spend heavily on alignment upfront, and heavily on human-in-the-loop review at the end. The middle - the actual writing of code - compresses from days to hours.
>


## The New Bottleneck: Correctness and Review

If writing code is no longer the bottleneck, what is? When an agent can run overnight, the constraint shifts entirely to **review burden and correctness**. 

If the output is too large, the team bogs down in context switching. If the output is low quality, we spend too long modifying it. Setting an agent running overnight on a probabilistic build only to find it built the wrong thing burns our most limited resource: human time. To maintain velocity, agent output needs to be right-sized and largely correct.

If the team is spending days refining agent output, the solution isn't to work harder on human code review - it's to improve the factory. To protect human time, we baked rigorous review directly into the refinement loop:

- **The Agent Council**: A human is no longer assigned to review a pull request until it has survived an automated multi-agent review cycle checking spec adherence, correctness, and security.
- **Codified Seniority**: We had agents analyse months of historic PR comments from our domain experts. Now, a custom skill reviews the feature using the exact same lens as our senior team members.
- **Smart Orchestration**: We use stronger models as coordinators and weaker models for simpler tasks, running multiple agents in parallel to handle the heavy review burden efficiently.
- **Deterministic Guardrails**: Because our codebase enforces semantic correctness at build time, we invest heavily in adding deterministic guardrails like new Roslyn analysers to catch issues before the agent even commits.

![The agent council - findings feed back into the build before the PR is even raised](https://www.datocms-assets.com/99305/1785148815-agent-council.png)

As a result, the team's focus shifts. Instead of just writing feature code, we also spend an time on continuous improvement of the factory that builds the code - refining agent instructions, building new skills, and using evals to rigorously verify quality.

## Alignment: The "Grilling" Process

If you want 90% correctness on the first pass, you can't throw a vague issue at an agent. Agents can't read your mind; unspecified details become inferred assumptions. 

To prevent this, we lean heavily into **"grilling"** (a nod here to [Matt Pocock](https://github.com/mattpocock/skills), who popularised the term). It's an intense, iterative discovery process where the agent interrogates the team to tease out hidden requirements, edge cases, and architectural constraints. We get the knowledge out of our heads and onto paper before a single line of code is written. 

**Waterfall design, Agile feedback** Like Waterfall, we spend heavily upfront to write deep, end-to-end specifications. But because the build phase compresses from weeks to hours, the cost of mistakes plummets. If we build the wrong thing, we throw the code away, adjust the spec, and have the agent rebuild it while we sleep. We get the rigour of deep design combined with the fast feedback loops of Agile.

This demand for upfront alignment is expanding upstream. Because writing code is no longer the long pole, the cost of entering a project with unclear information is magnified by agent rework. The product team now uses agentic sessions from conception to grill stakeholders, convert unknown unknowns into knowns, and gain deep alignment before engineering even begins.

## Structure: Vertical Tracer Bullets

Once alignment is locked, we structure execution using **vertical slices**. While this isn't a net-new concept, our norm has usually been building horizontally and integrating later. In an agentic workflow, vertical slicing becomes paramount.

Instead of building horizontal components, we build fully baked features end-to-end. A vertical slice extends through every part of the system, from unit tests up to the CLI. 

This is crucial because it allows the agent to test its own work. The agent doesn't just write code; it runs the deployed application and interacts with it like a user. The agent *is* the feedback loop. By experiencing the system in the flesh, it discovers what works and iterates until the feature functions as designed. When human team members finally review, we can experience and verify the product the exact same way.

![Horizontal slicing vs vertical tracer bullets - each slice extends through every part of the system](https://www.datocms-assets.com/99305/1785147792-tracer-bullets.png)

## Friction and Adaptation

Moving fast as a solo dev is one thing, but operating enterprise financial software at scale is another. We're not offloading understanding to our agents; we're offloading grunt work. We want to take out the middle layer so we can focus on building solutions and making decisions.

To make this work across a larger team, we have to continuously adapt:

- **Strict WIP Limits over Parallelisation:** Running multiple slices concurrently fails. When agents encounter issues, they autonomously suggest or make improvements to our factory. Running parallel slices means agents build from the same flawed base and miss each other's learnings. A strict WIP limit of one ensures the next slice benefits from the absolute latest environmental upgrades. It's "one-piece flow": doing one thing start-to-finish is faster than doing many things at once.
- **Group Reviews over Solo Handoffs:** Solo engineers reviewing agent output leads to a slow loop of pinging domain experts. We adapt by moving to group reviews - getting on a call, going through the PR together, and writing actionable comments for the agent to fix.
- **Agents for Understanding:** We still read and review every line, but we also leverage agents to generate HTML artifacts and one-pagers that explain high-level concepts, helping break people into new domains.
- **Right-Sizing Tasks:** We initially mapped backends into large slices, but quickly realized they are often too big to digest efficiently overnight. We move to right-sizing, breaking them into smaller, tighter chunks. There is no one-size-fits-all; we adjust boundaries continuously based on lessons from previous slices.

## The Strategy is Continuous Adaptation

These adaptations work. As we right-size our tasks, move to group reviews, and enforce strict WIP limits, the pace picks up and the review burden drops. The trajectory becomes clear: building the factory is the natural output of the learning process, followed by a sharp ramp in velocity once the refinement loop clicks into gear.

The biggest takeaway is that **we need to treat the "software factory" as a first-class product**. We are still in the proving process, but our energy is shifting from writing feature code to improving the system that writes it.

![The continuous adaptation loop - humans and agents](https://www.datocms-assets.com/99305/1785161854-adaptation-loop-v2-article.png)

We don't know exactly what the Strike software factory will look like in three or six months, and that is the point. The agentic environment changes rapidly, and trying to predict its exact shape is a losing game. Our job is to adapt with it - picking up new tools, adjusting our workflows, and continuously defining our own way of building. **The strategy isn't a locked-in process; the strategy is continuous adaptation.**

AI agents as a first-class part of the team

Building the Strike Software Factory

Agent workflows are messy. Every provider has a different way to store skills, rules, MCP configs, commands, subagents, and hooks. We think agents should be a tool choice, not a lock-in. Environments should work the same locally and in the cloud, whether you're using GitHub Copilot, Claude Code, or Gemini.

Agent Playground is our reference template for portable agent environments. It standardizes configuration, tool access, and setup so you can define once and run with parity everywhere.

https://github.com/LN-Zap/agent-playground

## Design principles

We had a few non-negotiables:

- **Portability over lock-in** - engineers can use the tool that fits their job.
- **Single source of truth** - configs defined once and only once.
- **Reproducibility** - local, CI, and cloud share the same environment.

If a new agent harness shows up tomorrow, we should be able to add it without rewriting everything else.

## How it works

### 1. Centralized config with rulesync

[rulesync](https://github.com/dyoshikawa/rulesync) lets us store skills, rules, MCP configuration, commands, subagents, and hooks in a provider-agnostic format.

![](https://www.datocms-assets.com/99305/1771601602-agent-playground-rulesync.jpg)

A single config declares the agent targets to support and the remote skills to pull in.

```json
{
  "targets": [ "copilot", "claudecode", "opencode" ],
  "features": [ "mcp", "rules", "skills", "subagents" ],
  "sources": [ {
    "source": "https://github.com/anthropics/skills",
    "skills": [ "skill-creator" ]
  } ]
}
```

The outputs are regenerated deterministically from source.

```text
.
├── rulesync.jsonc    # Config
├── rulesync.lock     # Lockfile
└── .rulesync/        # Canonical source
    ├── mcp.json      # Shared MCP
    ├── rules/        # Project rules
    └── skills/       # Pinned skills
```

### 2. Pinned skills via lockfiles

Pulling unpinned remote code is a security risk. We upstreamed lockfile support to rulesync ([PR link](https://github.com/dyoshikawa/rulesync/pull/1032)) to pin installs to specific commit hashes.

A `rulesync.lock` file keeps the environment reproducible:

```json
{
  "lockfileVersion": 1,
  "sources": {
    "anthropics/skills": {
      "requestedRef": "main",
      "resolvedRef": "1ed29a03dc85...",
      "resolvedAt": "2026-02-17T09:49:59.986Z",
      "skills": {
        "skill-creator": {
          "integrity": "sha256-e141..."
        }
      }
    }
  }
}
```

When we update a skill, the workflow is deliberate:

1. Run `rulesync install --update` to fetch code and update lockfile.
2. Review the diff in the "curated" source directory during the PR process.
3. Merge only after vetting the upstream code for security issues.

This makes the agent supply chain as auditable as the rest of our stack.

When we run in cloud environments, the workflow is deterministic:

1. Run `rulesync install --frozen` to pull reviewed, locked code.
2. The process aborts if the sources drift from the lockfile hashes.

This ensures zero drift between local vetting and cloud execution.

### 3. Unified MCP via rulesync

We maintain a central MCP server configuration within the rulesync source. rulesync then syncs this config to every target. Since tool access is defined once, agents keep the same capabilities even when you swap harnesses.

### 4. Reproducibility

We use [devenv](https://devenv.sh/) to ensure the toolchain is identical everywhere. `npm install` runs a frozen rulesync install and regenerates outputs. Setup is automatic via [direnv](https://direnv.net/) - simply changing into the repo bootstraps the environment.

### 5. Prebuilt Cloud Agents

Complex environment setup steps can be slow and cumbersome for cloud agents to run every time. We use `devenv` as the single source of truth to easily prebuild runner images for the GitHub Copilot coding agent (see [devenv-actions](https://github.com/LN-Zap/devenv-actions)).

The action outputs a Docker container that the GitHub Copilot coding agent uses as its environment. By prebuilding the image, we get super fast start-up times for the cloud coding agent, and we guarantee it has the exact same consistent environment we use locally.

We also use `devenv` to generate [Dev Container](https://containers.dev/) specs and use those to generate prebuilt images. That enables us to use the same fully set up coding environment with cloud-based IDEs such as [GitHub Codespaces](https://github.com/features/codespaces).

## Agent Playground at Strike

We run a shared Agent Playground that extends the template with our own skills, MCP servers, and custom agents. Every engineer can pull an environment that knows our internal patterns and connects to our stack.

Engineers bring their own API keys and OAuth credentials. Secrets stay off shared machines and align with individual permissions. Product teams use the same pattern in their own repos, keeping their agent capabilities portable and reproducible.

It's worth noting that Agent Playground is a collection of patterns, not an all-or-nothing framework. While adopting the entire stack (rulesync, lockfiles, devenv) yields the best results, teams can adopt these practices incrementally. You can start by just centralizing your Agent Skills and MCP configs, and add reproducible environments later.

## Standards or bust

Agent tooling shifts too fast for proprietary lock-in. Every new harness brings a unique config format and manual setup cost. That fragmentation slows down engineers.

We advocate for open, vendor-agnostic standards. A shared convention like [AGENTS.md](https://agents.md/) beats a pile of `CLAUDE.md` and `GEMINI.md` files. Your agent system should be bigger than your tool choice.

We aim to treat environments as first-class citizens: portable, reproducible, and tool-blind. Portability pays off. It helps us stay fast as the field evolves.

## Join us

We build this kind of infrastructure every day at Strike, and we think it matters. If you want to go deep on agent systems, developer tooling, and the primitives that make AI actually production-ready, take a look at our open roles.

Apply here: https://job-boards.greenhouse.io/strike

Portable, vendor-agnostic agent environments

Agent Playground

We have been working hard to help bitcoiners acquire more bitcoin in exchange for their fiat. For DCAs and direct deposits, we charge no fees. For one-time or target orders, we offer transparent fee tiers. Now, we are optimizing order routing with our liquidity providers.

## How Strike helps customers tap global liquidity 24/7

When you buy bitcoin on Strike, you’re not buying our bitcoin, because we never sell our holdings. Instead, your order is filled by one of our external liquidity providers. These are large market-making firms that supply buy and sell quotes across the Bitcoin ecosystem. Most exchanges and brokerages rely on a shared pool of liquidity filled by the same handful of providers.

Think of liquidity providers as the always-on counterparties that make the market function. If someone is selling bitcoin on one venue, a liquidity provider may step in to buy it, then hedge or offload that position on another venue. They stitch the global market together.

This is what enables your orders on Strike to execute instantly, at any time of day, any day of the year. Without liquidity providers, you’d be waiting for another human to match your trade.

### Does Strike charge any hidden fees?

We released our current tier-based fee structure in February 2024. Since then, [the fees you pay](/faq/what-are-the-bitcoin-trading-fees-on-strike/) are displayed on the confirmation screen before you confirm a trade.

![](https://www.datocms-assets.com/99305/1763764585-introducing-smart-order-routing-more-bitcoin-for-your-cash-fee-tiers.png)

If you tap to buy and see $89,047.20, and tap to sell and see $88,652.48, that’s expected. We regularly request live quotes from our liquidity partners and offer the best possible prices. The $394.72 gap between them is not a fee charged by Strike.

Providing liquidity isn’t free. The buy price is always higher than the sell price because this spread allows liquidity providers to fund their operations and be available as a counterparty for your trades at any time. These firms operate sophisticated infrastructure, manage inventory risk, and quote prices across dozens of regions and currencies. They make money by quoting a spread: selling bitcoin slightly above the price at which they’re willing to buy it. That spread is their revenue for making markets efficient and reliable at scale.

![](https://www.datocms-assets.com/99305/1763768028-introducing-smart-order-routing-more-bitcoin-for-your-cash-posts.png)

### Why does Strike show different Bitcoin prices on various screens?

Bitcoin doesn’t have a single, global price. You buy at the price a seller is willing to offer, and you sell at the price a buyer is willing to pay. Strike’s role is to ensure you’re always matched with the liquidity provider willing to sell to you at the lowest price or buy from you at the highest price. Whether you’re buying or selling, we’re constantly searching for the most competitive quotes we can find. That way, you get more sats for every dollar you spend, and more dollars for every sat you sell.

When you first open Strike, you might buy or sell bitcoin, but we don’t know which. To avoid confusion, we show a single midpoint price on the home screen: the average of the best buy and sell quotes we get from our liquidity partners.

For example, if the best buy quote is $89,047.20 and the best sell quote is $88,652.48, the midpoint is $88,849.84. When you actually tap Buy or Sell, you’ll see the real quote for that action. In this example, that means only a $197.36 move from the homepage price in either direction, instead of a full $394.72 swing. Showing the midpoint keeps the homepage neutral, consistent, and easier to understand.

![](https://www.datocms-assets.com/99305/1763760455-introducing-smart-order-routing-more-bitcoin-for-your-cash-price-screens.png)

## How smart order routing provides better prices to Strike customers

Strike has invested in integrating with multiple high-quality liquidity providers to ensure redundancy and competitive execution. However, during periods of high volatility, buy-side and sell-side demand can become unbalanced. When more people want to buy than sell (or the opposite), the bid/ask spread naturally widens throughout the entire market. Neither Strike nor our liquidity providers are “profiting more” during these times. This is simply how market microstructures behave under stress.

Wider spreads can materially affect user experience: a buyer trying to “catch the dip” may suddenly see bitcoin priced thousands of dollars higher than someone selling at the same time. This is a problem we set out to reduce.

![](https://www.datocms-assets.com/99305/1763769761-introducing-smart-order-routing-more-bitcoin-for-your-cash-post.png)

With our new smart order routing system, every time you place a buy order, we request a real-time quote from each of our connected liquidity providers. Conceptually, we’re asking each one: “A user wants to buy $100 of bitcoin. How many sats can you deliver right now?”

Each provider responds with a quote, and those quotes are often different. Smart order routing automatically selects the best quote (the one that gives you the highest number of sats per dollar) and executes your trade against that venue. The same logic applies when you sell: we choose the provider offering the highest price for your bitcoin.

We’ve effectively created real competition among our liquidity providers. Those quoting wide spreads will naturally lose flow to providers offering tighter markets. As a result, spreads should compress over time, and you’ll see better pricing on both buys and sells.

This system improves execution quality in both calm markets and high-volatility conditions, reducing the impact of temporary liquidity imbalances and ensuring you always get more bitcoin for your cash.

![](https://www.datocms-assets.com/99305/1764087623-strike-live-price-quotes.gif?fm=gif)

Smart order routing is enabled for all our fiat and USDT trading pairs. It provides you with the best quote not only when you buy or sell but also when you pay bills with bitcoin or convert part of your salary through a direct deposit. There is nothing you need to do to enable it, and we don’t charge you anything extra for it. There are no gimmicks, just a healthy obsession with delivering you as many sats as we possibly can whenever you need them.

## How Strike improves trading prices, redundancy, and reliability

Smart order routing is one part of a broader effort. We’re continually exploring new ways to improve execution quality: expanding our network of high-quality liquidity providers, adding new regions and payment methods, and building features that help you grow your strategic reserve.

Strike has come a long way. In our earliest days, we relied on simple, single-path integrations that could be brittle under load or during market volatility. Over the years, we’ve evolved those systems into one of the most robust trading engines in the industry: fault-tolerant, globally distributed, and capable of sourcing competitive prices across multiple venues in real time. Exchange is core to our mission, and as long as our users care about acquiring bitcoin efficiently, we’ll continue investing heavily in making it faster, more reliable, and more cost-effective.

If you haven’t bought Bitcoin with Strike yet, [give it a try](https://strike.me/download). If building systems like this sounds exciting to you, we’re hiring. Check out our open roles and consider [joining the team](https://strike.me/careers/).

We’ve upgraded our systems to provide better pricing for buys and sells

Introducing Smart Order Routing: More Bitcoin for Your Cash

Estoy complacido de compartir nuestra última contribución de código abierto, el [Patio de Juegos de BOLT 12](https://github.com/LN-Zap/bolt12-playground). Este proyecto proporciona un entorno de prueba práctico y fácil de usar para aquellos que trabajan en o están interesados en explorar y probar prácticamente BOLT 12, un nuevo protocolo de pagos para la [Red Lightning](https://strike.me/es/learn/what-is-the-lightning-network/).

Échale un vistazo: https://github.com/LN-Zap/bolt12-playground.

![](https://www.datocms-assets.com/99305/1718994172-bolt12-hero.png)


## ¿Qué es BOLT 12?

BOLT 12 es un protocolo que extiende las capacidades de la Red Lightning, una solución de segunda capa para Bitcoin que permite transacciones rápidas y de bajo costo. BOLT 12 introduce un nuevo tipo de [factura Lightning](https://strike.me/es/learn/what-is-a-lightning-invoice/) llamada "Ofertas," que son reutilizables, pueden usarse para pagos recurrentes, incluyen características avanzadas de seguridad y pueden contener información adicional como direcciones de reembolso y notas del pagador.

Consulta https://bolt12.org/ para obtener más información.

## ¿Qué es el Patio de Juegos de BOLT 12?

El Patio de Juegos de BOLT 12 es un stack de [Docker](https://www.docker.com/) que incluye soporte para las implementaciones más populares de la Red Lightning y componentes relacionados, incluyendo [Lightning Network Daemon (LND)](https://github.com/lightningnetwork/lnd), [LNDK](https://github.com/lndk-org/lndk), [Core Lightning (CLN)](https://github.com/ElementsProject/lightning), [Eclair](https://github.com/ACINQ/eclair) y [LDK Node](https://github.com/lightningdevkit/ldk-node). Conecta todo, inicializa billeteras y crea canales entre los nodos. Cada nodo en el stack soporta BOLT 12, lo que permite una fácil experimentación con la creación de facturas, pagos y otras características de BOLT 12.

[![](https://www.datocms-assets.com/99305/1718949890-bolt12-playground-stack.png)](https://github.com/LN-Zap/bolt12-playground)

## ¿Por qué usar el Patio de Juegos de BOLT 12?

El Patio de Juegos de BOLT 12 proporciona una oportunidad para que los profesionales de Bitcoin y los aficionados obtengan experiencia práctica con el protocolo BOLT 12. Es un sandbox donde puedes experimentar, aprender y obtener información sobre cómo funciona BOLT 12 en la práctica. Ya seas un desarrollador que busca implementar BOLT 12 en tus propios proyectos, un investigador que estudia la Red Lightning o un entusiasta de Bitcoin curioso sobre los últimos desarrollos, creemos que el Patio de Juegos de BOLT 12 puede ser un recurso útil para ti.

![](https://www.datocms-assets.com/99305/1718949886-bolt12-playground-tests.png)

El Patio de Juegos de BOLT 12 va más allá de un simple entorno de sandbox. También es una herramienta poderosa para desarrolladores y testers para garantizar la interoperabilidad entre diferentes implementaciones de nodos de la Red Lightning, completa con pruebas automatizadas para verificar todo.

### **El Patio de Juegos de BOLT 12 incluye:**

#### **Pruebas de Interoperabilidad** 
El Playground facilita pruebas de pagos BOLT 12 entre varias implementaciones de nodos, lo que puede ayudar a identificar y abordar posibles problemas de compatibilidad antes del despliegue en el mundo real.

#### **Pruebas de Topología de Canales** 
Permite pruebas a través de diferentes topologías de canales, incluidos canales directos, pagos multi-hop e incluso pagos multi-hop que atraviesan nodos de diferentes implementaciones. Esto ayuda a garantizar que BOLT 12 funcione sin problemas independientemente de la estructura de la red.

#### **Pruebas Automatizadas**
El proyecto incorpora un conjunto de pruebas de integración automatizadas. Actualmente, el conjunto soporta pagos simulados con LND (a través de lndk), Eclair, CLN y LDK Node. Esta automatización agiliza las pruebas y facilita las prácticas de integración continua.

## Contribuciones de la Comunidad
El Patio de Juegos de BOLT 12 es un proyecto de código abierto y alentamos las contribuciones de la comunidad. Si estás trabajando en una implementación de nodo con soporte para BOLT 12, te invitamos a probarlo y a integrarlo en el Patio de Juegos de BOLT 12.

## Comenzando
Para comenzar a usar el Patio de Juegos de BOLT 12, visita el repositorio del proyecto en GitHub: https://github.com/LN-Zap/bolt12-playground.

Un Sandbox para Pruebas Prácticas de BOLT 12

El Patio de Juegos de BOLT 12

La [red Lightning](https://strike.me/es/learn/what-is-the-lightning-network/) es una red de pagos de bitcoin que es instantánea, privada y de bajo costo o sin costo. Operar un nodo Lightning puede proporcionar beneficios significativos, incluyendo la autosoberanía financiera, mejora de la privacidad, obtención de comisiones de enrutamiento y/o participación en una nueva red financiera global. Sin embargo, mantener un nodo Lightning requiere trabajo, incluyendo la necesidad ocasional de migrar tu operación a un nuevo nodo por razones de seguridad, privacidad o mantenimiento. El proceso de migrar a un nuevo nodo a veces se denomina "rotar la semilla de tu nodo".

![](https://www.datocms-assets.com/99305/1712088217-blog-migrating-a-ln-node-01.png)

Los canales de tu nodo Lightning, a través de los cuales se envía y recibe bitcoin, están vinculados directamente a la semilla única del nodo. Esto significa que no puedes simplemente "copiar y pegar" los canales de tu nodo a una nueva semilla. Migrar tu nodo por razones de seguridad u otras requiere un proceso de migración estratégico.

En esta publicación, desglosaremos los pasos para migrar sin problemas la liquidez de tu nodo de un nodo a otro, minimizando el tiempo de inactividad y haciendo la transición sin problemas para tus usuarios y la red.

__💡**NOTA: ¿Mover tu nodo a un nuevo hardware sin cambiar su semilla? En este caso, deberías usar un enfoque más simple de "levantar y colocar": respaldo, transferencia y restauración. Esto evita las complejidades de la rotación de semilla.**

Asumiendo que necesitas migrar a un nuevo nodo con una nueva semilla y que tienes el lujo del tiempo a tu favor, las siguientes secciones describirán un enfoque paso a paso para migrar la liquidez y la actividad de enrutamiento de tu nodo a una nueva semilla con una interrupción mínima del servicio.


## Preparación para migrar tu nodo Lightning

Antes de comenzar, es importante recordar que si tu nodo opera como un nodo de enrutamiento, estarás reiniciando su reputación desde cero, lo que puede ser una consideración importante para la conectividad de canales y la liquidez. Comencemos estableciendo los elementos esenciales, configurando tu nuevo nodo y preparándolo para tomar el control sin problemas en el futuro.

![](https://www.datocms-assets.com/99305/1712088227-blog-migrating-a-ln-node-02.png)

### Paso 1: Provisiona un nuevo nodo

Para comenzar, necesitarás configurar de forma segura tu nuevo nodo con una semilla única y fuerte. Recuerda que la gestión adecuada de semillas y claves es primordial. Tu nuevo nodo viene con una nueva identidad única y pubkey.

![](https://www.datocms-assets.com/99305/1712088235-blog-migrating-a-ln-node-03.png)

### Paso 2: Crea un puente

Luego, necesitarás establecer un gran canal entre los nodos antiguo y nuevo. Recuerda iniciar la apertura del canal desde el nodo antiguo para que tenga la capacidad de enrutar pagos hacia el nuevo. Este canal actuará como un puente para la transferencia eficiente de fondos. En el nodo antiguo, configura la política del canal con una comisión baja (por ejemplo, cero) y un delta de bloqueo de tiempo bajo (por ejemplo, 18). Dado que controlas ambos nodos, controlas las políticas de enrutamiento en ambos extremos del canal. En el nodo nuevo, establece las comisiones de enrutamiento para este canal más altas para desalentar el flujo en la otra dirección. La baja comisión para enrutar hacia el nuevo nodo fomentará que la liquidez fluya en esa dirección.


## Migración paso a paso

Mientras migras la liquidez a tu nuevo nodo, la clave es mantener una transición fluida para tus usuarios y la red. Quieres que tu nodo existente permanezca activo y disponible, enrutando con su liquidez actual, mientras construyes simultáneamente el nuevo nodo para que tome el control sin problemas.

![](https://www.datocms-assets.com/99305/1712088241-blog-migrating-a-ln-node-04.png)

### Paso 3: Cierres estratégicos de canales

Primero, prioriza el cierre de canales donde la mayor parte de la liquidez reside de tu lado del canal, también conocidos como canales con liquidez saliente. Esto te proporcionará capital que puedes usar para abrir nuevos canales en el nuevo nodo, y el perfil de liquidez de esos nuevos canales será similar al de los antiguos (la mayor parte de la liquidez de tu lado). Los canales necesitarán cerrarse individualmente, ya que la mayoría de las implementaciones de nodos aún no soportan el agrupamiento, así que usa un momento estratégico y comisiones adecuadamente bajas para mantener bajos los costos de cierre de canales.

![](https://www.datocms-assets.com/99305/1712088247-blog-migrating-a-ln-node-05.png)

### Paso 4: Apertura de canales en lotes

A medida que cierras canales en el nodo antiguo, abre simultáneamente nuevos en el nodo nuevo hacia el mismo conjunto de pares, usando la apertura de canales en lotes para ahorrar comisiones. Es mejor abrir canales de una capacidad similar para permitir la continuidad del servicio hacia esos pares. Alternativamente, esta puede ser una buena oportunidad para repensar y reconsiderar tu topología de canales.

![](https://www.datocms-assets.com/99305/1712088252-blog-migrating-a-ln-node-06.png)

### Paso 5: Controlar el flujo

Luego, necesitarás monitorear de cerca los balances de los canales para el nuevo nodo y usar las comisiones de enrutamiento como una palanca para influir en el flujo de liquidez.

Es una buena idea abrir los nuevos canales con comisiones competitivas para promover el flujo saliente y aumentarlas gradualmente a medida que la liquidez comienza a fluir a través de los nuevos canales y alcanza un estado equilibrado. Considera usar una herramienta como [charge-lnd](https://github.com/accumulator/charge-lnd) para automatizar los ajustes de comisiones a medida que el perfil de liquidez cambia con el tiempo.

Si originas pagos desde tus nodos, considera que si los canales salientes en el nuevo nodo tienen comisiones de enrutamiento no nulas, cualquier pago saliente que se origine desde tu nodo original y pase por el canal puente incurrirá en esas comisiones de enrutamiento. Esto puede o no ser deseable, dependiendo de tu caso de uso. Para evitar estas comisiones adicionales, puedes ser selectivo sobre el canal de primer salto utilizado para pagos y excluir el canal puente si lo deseas. Alternativamente, puedes establecer comisiones de enrutamiento salientes externamente a cero en el nuevo nodo, o ser estratégico sobre qué nodo eliges para originar pagos.

![](https://www.datocms-assets.com/99305/1712088259-blog-migrating-a-ln-node-07.png)

### Paso 6: Repetir

Continúa iterando entre los pasos 3-5, migrando gradualmente lotes de canales hasta completar.


## Consejos adicionales

Migrar la semilla de tu nodo Lightning puede sonar complejo, pero con el enfoque correcto, puede ser un paso manejable hacia una seguridad mejorada o una topología mejorada. Aquí hay otras cosas a considerar para agilizar aún más el proceso:

* Considera usar swaps como [peerswaps](https://strike.me/es/blog/peerswaps/) o [loops](https://lightning.engineering/loop/) para acelerar el reequilibrio.
* Actualiza las políticas del nodo para evitar que se abran nuevos canales hacia el nodo antiguo.
* Usa un [estimador de comisiones combinado](https://strike.me/es/blog/blended-bitcoin-fee-estimations/) para buenas estimaciones de tarifas.
* Actualiza los alias de los nodos para indicar que está en progreso una migración.
* Informa a los operadores de nodos sobre la transición a través de comunidades en línea.
* Trabaja con socios de canal para actualizar las políticas del aceptador de canales con tu nueva pubkey.
* Crea nuevas direcciones on-chain desde el nuevo nodo y actualiza referencias según sea necesario.
* Monitorea las direcciones on-chain asociadas con el nodo antiguo y transfiere los fondos recibidos.
* Adapta el proceso a la configuración y preferencias específicas de tu nodo.


Moviendo liquidez a un nuevo nodo Lightning

Migración de un nodo Lightning

En Bitcoin, las comisiones de transacción juegan un papel importante en garantizar la confirmación oportuna y confiable de las transacciones. Sin embargo, estimar estas comisiones con precisión puede ser una tarea desafiante, dadas las dinámicas de mercado siempre cambiantes y las demandas de transacciones competidoras. Este desafío se ve aún más complicado por la escasez de espacio en los bloques, un recurso finito por el que compiten todas las transacciones.

Con nuevos bloques minándose aproximadamente cada 10 minutos, depende de ti, el remitente de la transacción, determinar la comisión que estás dispuesto a pagar para asegurar la inclusión de tu transacción en la blockchain. Una comisión más alta generalmente se traduce en una mayor probabilidad de una confirmación rápida, mientras que una comisión más baja puede llevar a una confirmación retrasada. Pero, ¿cómo puedes estimar con precisión la comisión requerida según tu preferencia de tiempo?

**En esta publicación, analizaremos algunas de las diferentes formas de estimar las comisiones de transacción de bitcoin y cómo puedes combinarlas en una estrategia efectiva de estimación de comisiones.**


## Tipos de estimación de comisiones en Bitcoin

Predecir con precisión las tendencias futuras de las comisiones sigue siendo un desafío. Aunque las billeteras y los nodos emplean varios métodos de estimación de comisiones, cada enfoque tiene sus fortalezas y limitaciones.

**Hay dos métodos principales de estimación de comisiones que analizaremos: basado en el mempool y basado en el historial.**


### Estimación de comisiones basada en el mempool

La estimación de comisiones basada en el mempool se centra en analizar el estado actual del mempool, la colección de transacciones no confirmadas que compiten por espacio en los bloques. Al examinar las tasas de comisión de las transacciones recientemente añadidas al mempool, este método proporciona información en tiempo real sobre el panorama actual de comisiones. Este enfoque es particularmente útil para situaciones donde se desea una confirmación rápida, ya que puede proporcionar estimaciones actualizadas basadas en las dinámicas inmediatas del contenido real del mempool.

Un buen ejemplo de estimación de comisiones basada en el mempool es el proyecto de código abierto [Mempool](https://mempool.space). El equipo de [Muun](https://muun.com) también usa su propio estimador de comisiones basado en el mempool, del cual puedes leer más [aquí](https://blog.muun.com/why-is-muuns-fee-estimator-more-efficient/). Producen este gráfico en su sitio web que muestra cuánta diferencia puede hacer un enfoque basado en el mempool:

![](https://www.datocms-assets.com/99305/1705601134-munn-fee-chart.png)

Como puedes ver, cuando se trata de estimar con precisión la comisión para que una transacción sea confirmada en el próximo bloque, los estimadores basados en el mempool como este hacen un buen trabajo; producen estimaciones que son más óptimas ya que son más reactivas a los cambios a corto plazo.

### Estimación de comisiones basada en el historial

En contraste con la estimación basada en el mempool, la estimación de comisiones basada en el historial utiliza datos históricos para predecir las tendencias futuras de comisiones, analizando datos de transacciones pasadas para identificar patrones y tendencias en las fluctuaciones de comisiones. Al entender los movimientos históricos de las comisiones, la estimación basada en el historial puede proporcionar estimaciones más estables y predecibles para las transacciones con objetivos de confirmación más flexibles.

[Bitcoin Core](https://github.com/bitcoin/bitcoin), la implementación de nodo de Bitcoin más utilizada, y la que usamos en Strike, utiliza este enfoque basado en el historial. Si deseas ver exactamente cómo genera sus estimaciones de comisiones, puedes leer [el código fuente de estimación de comisiones de Bitcoin Core](https://github.com/bitcoin/bitcoin/blob/master/src/policy/fees.h). Pero para desglosarlo en términos simples, el proceso de estimación involucra:
* Agrupar transacciones en categorías basadas en tasas de comisión similares
* Rastrear cuánto tiempo tarda en minarse las transacciones en estas categorías
* Usar diferentes conjuntos de datos para rastrear esta información en varios horizontes temporales (corto, mediano y largo)
* Aplicar un factor de decaimiento para cada conjunto de datos para dar más peso a las transacciones recientes
* Usar umbrales de éxito para diferentes horizontes temporales
* Calcular estimaciones basadas en el número de transacciones confirmadas dentro del número objetivo de bloques o menos

La estimación de comisiones de Bitcoin Core utiliza un promedio móvil y varios parámetros para proporcionar estimaciones de tasas de comisión bajo diferentes condiciones. Dentro de esto, hay dos modos de estimación que puedes seleccionar: económico y conservador.

**Modo Económico:** Este modo estima las comisiones basándose en bloques recientes, con el objetivo de optimizar por comisiones más bajas. Es más receptivo a los cambios más recientes en el mercado de comisiones, lo que lo hace adecuado para situaciones donde estás dispuesto a arriesgar tiempos de confirmación más largos por comisiones potencialmente más bajas.

**Modo Conservador:** Este modo proporciona estimaciones que son más propensas a asegurar una confirmación más rápida, ya que considera un historial de transacciones más largo. Sin embargo, es menos receptivo a caídas a corto plazo en las tasas de comisión, lo que a menudo resulta en recomendaciones de comisiones más altas. Este modo es mejor si deseas priorizar el tiempo de confirmación de la transacción sobre el costo de la comisión.

Ambos modos buscan equilibrar el costo y el tiempo de confirmación según las diferentes preferencias del usuario y las condiciones del mercado.


## Logrando el equilibrio adecuado
En Strike, realizamos muchas transacciones de Bitcoin en nombre de nuestros usuarios. Dependiendo del escenario, tenemos diferentes requisitos para nuestros tiempos de confirmación. Veamos un par de ejemplos breves:

**Agrupación de transacciones:** Cuando transmitimos transacciones on-chain en nombre de nuestros usuarios, usamos la agrupación de transacciones para optimizar nuestro uso del espacio en los bloques. En términos generales, nuestro algoritmo de agrupación apunta a transmitir un lote de transacciones cada bloque. Para que esto sea efectivo, necesitamos garantías fuertes de que nuestra transacción realmente entrará en el próximo bloque, por lo que usar un estimador de comisiones basado en el mempool funciona mejor para este caso de uso.

**Apertura/cierre de canales Lightning:** Por el contrario, cuando estamos abriendo y cerrando canales lightning, podemos esperar más tiempo, y por lo tanto una estimación basada en el historial, como las de Bitcoin Core, puede ser más apropiada ya que nos permite apuntar más efectivamente a bloques más lejanos en el futuro.

## Estimación combinada de comisiones

Dadas las ventajas y limitaciones de cada enfoque individual, utilizamos un método de estimación combinada de comisiones que aprovecha las ventajas de las estimaciones basadas en el mempool y en el historial.

Para transacciones inmediatas que requieren una confirmación rápida dentro de los próximos bloques, priorizamos las estimaciones basadas en el mempool por su precisión en tiempo real.

Para transacciones con objetivos de confirmación más flexibles en el futuro, confiamos en las estimaciones basadas en el historial para proporcionar un rango de comisiones más estable y predecible.

Este enfoque combinado logra un equilibrio entre precisión en tiempo real y previsibilidad a largo plazo, lo que nos permite optimizar las comisiones de transacción de manera efectiva en una amplia variedad de escenarios.

## Mejorando las estimaciones de comisiones de LND

**En el resto de esta publicación, veremos cómo combinamos las dos técnicas: estimación de comisiones basada en el mempool y basada en el historial.**

Dado que usamos principalmente el [Daemon de la Red Lightning (LND)](https://github.com/lightningnetwork/lnd) para nuestras necesidades de nodo Lightning, nos centraremos en eso; sin embargo, se podría tomar un enfoque similar para otras implementaciones de nodos.


### Custom fee estimates with LND

De forma predeterminada, un nodo LND que está conectado a una instancia de Bitcoin Core usará el [`estimatesmartfee` RPC](https://developer.bitcoin.org/reference/rpc/estimatesmartfee.html) de Bitcoin Core para proporcionar sus estimaciones de comisiones. Como vimos anteriormente, esto es menos que ideal en algunas situaciones, ya que sus estimaciones solo se basan en datos históricos.

¿No sería mejor si pudiéramos conectar un estimador de comisiones diferente en LND? Bueno, tenemos suerte porque los ingenieros que trabajan en LND pensaron en eso y, por supuesto, ya hicieron configurable el servicio de comisiones.

Puede que no sea inmediatamente aparente, pero si miras el [archivo de configuración](https://github.com/lightningnetwork/lnd/blob/master/sample-lnd.conf) de muestra proporcionado en el código fuente de LND, encontrarás este bloque de código:

```
; Optional URL for external fee estimation. If no URL is specified, the method
; for fee estimation will depend on the chosen backend and network. Must be set
; for neutrino on mainnet.
; Default:
;   feeurl=
; Example:
;   feeurl=https://nodes.lightning.computer/fees/v1/btc-fee-estimates.json
```

Como puedes ver, hay una opción de configuración feeurl, que se puede establecer en una URL que proporcione estimaciones de comisiones. Y si visitamos la [URL de ejemplo](https://nodes.lightning.computer/fees/v1/btc-fee-estimates.json) de ese mismo fragmento, llegarás a una página que sirve un json que se ve así:

```
{
  "current_block_hash": "0000000000000000000075b86...6303e",
  "fee_by_block_target": {
    "2": 141428,
    "4": 96148,
    "85": 82688,
    "121": 79068
    "24": 171819,
    "25": 86680,
    "144": 58520,
    "504": 56192,
    "1008": 37896
  }
}

```

Examinando esto un poco, notamos que proporciona una serie de estimaciones de objetivos de confirmación. Del ejemplo anterior, la comisión estimada para que una transacción sea minada dentro de los próximos 4 bloques es de 96,148 (eso es comisión por kb, lo que se traduce en una tasa de comisión de ~96 sats/vbyte).
Esto es bastante bueno. Significa que podemos apuntar la configuración `feeurl` a cualquier URL que devuelva json siguiendo este formato, por lo que, en teoría, podríamos conectar cualquier sistema de estimación de comisiones a eso, siempre que pueda devolver estimaciones de comisiones en el formato esperado.


### Usando estimaciones basadas selectivamente en el mempool y el historial

Nuestro objetivo era usar estimaciones de comisiones basadas en el mempool para transacciones que deberían ser confirmadas dentro de los próximos bloques, pero seguir usando estimaciones basadas en el historial para transacciones que deberían ser confirmadas más adelante en el futuro.

Cuando se trata de estimadores de comisiones basados en el mempool, creemos que el proyecto de código abierto Mempool es una de las mejores herramientas disponibles, por lo que queríamos usar eso para nuestras estimaciones de comisiones a corto plazo. Y para las estimaciones a largo plazo, creemos que Bitcoin Core hace un buen trabajo, así que queríamos seguir usándolo.

Para lograr esto, creamos un [Estimador Combinado de Comisiones de Bitcoin](https://github.com/LN-Zap/bitcoin-blended-fee-estimator). Este es un servicio básico que proporciona un único endpoint que sirve json con estimaciones de comisiones en el formato esperado para LND.

Las estimaciones para un objetivo de confirmación de 1 a 6 son proporcionadas por la [API de Mempool](https://mempool.space/docs/api/rest), mientras que las estimaciones para objetivos de confirmación más lejanos en el futuro son proporcionadas por Bitcoin Core a través de la [API de Esplora](https://github.com/Blockstream/esplora/blob/master/API.md).

Por defecto, se conecta a las APIs públicas de [mempool.space](https://mempool.space) y [blockstream.info](https://blockstream.info), sin embargo, se puede configurar para conectarse directamente a tus propias instancias de Mempool y Esplora para reducir la dependencia de estas APIs de terceros alojadas.

### Ejecutando el servicio de estimación combinada de comisiones

Puedes ejecutar este servicio en tu propia infraestructura junto a tu nodo LND. O, puedes usar nuestra versión alojada para comenzar rápidamente (sigue leyendo para más detalles).

Si tienes Docker configurado en tu máquina, puedes probarlo ejecutando la [imagen de Docker](https://hub.docker.com/repository/docker/lnzap/lnd-mempoolspace) que proporcionamos para tu conveniencia.

```
docker run -p 3000:3000 lnzap/bitcoin-blended-fee-estimator:latest
```

Después de que la imagen de Docker se haya descargado, deberías ver la siguiente salida indicando que el servicio está en funcionamiento.


```
---
Using port: 3000
Using base URL: http://localhost:3000
Using Esplora base URL: https://blockstream.info
Using Mempool base URL: https://mempool.space
Using Mempool estimation depth: 6
Using fee multiplier: 1
Using cache stdTTL: 15
Using cache checkperiod: 20
---
Fee Estimates available at http://localhost:3000/v1/fee-estimates
```

Luego, simplemente navega a http://localhost:3000/v1/fee-estimates donde deberías ver las estimaciones de comisiones actuales, formateadas adecuadamente para LND.

Puedes configurar esta URL en tu archivo de configuración de LND y reiniciar tu nodo LND:

```
; URL for external fee estimation.
feeurl=http://localhost:3000/v1/fee-estimates
```

Con esto en su lugar, LND ahora usará estimaciones de comisiones de Mempool para estimaciones de comisiones del próximo bloque, y estimaciones de Esplora para estimaciones más lejanas en el futuro.

### Aprovechando el servicio de estimación combinada de comisiones

Debido a que nos hemos conectado directamente a LND, usará esto para todas sus estimaciones internas de comisiones que apunten a un número específico de bloques en el futuro, como hacer transacciones on-chain, abrir canales, sweeps, etc. Además, cualquier cosa que se conecte o construya sobre LND también se beneficiará de las nuevas fuentes de estimación de comisiones. Así que tendrás un enfoque consistente para generar estimaciones de comisiones en toda tu pila.

Por ejemplo, si estás utilizando [Lightning Loop](https://lightning.engineering/loop/) para reequilibrar canales, las estimaciones de comisiones proporcionadas por el servicio Loop también usarán nuestras fuentes de comisiones personalizadas, ya que llama a LND para obtener esas estimaciones (descubrimos que esto reduce drásticamente nuestros costos de reequilibrio al evitar que Loop pague de más en comisiones on-chain).

O si estás construyendo una billetera u otro servicio sobre LND, eso también usará las fuentes de estimación de comisiones personalizadas.
Esencialmente, cualquier cosa que llame al [RPC EstimateFee](https://lightning.engineering/api-docs/api/lnd/wallet-kit/estimate-fee) de LND, ya sea directamente o indirectamente, usará la nueva fuente de estimación de comisiones.


## Un servicio de estimación de comisiones alojado por Strike para LND

Usar una combinación de estimaciones de comisiones basadas en el mempool y en el historial en nuestras herramientas nos ha proporcionado mejores estimaciones para que las transacciones sean minadas. Esto ayuda a mantener los costos bajos para nuestros usuarios, así como a aliviar la presión de las comisiones en la blockchain de Bitcoin.

Pensamos que podría ser útil para otros operadores de nodos, proveedores de servicios de billetera o desarrolladores, así que hemos abierto el código:

https://github.com/LN-Zap/bitcoin-blended-fee-estimator

Además, queríamos hacerlo súper simple para que lo pruebes sin necesidad de desplegar una instancia del servicio en tu propia infraestructura, así que hemos configurado una versión alojada del servicio para que cualquiera lo use. Puedes acceder a él en la siguiente URL:

https://bitcoinchainfees.strike.me

Para usarlo, simplemente agrega/actualiza la configuración `feeurl` en tu archivo lnd.conf para apuntar al endpoint proporcionado por el servicio:

```
feeurl=https://bitcoinchainfees.strike.me/v1/fee-estimates
```

¡Esperamos que encuentres útil la herramienta de estimación combinada de comisiones! Haznos saber si funciona para ti o si tienes alguna pregunta o sugerencia para mejoras.

## Mejoras futuras

Los problemas con las estimaciones de comisiones basadas en el historial de Bitcoin Core son bastante conocidos y entendidos, y hay múltiples esfuerzos y propuestas para mejorar esto.

Una propuesta reciente es la idea de Estimación de Comisiones por Clústeres, que surge de discusiones en la comunidad de Bitcoin en general. Este enfoque busca abordar algunas de las complejidades del mecanismo Child Pays For Parent (CPFP) agrupando transacciones vinculadas y evaluando sus tasas de comisión colectivas. Para entender el impacto del mecanismo CPFP en la estimación de comisiones y la propuesta de Estimación de Comisiones por Clústeres en más detalle, vale la pena leer este [artículo de Bitcoin Optech](https://bitcoinops.org/en/topics/cluster-mempool/), o revisar este [resumen más detallado](https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393) de la propuesta de Suhas Daftuar.

Aunque ninguna técnica de estimación de comisiones será perfecta dada la tarea imposible de predecir el futuro, podemos continuar implementando soluciones más avanzadas, robustas y adaptativas que ofrezcan mejoras generales al problema de la estimación de comisiones.

**Cuanto más colectivamente optimicemos nuestras comisiones de transacciones on-chain, mejor para todos;** al reducir el pago excesivo de comisiones, podemos ayudar a evitar el ciclo auto perpetuante en el que las personas que pagan comisiones innecesariamente altas pueden impulsar las estimaciones de comisiones aún más alto.

Combinando estimadores de comisiones basados en el mempool y en el historial

Estimaciones combinadas de comisiones de Bitcoin

[Peerswaps](https://www.peerswap.dev/) enable atomic swaps between Lightning Network and Bitcoin (BTC) or Liquid Bitcoin (L-BTC). This can enable a cost effective and capital efficient way to maintain well balanced Lightning channels.

We’ll take a practical look at how to go about performing a peerswap, and how you could add peerswaps to your channel rebalancing strategy.

## Run the Daemons
Alongside your Lightning node (peerswap currently supports [LND](https://github.com/lightningnetwork/lnd) or [CLN](https://github.com/ElementsProject/lightning)), run the [Peerswap daemon](https://github.com/ElementsProject/peerswap), and optionally the [Elements daemon](https://github.com/ElementsProject/elements) if you want to use L-BTC.

The Peerswap node will act as the swap coordinator.

The Elements node will act as a Liquid Bitcoin wallet which you can use to swap funds into and out of your Lighting channels. If you want to use regular BTC instead of L-BTC, you can use the on-chain bitcoin wallet that’s integrated with your Lightning node instead.

When you want to rebalance the channel, use the Peerswap daemon to initiate a peerswap. The peerswap daemon will coordinate the transactions with your channel peer. After initiating the swap, you just need to wait for 2 confirmations on the Liquid network for everything to complete. The whole process takes about 2 minutes (the time it takes for 2 blocks to confirm on the Liquid blockchain).

## Whitelist Peers
Peerswaps are direct swaps with direct channel partners. To use Peerswap your channel partner must also be running Peerswaps and must have whitelisted you in their peerswap config file (or set the `accept_all_peers` option). You must also whitelist them in yours. You can run `pcli listpeers` to check which of your connected channel peers support peerswaps and which chains they support (BTC and/or L-BTC).

Why the whitelist? Consider that a peerswap is an operation that has a cost (on-chain fees), a time opportunity cost (funds locked during the swap operation), and an effect on your liquidity profile (swapping capital between Lightning and BTC or L-BTC). It’s probably not something that you want to blindly allow anybody to do. However, it is something that you could reasonably enable between proven node operators within your own network of channel peers, or even your own nodes if you run multiple.

## Rebalancing Use Bitcoin (BTC) or Liquid Bitcoin (L-BTC)
Peerswaps supports swapping using both the Bitcoin base chain, and the [Liquid](https://liquid.net/) Bitcoin federated sidechain. Each has their pros and cons, but for the purposes of rebalancing channels, the Liquid Network has a distinct advantage in two important areas - speed, and cost.

### Speed
Blocks on the Liquid network are produced every minute and only 2 confirmations are required to complete a peerswap. So it takes ~2+ minutes to finalize a peerswap.

On the Bitcoin network blocks are produced on average every 10 minutes and it will take 3 confirmations to complete a peerswap. So it takes ~30+ minutes to finalize a peerswap.

### Cost
The average transaction fee on the Liquid network is currently 0.1 sat/vbyte to get into the next block (although this may change over time). Given an average transaction size of ~2000 vbytes it would cost you about 200 sats to perform a swap. That is about $0.025 by today's exchange rates.

On the Bitcoin base chain, fees are variable but generally much higher. At the time of writing, it will cost about 50 sat/vbyte to get into the next block. Given an average transaction size of ~300 vbytes it would cost you about 12,000 sats to perform a swap. That is about $5.62 by today's exchange rates. In other words, about 225 times more expensive than L-BTC, and a material consideration if you are a Lightning routing node operator or are running a business in which channels need to be regularly rebalanced.

### Other Considerations
Of course, cost and speed aren’t the only considerations. To use Peerswaps you will also have some additional overhead.

Running peerswaps itself is pretty straightforward. It’s only acting as a coordinator so it doesn’t directly hold funds, although it does need access to your nodes, and it does need to maintain state so you will need to ensure you have robust secrets management and backup solutions in place.

If you want to take advantage of Liquid you also need to run the Elements daemon where there is more to consider, as the Elements wallet will be holding an L-BTC balance. And there is also the different [trust model](https://blog.liquid.net/the-truth-about-liquid/) of the Liquid federation itself to consider.

### BTC vs L-BTC
All in all, if you're looking for a fast, very cost effective way to maintain balanced channels between semi-trusted direct channel peers, L-BTC is a good option. Although using BTC for peerswaps may also be useful and preferable in certain situations. This comparison from the Peerswaps team shows some of those considerations:

![](https://www.datocms-assets.com/99305/1702226228-peerswaps-btc-lbtc.png)

## Performing Swaps
Depending on the state of your channel, you’ll perform a swap-in or a swap-out to rebalance it:

### The Swap-Out
When most of the liquidity is at your end of the channel (you are short of inbound liquidity) you swap some of your Lightning Bitcoin with your peer’s L-BTC (or BTC); you perform a swap-out.

![](https://www.datocms-assets.com/99305/1702226245-peerswaps-swap-out.png)

In the swap-out, you will generate an L-BTC (or BTC) on-chain address, your peer will generate a Lightning invoice for the same amount, and you will then pay this invoice using the  unbalanced outbound heavy channel. This pushes Lighting Bitcoin along the channel, to your peer, rebalancing the channel. As part of the same process your peer will send the required BTC amount to your on-chain address.

### The Swap-In
Conversely, when most of the liquidity is at your peers end of the channel (you are short of outbound liquidity) you swap your L-BTC (or BTC) with your peers Lightning Bitcoin; you perform a swap-in.

![](https://www.datocms-assets.com/99305/1702226238-peerswaps-swap-in.png)

In the swap-in, you will generate a Lightning invoice, your peer will generate an L-BTC (or BTC) on-chain address, and they will then pay your invoice using the unbalanced inbound heavy channel, pushing their Lighting Bitcoin along the channel to your side of the channel making it yours, and in the process rebalancing the channel. As part of the same process you will pay the required amount of BTC to your peer’s on-chain address.

The end result - ~2 minutes later your channel will be back at your preferred liquidity profile for a cost of less than $0.03, if you used liquid. You could do this dozens of times in a single day and only pay $1 total at today’s rates.

## Automation to keep the channel balanced
With both yourself and your peer running peerswaps and elements, you now have the ability to keep channels between each other balanced for a very low cost.

One way to do this would be to maintain a pool of working capital in the form of L-BTC, which you peg into the Liquid sidechain from the Bitcoin chain when on-chain fee rates are relatively low. You could then automate things such that if all the liquidity in the channel moves towards 100% in either direction you can use peerswap to bring it back towards 50% by swapping into or out from the channel balance to and from your L-BTC working capital pool.

This can enable you to maintain fewer, smaller, well balanced channels with a very small on-chain footprint.

## Testing with Peerswap Playground
We put together this simple [PeerSwap Playground](https://github.com/LN-Zap/peerswap-playground) which you can use to try it out. It provides a Docker stack that comprises bitcoind (running on regtest), elementsd, 2x lnd nodes, 2x peerswap clients, and 2x L-BTC wallets. It connects everything together, initializes the wallets, and creates a channel between the two nodes.

You can use this to perform test swaps or just practice your skills with lnd, elementsd, and peerswapd! There are some simple instructions in the project’s readme which will walk you through the setup and the process of performing a swap.

## Rebalancing channels with Strike using Peerswaps
If you support Peerswaps and are one of our existing channel partners or run a reliable routing node and would like to maintain a balanced channel with the [Strike routing node](https://1ml.com/node/034d7f4bbbd6c1c1d8fbe0a42dd1f59e10b66540c6872dfcaa095d8d5cffebcf46), reach to our liquidity team at [liquidity@strike.me](mailto:liquidity@strike.me).

### Other Rebalancing Tools and Techniques
Peerswaps is a relatively new rebalancing technique. This comparison from the Peerswaps team conveys some of the key properties and tradeoffs of peerswaps as compared to other approaches to rebalancing channels.

![](https://www.datocms-assets.com/99305/1702226252-channel-balancing-options.png)

All in all, Peerswaps between Lightning and L-BTC can be a reliable, cost effective, and capital efficient way to keep channels between semi-trusted peers well balanced.

## More About Peerswaps
Peerswaps was created by the team at [Blockstream](https://blockstream.com/). It's in its early stages and under active development. Peerswaps currently supports LND and CLN. There is only a command line interface at the moment, although a GUI integration with [Ride the Lightning](https://www.ridethelightning.info/) is in the works. The Peerswaps team has an active [Discord](http://discord.gg/MSNt8eyZrT) where they engage with the community so if you need help or would like to help with the project you can head over to there.