Would you use crypto to book hotels or flights? If not, what's the biggest obstacle for you - volatility, fees, taxes, or limited acceptance?

Phoenix Wallet's documentation says that if ACINQ disappears completely, users can either wait for Phoenix to move the funds to the "Final wallet" after a force close, or manually recover their funds by importing the BIP39 seed into a standard BIP84 wallet such as Electrum.

My question is about the second option.

As I understand it, importing the BIP39 seed into a regular on-chain wallet only restores the Bitcoin private keys derived from the BIP84 path. However, it does not restore the Lightning channel state or any Lightning-specific data.

So how would such an on-chain wallet recognize or recover funds that were still locked in Lightning channels? Would those funds only become recoverable after the channels have already been force-closed and the outputs have been published on-chain? Or is there some mechanism that allows recovery directly from the seed without access to the Lightning channel state?

Here is the official documentation for their wallet, where I found this information:

https://phoenix.acinq.co/faq

Thanks in advance for those who help me!

Throwaway account for obvious reasons.

Seriously, if you do not provide a service, running a lightning node is complete bullshit. You take a huge risk having a hot wallet. I shrinked my electricity costs down to 120 sats a day. Still, on some days, I can make up for that, on others I cannot.

The fee management I automated. Peer disovery for channel creation as well, with some manual intervention.

I saw some bigger nodes having the mission of "helping the lightning network grow", but us "routing nodes", nobody really needs. Meaning, that as a common pleb, you should always rely on something else than your own node. Yeah you can do this for learning, but what's the use for that, if node running probably never will be a thing you seriously get in touch with?

I wonder how you guys see that. I will probably keep my node up, but with just my very small wallet connected to it and with 1-2 small channels, because I somewhat enjoy doing that. But that 1 BTC scared me, as it's not that I'm some OG or whatever who has many Bitcoin, I just read everywhere that starting below that is almost useless. I'm here to tell you that even with 1 BTC, you will get absolutely nothing. Maybe I'm just not good enough to make it work, but even if you end up ahead of the race, I don't see how such a thing is worth the risk.

NOBODY needs my node. All I can do is bend over and offer lower fees than the bigger nodes that actually get used provide, to get transactions in. But since many people spin up nodes like that, it's a competition. You either get the routes or you don't. A race to the bottom.

A lot of effort, a race to the bottom, negative returns and hot-wallet headaches. And AI-nodes probably further lower my chances of success, as I guess there are a lot of people training AI models to run their nodes. I don't really know if they exist, but I can't believe the don't.

The be your own bank dream has popped in my opinion. As soon as the lightning services need to work with the governments, it might be worth having a look again, but I'm pretty sure it is IMPOSSIBLE to beat the fees you pay for something like Phoenix that has zero headaches, a nice UI and no additional work involved.

What is your opinion here?

PS: Despite the frustration I offered here, I'm still interested in the network. I fondly believe in the future of the LN network, just not in the "be your own bank" thingy, apart from hodling bitcoin. I just want to see your viewpoints. I hope they are humble, as I have the feeling that a successful lightning node runner would say "yeah, it's not worth it" so that their node gets less competition. I know there are ppl running successful routing nodes, but the once I managed to get in contact with invest a looot of time doing things manuall and see it kinda as a hobby.

Lightning Labs open-sourced lightning-agent-tools

in February 2026 — a toolkit for AI agents to

transact autonomously on Lightning.

The technical stack:

lnget — like curl but Lightning-aware. Detects

HTTP 402 responses, pays the invoice, caches

the macaroon, retries. Fully automatic.

Aperture — reverse proxy that turns any API

into a pay-per-use Lightning endpoint. Full

agent-to-agent commerce loop.

Remote signing — keys live on a separate

signer machine. Agent handles payments but

never touches private keys.

Scoped macaroons — cryptographic spend limits

per agent: "max 1000 sats/hour" or

"invoices only, no payments."

MCP support — Claude Code, GPT, and custom

AI frameworks can query node state and trigger

payments via Model Context Protocol.

