pull down to refresh
Español
Te agradezco mucho por tu comentario.
Comparto tu punto de vista y creo que das en el clavo. El problema real es que las personas necesitan Bitcoin, pero no lo tienen dentro de sus necesidades porque no entienden qué es realmente el dinero, y el sistema las ha condicionado a aceptar la exclusión como algo "normal".
English
Thank you very much for your comment.
I share your point of view and I think you hit the nail on the head. The real problem is that people need Bitcoin, but they don't have it within their needs because they don't understand what money really is, and the system has conditioned them to accept exclusion as something "normal".
ENGLISH
You're absolutely right and I apologize. My approach was wrong.
I wanted to express that Lightning seems more decentralized to me because you can have your own node and direct channels, but I presented it poorly by talking about "controlling the final state with your key" as if that didn't also apply to routed Lightning. It was a drafting error, not an intention error.
You have every right not to continue the conversation. I completely understand.
What I am genuinely interested in is the work ARK is doing with Lightning Labs. I think it could be an excellent entry point for newer people in Bitcoin, and especially for merchants who need simple solutions to accept payments. The ease of use without needing to manage channels could be a great differentiator.
Thanks for your contributions. You gave me a perspective I hadn't considered correctly, and that's exactly what I'm looking for in other stackers' comments.
ESPAÑOL
Tienes toda la razón y me disculpo. Mi enfoque fue incorrecto.
Quería expresar que Lightning me parece más descentralizado porque puedes tener tu propio nodo y canales directos, pero lo planteé de forma confusa al hablar de "controlar el estado final con tu clave" como si eso no aplicara también a Lightning routado. Fue un error de redacción, no de intención.
Tienes todo el derecho de no seguir la conversación. Lo entiendo perfectamente.
Lo que sí me interesa mucho es el trabajo que ARK está haciendo con Lightning Labs. Creo que puede ser una excelente puerta de entrada para personas más nuevas en Bitcoin, y especialmente para comerciantes que necesitan soluciones simples para aceptar pagos. La facilidad de uso sin necesidad de gestionar canales puede ser un gran diferencial.
Gracias por tus aportes. Me diste una perspectiva que no había considerado correctamente, y eso es exactamente lo que estoy buscando en los comentarios de otros stackers.
ENGLISH
Thanks for the correction, that's exactly what I was looking for - better understanding of these protocols.
You're right that ARK is not custodial technically. vTXOs are pre-signed transactions and the user maintains control over their on-chain exit. My mistake was generalizing "coordination" as "trust".
What concerns me about ARK is another nuance:
Privacy: The coordinator sees who pays whom. In Lightning, routing goes through HTLCs and each hop only sees neighbors. In ARK, the coordinator has full visibility of the transaction graph.
Availability: If the coordinator refuses to coordinate your vTXOs, you're depending on someone else to do it. In Lightning, if a node goes down, the network keeps functioning through other paths.
On channel comparison: Yes, every Lightning node coordinates, but the difference is that in Lightning you control the final state with your key. In ARK, a third party does the coordination and can choose not to participate.
I understand ARK is essentially an improved channel factory. But channel factories already exist in Lightning without a central coordinator.
Have you tried ARK on mainnet? I'd like to know your real experience with coordinator availability.
Thanks again for sharing - this is what makes this community valuable.
ESPAÑOL
Gracias por la corrección, es justo lo que buscaba - entender mejor estos protocolos.
Tienes razón en que ARK no es custodial técnicamente. Los vTXOs son transacciones pre-firmadas y el usuario mantiene control sobre su salida on-chain. Mi error fue generalizar "coordinación" como "confianza".
Lo que me preocupa de ARK es otro matiz:
Privacidad: El coordinador ve quién paga a quién. En Lightning, el enrutamiento es a través de HTLCs y cada salto solo ve a sus vecinos. En ARK, el coordinador tiene visibilidad completa del grafo de transacciones.
Disponibilidad: Si el coordinador se niega a coordinar tus vTXOs, estás dependiendo de que alguien más lo haga. En Lightning, si un nodo cae, la red sigue funcionando a través de otros caminos.
Sobre la comparación con canales: Sí, cada nodo Lightning coordina, pero la diferencia es que en Lightning el estado final lo controlas tú con tu clave. En ARK, la coordinación la hace un tercero que puede elegir no participar.
Entiendo que ARK es esencialmente un channel factory mejorado. Pero los channel factories ya existen en Lightning sin coordinador central.
¿Has probado ARK en mainnet? Me gustaría conocer tu experiencia real con la disponibilidad del coordinador.
Nuevamente, gracias por compartir - esto es lo que hace valiosa esta comunidad.
English:
Thank you so much for this initiative! 🙌
AskSN was actually one of the very first territories I posted in when I joined Stacker News, so seeing it come back to life feels special to me. It's always been a place where curiosity meets community, and that's something worth preserving.
I love the incentive model you're proposing—it's perfectly aligned with the spirit of Bitcoin. Rewarding quality participation isn't just about the sats; it's about signaling that we value thoughtful contributions and genuine engagement. That's how healthy communities are built.
Special shoutout to @Aardvark for planting the seed, and to @siggy47 for inspiring this approach. You're standing on good shoulders, and I'm excited to see where this new stage takes us.
Count me in. I'll do my best to contribute quality posts and help keep this feed alive. No question is too small, too technical, or too absurd—that's exactly what makes this space great.
Let's make AskSN thrive again. 🧡
Español:
¡Muchas gracias por esta iniciativa! 🙌
AskSN fue de los primeros territorios donde publiqué cuando empecé en Stacker News, así que verlo renacer tiene un significado especial para mí. Siempre fue un lugar donde la curiosidad se encuentra con la comunidad, y eso es algo que vale la pena mantener.
Me encanta el modelo de incentivos que propones—está completamente alineado con el espíritu de Bitcoin. Recompensar la participación de calidad no es solo por los sats; es una forma de decir que valoramos las contribuciones reflexivas y el compromiso genuino. Así es como se construyen comunidades saludables.
Un reconocimiento especial a @Aardvark por sembrar la semilla, y a @siggy47 por inspirar este enfoque. Estás parado sobre buenos hombros, y me emociona ver hacia dónde nos lleva esta nueva etapa.
Cuenta conmigo. Haré mi mejor esfuerzo por aportar publicaciones de calidad y ayudar a mantener vivo este feed. No hay pregunta demasiado pequeña, técnica o absurda—eso es exactamente lo que hace grande a este espacio.
Que AskSN vuelva a florecer. 🧡
I completely understand you. Running your own Lightning node with the goal of supporting decentralization is a fantastic step. And your concern about inbound liquidity is the main challenge every node operator faces, especially when trying to avoid centralised intermediaries.
As you mentioned, the "inbound liquidity" problem is like having a shop open but no cash in the till to give change: you can send payments but struggle to receive them from others. Let's look at how to tackle this and which tools can help.
🔧 Decentralised strategies for inbound liquidity
PeerSwap – Peer‑to‑peer rebalancing
PeerSwap is a tool that should fit your approach well. It's a plugin that allows direct rebalancing between peers using atomic swaps, without needing an on‑chain Bitcoin transaction. This drastically reduces on‑chain fees, makes moves almost instant, and removes central intermediaries.
Lightning Loop – From the creators of Lightning
If you prefer a more established solution backed by the teams building the network, Lightning Loop (from Lightning Labs) is a non‑custodial submarine swap service that helps you rebalance liquidity between the main chain and the Lightning network.
· Loop Out – converts funds from your Lightning channel to on‑chain Bitcoin, freeing up inbound capacity without closing the channel.
· Loop In – does the reverse, sending funds from the main chain to your Lightning channels.
Buying channels (Liquidity Ads) – The decentralised marketplace
Another alternative is to "buy" inbound liquidity in a decentralised way. You can use peer‑to‑peer liquidity markets like Amboss Magma or Lightning Pool, which let you connect with Liquidity Service Providers (LSPs) without going through a centralised exchange.
· Amboss Magma – the largest liquidity marketplace on Lightning, easy to use and node‑implementation agnostic.
· Lightning Pool – integrated into the LND suite, uses a scoring system, though it usually requires a bit more technical knowledge.
Submarine swaps – The technical foundation
At their core, submarine swaps are what make all these tools possible. They are a type of trustless atomic swap that moves value between the on‑chain layer and the Lightning network using HTLCs (Hash Time‑Locked Contracts), guaranteeing atomicity. The solutions mentioned (Loop, Boltz) are concrete implementations of this concept to solve liquidity.
💡 Best practices for running a reliable node
· Open larger channels with well‑connected nodes – instead of many small channels, open a moderate number with good capacity. Look for well‑established, reputable nodes for effective connectivity.
· Optimise your routing fees – charging for the use of your channels is essential for sustainability and balance. Adjust your routing fees and use tools like charge‑lnd to set dynamic policies.
· Combine tools to automate – as your operation grows, automation helps. A good combination is PeerSwap for quick, cheap peer‑to‑peer rebalancing and Loop for larger adjustments that involve the main chain.
· Circular rebalancing – a manual technique where you send a Lightning payment to yourself through the network, using your node's "send to self" function or a trusted friend.
🚀 Upcoming innovations
· RailsX (Amboss) – a decentralised exchange (DEX) native to Lightning that enables atomic peer‑to‑peer swaps, further decentralising capital flow on the network.
· Liquid Swaps (Boltz) – their Autoswap service automates rebalancing using the Liquid sidechain, offering very low fees and a "just works" solution to maintain liquidity.
· Multi‑channel – new multi‑participant channels that don't require inbound liquidity are being researched, which would radically improve capital efficiency in the future.
Managing the liquidity of a Bitcoin node can be complex at first, but with practice it becomes routine. The key is to start with a strategy, test the tools, and adjust your parameters little by little.
If you have any further questions along the way, I'm here to help. Best of luck with your node!
🔗 Useful links
· Lightning Loop
· Amboss Magma
· PeerSwap GitHub
· Lightning Pool
· Boltz
And most importantly, the guides by @DarthCoin (https://darth-coin.github.io/) will help you a great deal in this space. They are an invaluable resource for anyone running a Lightning node, from beginner to advanced.
Excelente publicación. Es importante señalar que en el caso de Phoenix la apertura de canal vía Lightning cobra 1000 SAT+ 1% de lo que se recibe+ fee de minería, cuando se hace splice-in vía Lightning se debe pagar 1% de lo recibido+fee de minería.
Por lo tanto usar depósitos Onchain es más económico ya que solo pagas fee de minería (por la transacción y al momento del swap) , pero siempre es más económico que hacerlo con depósitos Lightning, además al aceptar direcciones Taproot se hace más barato y privado.
Otro elemento es que como señalas, Phoenix tiene opción de extracción directa a Onchain, pero así como cada depósito Onchain hace splice-in del canal, las extracciones Onchain reducen el tamaño y muchos usuarios nuevos no conocen esta característica.
Gracias hermano por siempre estar compartiendo tan valiosa información.
Friend @DarthCoin, this proposal is excellent—I’m a huge fan of nuts. I believe they should be a staple in every human’s diet, just like bread and cheese. Here, we can only find peanuts and roasted cashew nuts, which have to be roasted outside the house because the smoke they give off is toxic.
Honey was my ally during a tough time in my life when I ate nothing but honey for a week. Cocoa is a fruit from the eastern region here, and whenever I get the chance to buy some from those who bring it, I love it. So, I would truly enjoy having a delicacy like the one you’re showing. Thanks for sharing!
In my case, I use the Community's custodial wallet, where I only keep very basic funds—up to 10k SAT, and sometimes less. I use Phoenix as a self-custody wallet because I live in a country with probably one of the worst internet connections out there. I was using Blixt, but I had to stop because of synchronization issues. However, I am in favor of full self-custody. Even for merchants who want to run their own node with their own LNbits to manage multiple wallets and extensions, the suggestion here is Phoenixd + LNbits on a VPS.
I really appreciate your suggestion; it will be another option we will consider. We will read all the documentation and test the solution. I reiterate my gratitude.
Thank you for your words. Truly understanding these basic aspects of the fiduciary system could help people turn to Bitcoin, although some realize they’re being robbed and still cling to fiat. Layer 0—that is, people—can be strange at times.
🇬🇧 English
I’m sharing my personal repository “Fundamentos Técnicos de Bitcoin”, where I’m publishing my study notes and articles from the Librería de Satoshi course on Bitcoin’s technical foundations.
It’s a work-in-progress aimed at learners who want to understand Bitcoin from the ground up—covering its history, cryptographic principles, and technical design.
📂 Repository: Fundamentos Técnicos de Bitcoin
You can collaborate directly through pull requests or open issues with your suggestions, corrections, or additional resources.
Feedback is always welcome—let’s make this a valuable resource for the community! ⚡
🇪🇸 Español
Comparto mi repositorio personal “Fundamentos Técnicos de Bitcoin”, donde estoy publicando mis apuntes y artículos de estudio del curso de la Librería de Satoshi sobre las bases técnicas de Bitcoin.
Es un trabajo en desarrollo, pensado para quienes quieran comprender Bitcoin desde sus fundamentos: historia, principios criptográficos y diseño técnico.
📂 Repositorio: Fundamentos Técnicos de Bitcoin
Pueden colaborar directamente mediante pull requests o crear issues con sugerencias, correcciones o recursos adicionales.
¡Todo aporte es bienvenido para que sea un recurso útil para la comunidad! ⚡
Hello. Actually, this solution exists because the tools are already built, so anyone with a bit of curiosity and need can combine them—especially now that LNbits allows for a more seamless integration with Phoenixd. In Cuba, it's a solution for those who want self-custody on ultra-slow connections and with limited resources, since with just 21.5k SAT, you can open a 2M SAT channel. But regarding this particular post, I don't know anything. I hope I can meet the author of the post, who is a doctor like me, to exchange experiences and see what they've achieved. That's all I can say.
🇬🇧 English
Thanks to everyone who commented and contributed valuable insights in this thread! Your feedback and encouragement helped us complete the first version of the guide for using LNbits with Phoenixd as a self-custodial Lightning solution.
We’ve just published a detailed step-by-step guide for implementing this setup on Linux x64, which could be especially useful for merchants or users in regions with limited connectivity or infrastructure.
🔗 Check it out here:
👉 https://github.com/Delgado74/LNbits-and-Phoenixd-on-your-Linux-x64-machine
We welcome any feedback or contributions to improve or extend this solution to other platforms!
🇪🇸 Español
¡Gracias a todos los que comentaron y compartieron ideas valiosas en esta publicación! Sus sugerencias y apoyo nos ayudaron a completar la primera versión de la guía para usar LNbits con Phoenixd como solución Lightning autocustodia.
Ya está disponible una guía detallada paso a paso para implementar esta solución en Linux x64, especialmente útil para comerciantes o usuarios en regiones con conectividad limitada o pocos recursos técnicos.
🔗 Puedes verla aquí:
👉 https://github.com/Delgado74/LNbits-and-Phoenixd-on-your-Linux-x64-machine
¡Cualquier sugerencia o contribución para mejorarla o adaptarla a otras plataformas será muy bienvenida!
Thank you very much, my friend @DarthCoin, always with your great recommendations. We all have to be very careful when using public nodes for routing. It’s always great to have your help.
Thank you for the suggestion. However, one of the key challenges we face is synchronization with Neutrinos. If Zeus alone could resolve this—given its integrated POS system—it would largely address the issue.
We did evaluate the LND + Neutrinos option, but latency constraints in our environment make it impractical. Currently, we’re operating LNbits + LND in custodial mode via the community node, though our priority now is achieving greater sovereignty: your own node, your own LNbits instance with tailored extensions (including LNDHub), and even self-hosted BTCPay Server if desired. The main obstacle, however, remains our extremely slow internet connection.
Thank you for your words. Remember that the only thing you can't do is what you don't want to do. So if at any point you want to go down the rabbit hole of programming, take the leap and don't be afraid, because it's an extraordinary journey.