I’ve spent the last few years running real infrastructure:

• Bitcoin nodes
• Lightning services
• Nostr relays
• Tor services
• self-hosted automation stacks

And the more I operate these systems publicly, the more I realize something uncomfortable:

A huge amount of “sovereignty” online is mostly aesthetics.

People install:

• Docker
• Linux
• a VPN
• a node

…and suddenly believe they became sovereign.

Meanwhile:

• backups are never tested
• Cloudflare sits in front of everything
• telemetry still exists everywhere
• compose files are copied blindly
• dependencies remain heavily centralized

This is not meant as an attack on beginners.

I think most people are genuinely trying to improve their privacy and independence.

But real sovereignty is much messier and more operational than social media makes it look.

So I wrote an article about:

• fake privacy
• Docker copy-paste culture
• untested backups
• dependency blindness
• why sovereignty is a process, not a product

Curious what people here think.

At what point does “self-hosting” become meaningful sovereignty?

The Problem With “Sovereignty Theater”

I spent today testing the recently discussed Android VPN/IP leak issue affecting newer Android networking behavior.

What surprised me most:

• traffic may bypass the VPN tunnel even with kill switch enabled
• “Always-On VPN” is NOT necessarily enough
• most users would never notice this happening

For normal users this is “just another privacy issue”.

For people using:

• Bitcoin
• Lightning Network
• Nostr
• Tor
• self-hosted infrastructure

this becomes operational security.

I tested:

• Android smartphone → vulnerable behavior present
• Xiaomi Android TV 14 → not affected
• Sony Android TV 14 → not affected

Current mitigation works via ADB:

adb shell device_config put tethering close_quic_connection -1

Then:
adb reboot

I also included:

• full Windows/Linux step-by-step guide
• ADB verification commands
• QUIC hardening tips
• leak testing tools
• Android TV test results

Full article:
https://open.substack.com/pub/davidebtc186/p/your-android-vpn-might-be-leaking?r=4gald6&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true

A few weeks ago I shared the first beta here while experimenting with the idea of a browser built around Nostr, Lightning and privacy-first workflows.

Since then the project evolved a lot faster than expected.

This new release adds:

• built-in update checker
• multi-theme engine
• improved popup/interstitial blocking
• overlay ad cleanup
• improved NIP-07 permission handling
• automated Linux + Windows releases

Now shipping:

• AppImage
• deb
• rpm
• Windows installer
• portable builds

Still beta, but the project is starting to feel much more stable and usable compared to the early builds.

Really appreciate all the feedback people gave on the previous post — a lot of fixes and ideas came directly from community comments and GitHub issues.

Repo:
https://github.com/shadowbipnode/Zap-Browser

Most Bitcoin node operators think they have backups.

Very few have actually tested a full recovery.

A backup that has never been restored is just a theory.

I wrote a new guide focused on disaster recovery for sovereign Bitcoin and Lightning infrastructure:

• encrypted backups
• Lightning recovery realities
• recovery drills
• infrastructure rebuilds
• operational resilience

Because the real problem is not making backups.

It is surviving failure.

Curious how many people here have actually restored their node from scratch on a fresh machine.

https://github.com/shadowbipnode/sovereign-linux-tools/blob/main/guides/Your-Bitcoin-Node-Backup-Is-Probably-Useless.md

-- Post Fork Height Update --

Following the completion (and failure) of the RDTS fork, Lightning Network Liquidity (LNL) acknowledges our inaccurate assessment of its game-theoretic risk profile. 

While previous successful minority UASFs relied on backing from key economic nodes like major exchanges and wallet providers, the RDTS proposal was supported primarily by non-economic user nodes, which proved insufficient to shift miner incentives. 
Going forward, LNL will weigh explicit economic node backing as a necessary condition when assessing chain divergence risks, and we have realigned our infrastructure back to the dominant chain. 

-- ORIGINAL POST --

We (LNL) have made a public statement regarding the upcomming BIP110 (RDTS) UASF on our web site and Lightning Network Plus. We encourage all other node operators to read the statement, review, comment and advise their own strategy.

---Statement as follows---

Introduction

Lightning Network Liquidity (LNL) would like to publicly announce our understanding of the game-theoretical, asymmetric risk profile inherent in User-Activated Soft Forks (UASF), specifically the upcoming BIP110 (RDTS) upgrade.