For node runners, this is directly relevant:

AI agent micropayments mean more routing

traffic and demand for well-connected,

liquid nodes.

Full breakdown with practical example:

https://davidebtc186.substack.com/p/ai-agents-are-starting-to-pay-in

Hi All,

If you want a free 1m channel (could be larger), post your pubkey/Amboss link here. If it's inactive for over 30 days, I'll be closing it. It'll have auto-fees and rebalancing from my end. My plan is to giveaway roughly 10 channels over the next few days. If the channel is active, I'll increase it's size.

This will be different than my past giveaways as I'll be opening it with my new node, focused on smaller channels (and as a test environment for me).

Integrity - https://amboss.space/node/030a118c885489ff9a751bd5c8b1941bc22c7b88ade7e0fe36fe3df87dd15c5e91

My requirements to participate are that you have 2m capacity and 4 channels already (to prevent idle capacity on my end). I won't be duplicating channels I already have open, and if I opened one in my last giveaway I may not open a new one (due to lack of routing).

-A

*PS* My next post plans to be that long promised architecture post in the next few weeks - along with an update of the monitoring dashboard I've been working on.

OpenRouter needs Lightning now!

What Bitcoin Lightning value added businesses
or service you could start offering by running your own node and make a profit eventually.

Future businesses and ideas are all welcome to be listed or shared.

If Bitcoin is like oil of 21st century- what can be innovated as value added on top using this digital gold as a commodity?

Freeport is a P2P marketplace (rides, services, goods) running entirely on Nostr relays - no server, no middleman. It now has payments built in:

- Self-custodial Lightning (Breez SDK / Spark) - the app never holds funds

- Wallet key derived from your Nostr key: one backup covers identity + wallet

- No signup - keypair generated on-device, optional passkey login

- Lightning address, bolt11, on-chain

- Confirmed deals get a Pay button / QR with the agreed amount, auto-converted from fiat

Fun fact: you can download the HTML file from releases page to run the whole app 😎

just heads up for umbrel users TOR was down more info on https://github.com/getumbrel/umbrel/issues/2189

Anyone migrated a Bitcoin Lightning node from an AWS set up to Umbrel OS?

Bitcoin lightning ⚡️ node service provider Voltage is closing down its services to self serve customers. Any alternatives or best tips to self host a Bitcoin lightning node?

Revolut is integrating Lightning via

Lightspark. Technical reality check:

What users GET:

• Faster Bitcoin transfers
• Lower fees than on-chain
• Human-readable payment addresses (UMA)

What users DON'T get:

• Lightning keys
• Channel control
• Privacy (fully KYC'd)
• Routing fees
• Any sovereignty whatsoever

Every payment through Revolut's Lightning

is linked to your passport, logged by

Revolut, reportable to financial

intelligence units, and freezable at any

time.

That said — there are legitimate upsides:

• Proves Lightning reliability at scale
• Increases overall network liquidity
• Normalizes Lightning Addresses

• Could onboard people who later ask

  "why do I need Revolut for this?"

The sovereign alternative is a self-hosted

LND node with NWC for Zaps. More work.

Worth it.

Full article:

https://davidebtc186.substack.com/p/revolut-lightning-good-news-or-a

Running your own node? Happy to compare

notes in the comments.

Donate: [[email protected]](mailto:[email protected])

I've been working on a middleware that exposes a SQLite database through an HTTP API where each request carries a micro‑payment, using the x402 protocol (HTTP 402 Payment Required). The code is here: https://github.com/damienos61/SQLite-x402-Gateway

Core technical challenge : the gateway needs to accept an arbitrary SQLite database, inspect its schema, and generate priced REST endpoints automatically — without requiring the user to write route definitions. This means parsing SQLite metadata (sqlite_master, PRAGMA table_info) and inferring column types from actual data to produce consistent JSON responses, since SQLite is weakly typed.

Payment abstraction : the x402 protocol requires a handshake — client calls a protected route, server responds with a 402 status and a price, client provides a payment proof, server verifies and returns data. To keep the code flexible, I abstracted the payment verification behind an interface with two implementations :

• A simulation mode that handles the protocol flow with fake signatures — useful for testing without crypto setup.
• A real mode integrated with Coinbase's x402-express SDK, configured for the Base Sepolia testnet (test USDC, no real funds).

The switch between modes is handled at the route level without recreating handlers, by injecting the appropriate verifier instance.

Database abstraction : the initial version used SQLite natively, but adding PostgreSQL support required abstracting both the SQL dialect (parameter placeholders, schema queries, pagination syntax) and the schema introspection logic — Postgres metadata is structured differently and more verbose. The inspector now adapts to the database type at runtime.

Performance considerations : SQLite isn't designed for high concurrent loads, so I added an in‑memory query cache with TTL invalidation, and implemented keyset pagination instead of OFFSET/LIMIT to maintain performance on large tables without fixed indexes. Rate limiting (sliding window per IP) is also included to prevent abuse.

Observability : rather than maintaining a static OpenAPI file, the spec is generated dynamically from the detected routes and their associated pricing. The challenge was describing query parameters (filters, columns, pagination) and linking them to the price metadata in a machine‑readable format. Webhooks are also dispatched on each transaction to external endpoints (Slack, Discord, etc.).

Tooling : the project includes a CLI (monetize, start, generate-wallet), a client SDK for consuming the gateway, and a Docker setup. 14 unit tests run on each push via CI.

Known limitations are documented — the simulation mode is not a production blockchain integration, and the "upto" pricing schema (variable payment based on resources consumed) is only simulated server‑side, as no on‑chain implementation exists yet in the official SDK.

Please excuse my ignorance. I am a two-time stroke survivor and am not as mentally sharp as I was.

Can Lightning be used to run apps that require high GPU speeds? If so, how is it done?

TIA!!!

Hola, últimamente he eschuchado sobre esta wallet, que tiene opción para btc onchain, lightning y líquido. Con posibilidad de conectar a tu nodo, alguien la usa? Cual ha sido su experiencia? La recomiendan, actualmente uso muun para hotwallet

I don't know anything about crypto. Is it as convent as a normal subscription, like Youtube, where it charges the same amount each month automatically? Can it be set up to automatically charge the same $20 every month?

I have some questions regarding how Phoenix Wallet behaves on its initial deposit and how fees are applied in that context.

From what I understand, when a brand new Phoenix Wallet receives its first deposit — whether via on-chain Bitcoin or via Lightning — the wallet ends up creating a very similar initial channel in both cases, with comparable capacity and inbound/outbound liquidity after setup.

If that understanding is correct, I would like to better understand two related points:

First, what is the structural difference in how Phoenix handles the initial deposit depending on whether it comes from on-chain or from Lightning? In both cases, the result appears to be a newly created Lightning channel with very similar final balances and capacity. What exactly determines this similar outcome, and what is happening under the hood that leads both deposit methods to converge to such similar channel states at initialization?

Second, why does the fee structure differ between the two methods? The first Lightning deposit incurs a 1% fee in addition to on-chain mining fees, whereas the first on-chain deposit only incurs mining fees, and yet in both scenarios, it seems that ACINQ provides inbound liquidity, locks capital into channels, and uses the same underlying infrastructure to create a functional Lightning channel. If the 1% fee is meant to compensate for liquidity provision, infrastructure, and capital being locked in the channel, I am wondering why a similar fee is not applied to the first on-chain deposit, where essentially the same channel creation process appears to take place.

In other words, what is the exact technical or economic difference between these two initial deposit flows that results in both producing similar channel states, but only one of them being subject to the additional 1% fee?

Hey all,

I've mentioned this too many times in the past, but I'm finally able to push out the first iteration of my LND Lightning Dashboard project for feedback. It's very much a PoC to deploy a self-hosted docker Grafana, Prometheus, Loki stack to monitor and have a SPoG on your LND/LNDg setup.

This project will be published on GitHub in the next week or two. I'm currently sitting on the setup I have launched to feed in more data to check stability before the source goes public.

I would appreciate any feedback or requests people have on types of data they'd like to see visualized - whether from another location or currently not available.

https://docs.google.com/document/d/1SDfBKnJxaPmByGY4er9feJ59HgNN4kQJGwtZ86Cx7b4/edit?usp=sharing

Thank You!
-Auth

Last week I posted Conduit here (non-custodial Lightning wallets for AI agents, with spending caps the agent can't get around). Got some good feedback so figured I'd follow up.

The thing a few people kept bringing up: it's not enough to just block a bad payment, you need to be able to go back and see why it got blocked or allowed. And someone made a point that stuck with me — a payment blocked at 10x your cap and one that barely squeaked under are completely different situations, but if all you log is "allowed" they look the same. The second one means you're basically out of room and don't know it.

So I added that. Now every payment attempt gets recorded, including the rejected ones (those used to just vanish, which was dumb in hindsight). You get the amount, where it was headed, the cap at the time, the actual policy that was in force, and how close it got to the limit. Someone in the thread said the "how close" part is what turns it from a log into something you can actually debug with, which yeah, that's the point.

Anyway it's live. Mostly posting because the "ask people what's missing then build it" thing actually worked and I didn't expect it to work this well.

If you're building anything where software spends money on its own — what would you want logged before you trusted it?

repo: github.com/Jake1848/conduit

Need a wallet that will enable me to receive Ocean mining ⛏️ rewards over Lightning Bolt12 and will let me verify the message - any suggestions or ideas?

Posting this for builders interested in Lightning-style payment channels and cross-network payment infrastructure.

Fiber Network is a payment-channel network on CKB, and this hackathon is focused specifically on infrastructure, not consumer apps or token promotion. The part that may be interesting to LN developers is the overlap with familiar Lightning problems: routing reliability, channel lifecycle UX, payment failure diagnostics, liquidity tooling, LSP-style services, merchant payment primitives, and experiments around Fiber-to-Lightning connectivity.

The hackathon runs July 1-15, 2026, with a $20,000 prize pool. The organizers are especially looking for reusable infrastructure that helps developers, wallets, merchants, services, or node operators interact with Fiber more easily.

Relevant build areas include:

• Node dashboards, routing diagnostics, payment simulation, and failure analysis
• Wallet/channel management flows
• Liquidity dashboards and LSP-style tooling
• Merchant checkout/payment status infrastructure
• Cross-chain payment routing prototypes or Fiber <> Lightning experiments

Full announcement:
https://talk.nervos.org/t/gone-in-60ms-fiber-network-infrastructure-hackathon-announcement/10418

Disclosure: this is not a Bitcoin-only hackathon. I’m sharing it here because the technical design space overlaps with Lightning Network infrastructure, especially payment channels, routing, liquidity, and interoperability tooling.

Every guide tells you how to set up a Lightning node. Nobody tells you what happens after.

After months running a full LND node in production I wrote down everything that bit me — the things no documentation or tutorial ever warned about.

What's covered (behind paywall — first chapter free):

Chapter 1 — Force Closes (FREE)

The betrayal from liquidity marketplaces: after 30 days they close without warning. Funds locked in timelock sweeps. On-chain fees you didn't plan for. Why collaborative/ring-of-fire channels beat purchased liquidity every time.

Chapter 2 — Liquidity Traps (PAID)

Why opening channels toward top nodes (ACINQ, Bitfinex, WalletOfSatoshi) is a trap. They're liquidity idrovores — your side drains in hours. How fee management is actually flow control, not revenue.

Chapter 3 — LND in Production (PAID)

The btcd consensus divergence incident. UTXO sweeping bugs that don't announce themselves. Pathfinding failures that time out silently and why.

Chapter 4 — Tor Under Fire (PAID)

When Tor's DDoS attacks spike your CPU and degrade your node. Why this happens at a network level. Why clearnet is still worse. How I2P as a fallback helps.

👉 https://davidebtc186.substack.com/p/what-nobody-tells-you-about-running

Questions from other node runners welcome in the comments.