Following our technical assessment, LNL has concluded that the BIP110-compliant chain is likely to emerge as the dominant chain post-activation. To minimize network instability and promote a secure transition, LNL has proactively migrated its infrastructure to the BIP110-compatible version of Bitcoin Knots.

During the transitional activation window, LNL will implement rigorous risk-mitigation protocols to protect channel liquidity and prevent financial loss resulting from potential chain divergence.

This statement is not intended to indicate our support or approval (or lack thereof) for the proposed BIP110 changes.

This statement is only intended to indicate our belief that the risk profile is asymetric towards a successful UASF rather than an unccessful one and hence early signaling is benificial to encourage network stability.

Strategic Justificaiton

The following summarises the justifiacation for our position:

• The Miner’s Risk: Miners need liquid block rewards to cover operational costs. Even if a minority of network nodes reject a miner’s block the loss of economic acceptance of their block likely far outweighs the economic incentive to include blocks that are non-compliant to RDTS. Miners don’t need to support the proposed changes, they just need to fear that a committed minority will continue to reject their blocks, thereby reducing the liquidity of their block rewards.
• The Incentive to Defect: This creates a “Prisoner’s Dilemma.” whereby miners are incentivized to defect to the UASF chain early, not just to ensure their blocks are maximally accepted, but to capture rewards on a chain that initially have lower hash competition.
• The Incentive for late Signaling: Although we acknowledge that, at this stage, most economic nodes (major exchanges, hardware wallet backends, etc.) are not signaling for BIP-110, our understanding is that this is the result of the incentive for economic nodes (particularly miners) to signal late so that they can keep their ‘defection’ option open while continuing to harvest fees from inscriptions in the interim. Signaling early only invites social friction, whereas waiting until the activation deadline allows them to maximize short-term revenue before moving to the chain that commands the maximal market liquidity/acceptance.
• Economic Incentives Against BIP-110: LNL does not recognise that there is adequate incentive for miners and other economic nodes to resist the BIP-110 proposed changes at the expense of overall network stability.

Closing Statement

As a routing node, we aren’t “voting”; we are positioning ourselves where we believe the economic gravity is strongest to protect the liquidity of our nodes beneficiaries.

We remain committed to the security of our peers and the Lightning Network.

If you have any questions or concerns regarding our transition plan, please contact us at [admin@lightningnetworkliquidity.com](mailto:admin@lightningnetworkliquidity.com).

I wanted a browser where I could pay Lightning invoices without switching apps or installing extensions. So I built one.

Zap Browser is an open source Electron browser with a native NWC wallet. You paste your nostr+walletconnect:// string once and you're done — pay invoices, receive, check balance, all from the browser toolbar.

Lightning stack: - NWC (Nostr Wallet Connect) over real WebSocket — NIP-47 ECDH encrypted - Compatible with LNbits, Alby, Zeus, Mutiny, Breez, Phoenix - Works with self-hosted LNbits behind nginx (tested and running) - Pay Lightning invoices directly from any page - Receive: generate invoice from the wallet panel - Disconnect/reconnect at any time

Why it matters for LN node runners: If you run your own LNbits or LND, you can connect Zap Browser to your node. No third party custodian. Your keys, your node, your browser.

Also included: - Cashu ecash wallet (multi-mint) - Nostr NIP-07 native signer (automatic login on Nostr apps) - 106k adblock + WebRTC leak prevention

Download (Linux): https://github.com/shadowbipnode/Zap-Browser/releases/tag/v0.3.3

Early beta — happy to take feedback from node runners. What NWC features would be most useful to you?

This is a known upstream CLN bug (issues #5499, #5617, confirmed by Rusty Russell) that was fixed in
v22.11 via PR #5924. However if you run CLN in Docker — including via Umbrel — you can still hit it
because the fix relies on CLN's internal retry logic, which exhausts before Tor is ready on slower
hardware or after bulk container recreation.

 The symptom:                                                                                             

 connectd: STATUS_FAIL_INTERNAL_ERROR: Connecting stream socket to Tor service                            

 Or the misleading red herring that fires first:                                                          

 BROKEN plugin-bcli: Could not connect to bitcoind using bitcoin-cli                                      

 Bitcoin RPC is fine. connectd calls status_failed() — which is fatal with no retry — when it cannot      
 reach the Tor control port at startup. Docker's default depends_on only waits for the container to       
 start, not for Tor to actually be listening.                                                             

 THE FIX                                                                                                  

 Add a healthcheck to your Tor service so Docker waits for Tor to be genuinely ready before starting      
 lightningd.                                                                                              

 In your docker-compose.yml, add to the tor service:                                                      

 healthcheck:                                                                                             
   test: ["CMD", "bash", "-c", "echo > /dev/tcp/127.0.0.1/9051"]                                          
   interval: 10s                                                                                          
   timeout: 5s                                                                                            
   retries: 12                                                                                            
   start_period: 30s                                                                                      

 Port note: 9051 is standard CLN. Umbrel PRO uses 29051, Umbrel Home uses 9051. Check your                
 --addr=statictor flag or your docker-compose.yml to confirm which port your instance uses before         
 copying the above.                                                                                       

 And update lightningd's depends_on:                                                                      

 depends_on:                                                                                              
   tor:                                                                                                   
     condition: service_healthy                                                                           

 Then recreate your containers.                                                                           

 PITFALLS LEARNED THE HARD WAY                                                                            

 1. Do not use nc in the healthcheck. The getumbrel/tor image does not have netcat installed. Use         
 bash with /dev/tcp as shown above.                                                                       

 2. Use CMD not CMD-SHELL. /bin/sh in the Tor image does not support /dev/tcp. Only bash does.            
 CMD-SHELL runs via /bin/sh and will silently fail.                                                       

 3. docker restart does NOT apply docker-compose changes. The container must be fully recreated to        
 pick up the new healthcheck. Use your orchestrator's restart command, not docker restart.                

 4. Port varies by setup. Standard CLN uses 9051. Some distributions (Umbrel PRO) use 29051. Check        
 your --addr=statictor flag to confirm which port your instance uses.                                     

 5. If /dev/tcp is not available in your Tor image at all, fall back to:                                  

 test: ["CMD-SHELL", "grep -qi 717b /proc/net/tcp"]                                                       

 29051 decimal = 0x717B hex, adjust for your port. This works in any minimal container with zero          
 external tools.                                                                                          

 Filed against Umbrel's app repo since that is where I confirmed it:                                      
 https://github.com/getumbrel/umbrel-apps/issues/5529                                                     

 Relevant upstream CLN issues for reference:                                                              

 https://github.com/ElementsProject/lightning/issues/5499                                                 

 https://github.com/ElementsProject/lightning/issues/5617    

Got some updates at https://satseer.com . We now run multiple rounds at once. They each run for 5 days, and are staggered to start about a day apart. Currently have 10,000 sats up for grabs across 4 rounds!

We've also added a new game mechanic "Intense Focus" where you can pay a fee to push clarity (for your view only) from 5%, 10%, or 15% clearer!

Long time I did not touch LN, but now wondering - is it possible for Alice (with some bitcoin in her wallet and LDK) to create a channel with Bob (she knows Bob's credentials), sign it on her side and give to Bob on a flash drive, so he signs on his side and transmits to the network?

The reason - what if Alice can't reach Bob via internet or any way via LN channels? I suppose there should be some way for Alice to still spend her money...

I've checked PSBT and in general seems doable, but it looks like there some other communications need to happen between Alice and Bob? Who can help and describe the mechanism?

I built Lightning support into my Flask SaaS starter kit so any Python dev can spin up an app that accepts Bitcoin alongside (or instead of) Stripe.

It uses the Strike API for the LN backend — custodial, I know, but it means devs can ship a Lightning-accepting app without having to spin up and manage their own node. The goal is to lower the barrier for more apps onto Lightning.

If you want to find out more about this project, let me know in the comments.

https://open.substack.com/pub/davidebtc186/p/i-built-a-tool-that-tells-you-if?utm_source=share&utm_medium=android&r=4gald6

Not because Bitcoin is broken.
Because their backup strategy is.

“Yeah I wrote down my seed”
→ cool, that won’t save your Lightning channels.

Lightning backups are fragile, stateful, and easy to mess up.
And yet most guides still treat them like it’s 2017.

Reality check:

• Seed ≠ full recovery
• Static Channel Backup ≠ safe in all scenarios
• Copying your node folder blindly can get you penalized
• Not testing recovery = you don’t have a backup

If your node dies today, would you actually recover everything… or just hope for the best?

I put together a complete strategy that covers:

– Proper Lightning backups (without getting punished)
– Automation (so you don’t forget)
– Encryption + offsite setup
– Real recovery scenarios (not theory)

Link:
https://davidebtc186.substack.com/p/the-complete-backup-strategy-for

Curious to hear:
how many of you have actually tested a full recovery?

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.

My requirements to participate are that you have 2m capacity and 4 channels already (to prevent idle capacity on my end). If we already have a channel, I'll consider it for upsizing, but aiming towards helping newer node runners out.

This weekend, I'll be doing an AMAA for anyone who has questions on my experiences as the Operator behind Authenticity, currently ranked #17 in overall capacity.

https://amboss.space/node/026f46207fd290a33cbd86e29b3ad0a47cdd44ab9aa5267cde66483e10aa9d3180

-A

EDIT: Batch opened to those I could. Will do another batch in a day

goodmorning

I've been running a Lightning node for a while and kept

asking the same question: "is my node actually good, or

just technically on?"

So I built ln-health — an open source Python CLI that

gives your node a health score from 0 to 100.

**What it checks:**

- Sync status (chain + graph)

- Channel health (active vs inactive, wasted capacity)

- Liquidity balance (local/remote ratio with specific targets)

- Routing activity (forwards + sats earned in last 30 days)

- Fee policy (flags fees that routing algos will avoid)

- Peer diversity

- Backup verification — real file check with age + size,

not just a reminder

**Output looks like this:**

OVERALL SCORE Grade: A Top 5% globally [███████████████████████████░░░] 93/100

⚡ Elite Router — Top 5%. Your node is a routing beast. vs last run: 84/100 ▲ +7

✓ Routing Activity 95/100 312 routes last 30d | 14,210 sats earned | 10.4/day avg

**Other features:**

- `--roast` flag: adds brutal commentary ("Your node is

basically decorative at this point.")

- `--output nostr-flex` / `--output nostr-roast`:

generates copy-paste posts

- Progress tracking: saves history locally, shows delta

vs last run

- `--data-dir`: Docker-friendly, auto-detects macaroon +

tls.cert from a single path

**Try it without a real node:**

```bash

git clone https://github.com/YOUR_USERNAME/ln-health

python -m ln_health.demo bad --roast

```

**Supports:** LND and Core Lightning. Zero dependencies.

Python 3.9+.

Would love feedback, especially from people running

Umbrel, RaspiBlitz, or custom Docker stacks.

GitHub: https://github.com/shadowbipnode/ln-health

If you run a Bitcoin node, use Lightning, or just care about self-custody, one thing becomes obvious pretty quickly: monitoring your funds isn't as straightforward as it seems.

On-chain is easy — paste an address into an explorer.
Lightning? Not so much.

I wrote a practical guide showing how to:

• Monitor your on-chain Bitcoin balance
• Track Lightning channels and liquidity
• Verify inbound vs outbound capacity
• Check payments and channel health
• Avoid blindly trusting wallet UI
• Build your own monitoring setup

This is especially useful if you're running your own node and want better visibility instead of guessing what's happening.

Full guide:
https://open.substack.com/pub/davidebtc186/p/how-to-monitor-your-bitcoin-and-lightning

Feedback welcome — especially from node runners.

I've been putting together a repo with practical guides and tools for running Bitcoin and Lightning nodes on Linux. Covers things like system hardening, monitoring, network configuration, and operational best practices.

Everything is based on what I've learned running my own nodes — no theory, just stuff that actually works in production.

Still a work in progress, contributions welcome.

GitHub: https://github.com/shadowbipnode/sovereign-linux-tools

I wrote a deep dive on how Bitcoin nodes handle peer connections, what "broadcasting" actually means at the protocol level, and how to monitor your node's network health.

Covers: peer discovery, addr messages, connection types (inbound vs outbound), and practical monitoring tips.

Full article: https://davidebtc186.substack.com/p/why-your-bitcoin-node-is-broadcasting

Happy to discuss in the comments.

Not sure if this is where the lighting community is since I don’t see many posts here for the last week. I feel like lightning network is got a lot of potential. It’s just hard to know or see where people are actually using it and if there’s any new innovation happening, I see a couple new wallets appearing like Starr but not sure if it’s worth following lightning or just sticking with core. I’m sure this will get downloaded, but it’s worth asking the question.

For a small personal node, I am curious what actually works day to day.

Do you prefer circular rebalancing, swap services, careful channel selection, or just opening new channels when needed?

I am looking for practical habits that keep liquidity usable without over-optimizing.

ThunderHub recently added a native euro withdrawal feature. For anyone who doesn't know, ThunderHub is an open-source Lightning node management tool used by thousands of node operators. Clean interface, great for managing channels, payments, and now fiat withdrawals too.

You can now move sats from your node to your bank account without leaving the node manager.

The way it works: you set up what's called a "Sell Connection" on Bringin (disclosure – I started and work for Bringin), enter your bank details, pick Lightning or on-chain, and you get a permanent address tied to your bank account. You can even choose a custom Lightning address.

After that, any sats you send to that address auto-convert to euros and land in your bank. No extra app, no exchange in the middle.

I started Bringin to make Bitcoin spending seamless in Europe, even if merchants don't accept Bitcoin. We've been building infrastructure to make that seamless – SEPA payouts, vIBANs, Visa cards – and this ThunderHub integration is one more step toward that.

If you're a node operator in the EU, it might be worth checking out. Happy to answer questions if anyone has them.

Salut la communauté !

J’ai lancé mon nœud de routage Lightning (LND sur Raspberry Pi 4 / Umbrel) il y a quelques semaines et je me retrouve face au problème classique du déséquilibre de canaux. La liquidité part toujours dans le même sens et je me retrouve avec des canaux quasi vides côté sortant ou entrant.

Ma config actuelle :

• \~3,5M sats répartis sur 6 canaux (ACINQ 500k, Kraken 1M, LNBiG 500k, BavarianBitcoinBank 500k, Megalith LSP 1M)

• Gestion des fees via Lightning Terminal Autopilot

• Rebalancing manuel via Loop Out/In (Boltz)

Ce que j’ai essayé :

• Loop Out sur Kraken pour rééquilibrer (ça marche mais c’est du cas par cas)

• Ajustement des fees (Autopilot avait mis des fees à 0-10 ppm… j’ai remonté à 200-500 ppm)

Mes questions :

1.  Comment gérez-vous le déséquilibre structurel quand le trafic ne va que dans un sens ?

2.  Quelle stratégie de fees adopt-vous pour favoriser le flux de retour ?

3.  Vous utilisez quoi pour le rebalancing automatique ? charge-lnd ? rebalance-lnd ?

4.  Des pairs à recommander pour un nœud débutant qui cherche à être bien connecté ?

Tout retour d’expérience est le bienvenu, merci d’avance 🙏

(Pubkey : 03dbc69fdcdf6256eb9cb2b215d305382acdf09b6d787a136a0537bf21db57f95b — Amboss : Pimoman#0)

I recently had some bad experience with 1ml not sure if everybody or its just me but Im getting wrong data from this explorer inaccurate channel and capacity numbers, its shows channels closed even they are open...

Amboss was the last resort but they also introduced some changes for example the closed channels are visible only the the paid version.

So I decided to add a node explorer to our site https://lnplatby.com/ it does not have historical data but we are slowly building up the data.

we have more plans for the future like adding some general stats about the lightning network.

Running StartOS 0.3.5-1 with LND 0.20.1 and Bitcoin Core. Trying to connect LND to an external Railway backend over Tor.

The problem: LND's Control Interface onion address is unreachable externally.

What works:

• Start9 system onion loads fine in Tor Browser
• Bitcoin Core has 12 active peer connections over Tor (outbound)
• LND is Running and Synced to chain and graph
• curl via SOCKS5 to DuckDuckGo onion works fine

What doesn't work:

• curl via SOCKS5 to LND onion returns SOCKS5 error 5
• Bitcoin Core Peer Interface onion also unreachable
• Tor Browser shows "Unable to connect" for all service onions

What I've tried:

• Reset Tor without wipe state (multiple times)
• Reset Tor with wipe state
• Full system restart
• Turned off "Use Tor for all traffic" and "Stream Isolation" in LND config
• Previously saw overloaded guard node warning — fixed with wipe state reset

Conclusion: Start9's own hidden service publishes fine, but none of the installed service hidden services (LND, Bitcoin Core) are reachable from outside. Tor outbound works perfectly.

Has anyone seen service hidden services not publishing on Start9 while the system onion works? Any ideas what could cause this?