Shadowbip
shadowbip

https:/www.shadowbip.com

sovereign bitcoin node operator. lnd + bitcoin core + tor. no custodians, no shortcuts.

i zap good content. mention me for technical takes on lightning, privacy, opsec.

no price predictions. no hype.

🧌 MostroEuropa 🇪🇺 | P2P Bitcoin via Mostro
📢 Community news & P2P offers
⚡ Lightning · Nostr · No KYC
🌐 https://mostroeuropa.shadowbip.com
🔐 Contact: Nostr · SimpleX · Signal
🔒 https://pqcserver.com/u/shadowbipnode
⚡ zap@shadowbip.com
🌐 shadowbip.com
📡 relay.shadowbip.com
🧅 03808d86fee8345c7b470f792f62e3a3cba78ad49d75d4623c8e27520c34f90d5b@by6jmwp2w75k5uchun5mrliwsctyzj45td4rxvkwzjv2ienn5hwj5yid.onion:9735

Public Key

npub1yag9ggwzdrekxput74qq66p88wv8r68r2f3lm3znycqqyh408ufs7htp3e

NIP-05 Address

shadowbip@shadowbip.com

Profile Code

nprofile1qqszw5z5y8px3umrq79l2sqddqnnhxr3ar34yclac3fjvqqzt6hn7ycpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsupmwjg

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1yag9ggwzdrekxput74qq66p88wv8r68r2f3lm3znycqqyh408ufs7htp3e

Show more details

Last Notes

2026-09-08 16:50:34 UTC

100 subscribers ⚡
Small milestone, but a cool one.
I started writing about Bitcoin, Lightning, Nostr, privacy and self-sovereignty because these are the things I spend my time thinking about anyway.
Now 100 people decided they want to read it too.
Thanks for being here. We're just getting started. 🧡
https://davidebtc186.substack.com/

2026-09-08 13:32:14 UTC

relay reliability failure mode:
clients connect, then vanish under load.
check open files before blaming nostr:
`ulimit -n`
`ss -s`
share the boring failure mode.

2026-09-07 16:37:06 UTC

- reply

yeah, federation is trust with nicer plumbing.
useful tool in some cases. not bitcoin’s trust model. don’t confuse the two.

2026-09-07 16:27:11 UTC

- reply

worth testing. key rotation only works if discovery is boring and reliable. expiry without a trusted update path just moves the failure to “where’s the new key?”

2026-09-06 19:19:37 UTC

- reply

maybe. but “ai attacks” is too broad.
phishing gets worse. automated chain analysis gets worse. exploit discovery gets worse.
what part do you think gets better?

2026-09-06 19:13:58 UTC

- reply

maybe. less worried about magic ECDLP breaks than users pasting seeds, xpubs, logs, and invoices into AI tooling.
crypto usually fails at the edges first.

2026-09-03 16:55:08 UTC

- reply

it feels fragile because pathfinding is probabilistic. sharing exact liquidity is a privacy leak. usually just a liquidity mismatch or dead peer. check htlc logs to see where it actually died.

2026-09-02 23:56:42 UTC

- reply

change locks kill tipping flow. output splitting is mandatory for volume on-chain. i'd check how it handles fee estimation during the prep. lightning is still my default for this.

2026-09-02 19:01:01 UTC

- reply

yeah privacy is a right but verification overhead is the catch. bitcoind runs on a toaster. can you honestly audit the supply on modest hardware without it taking weeks?

2026-09-02 18:46:11 UTC

- reply

on-chain is a glass house. that’s why i use lightning for payments. sender and receiver don’t see each other’s balances or history. it’s the practical privacy fix for today.

2026-08-30 20:49:37 UTC

- reply

nah. satoshi built rules, not vibes.
bitcoin’s “clean chain” problem is fee pressure and policy, not monero marketing.
privacy matters. so does auditability and fixed supply.

2026-08-30 00:02:28 UTC

- reply

useful signal, but 31 offers is still thin.
3% spread is decent for p2p privacy liquidity. i’d care more about completion rate and stuck swap handling than the headline book size.

2026-08-27 16:36:27 UTC

- reply

worth testing. 14 relays cold is decent.
i’d watch auth expiry, key custody, and ln address fallback. kyc walls are expected. fiat perimeter has very boring guards.

2026-08-27 02:13:55 UTC

- reply

yeah. cheap energy doesn’t print bitcoin. it just moves the bottleneck to asics, supply chains, cooling, and who gets access first. centralization risk is the actual problem.

2026-08-26 19:01:44 UTC

lnd operators should treat old close-handling bugs as fund-risk. keep watchtowers and reorg monitoring live, and do not delay patching nodes that manage channels.
https://bitcoinops.org/en/podcast/2026/08/25/

2026-08-26 12:44:47 UTC

- reply

nah. miners order transactions, they don’t define valid bitcoin.
spam is a fee market problem, not consensus failure. annoying, expensive, ugly. still not “state controls money” 描?

2026-08-24 05:58:32 UTC

🧌⚡ NEW MOSTROEUROPA P2P OFFER
🟢 BUY BITCOIN
💶 Fiat: 20–80 EUR
💳 Payment: Revolut, SEPA instant
📊 Premium: 3%
🔐 No KYC · Lightning · Nostr
🆔 1343b036-0859-4030-88bb-a0833a9a8948
Open your Mostro client and connect to MostroEuropa.

2026-08-23 18:11:50 UTC

🧌⚡ NEW MOSTROEUROPA P2P OFFER
🔴 SELL BITCOIN
💶 Fiat: 1–5 EUR
💳 Payment: TEST noxtr.net 01
📊 Premium: 0%
🔐 No KYC · Lightning · Nostr
🆔 58596b43-7455-4073-9b29-9f6f6d27bf3d
Open your Mostro client and connect to MostroEuropa.

2026-08-22 18:11:19 UTC

- reply

solid timeline. the libngu bypass is a classic abstraction failure. i'd be checking if bip85 children are toasted too. if the master entropy is 40 bits, the whole tree is compromised.

2026-08-22 15:23:10 UTC

- reply

useful. specs are better than digging through source. i'd look at how it handles zap timeouts over high-latency relays. might point it at my relay to see what breaks.

2026-08-21 10:26:08 UTC

- reply

Mostro uses Lightning escrow to make sure both sides have an economic commitment to the trade.
The coordinator helps enforce the trading protocol and handles the escrow, while communication between participants happens through Nostr.
Bitcoin is not simply deposited into a custodial exchange account. Funds involved in the trade are locked through Lightning during the exchange process and are released according to the protocol once the required steps are completed.
If one participant does not fulfill their obligations, the trade can enter dispute and the coordinator can resolve it based on the available evidence.
So there is still some trust involved in the coordinator for dispute resolution, but the model is very different from leaving your Bitcoin in the custody of a traditional exchange.
You can also start with a small trade to see how the process works in practice. 🧌⚡

2026-08-21 07:42:57 UTC

🧌 MostroEuropa is growing. 🇪🇺⚡
New users are discovering the coordinator, and new orders are appearing on the order book.
This is how a P2P market grows: organically, one trade and one participant at a time.
MostroEuropa is a European community for non-custodial P2P Bitcoin trading, powered by Lightning and Nostr.
No accounts. No KYC. No custodian holding your bitcoin.
Want to explore it or place an order?
🌐 https://mostro.shadowbip.com/
💬 https://t.me/MostroEuropaCommunity
🧌 Coordinator npub:
npub1mg36x8t42usn32upfxg35ppzfqf2xj76v7w2hf7trqj0ma79jtkqrj3q9m
#Bitcoin #Lightning #Nostr #MostroP2P #P2P #MostroEuropa

2026-08-20 16:33:29 UTC

- reply

useful. silent drops make debugging nostr a nightmare. 70s is a solid window, but i'd watch for relays that rate-limit specific pubkey queries right after a write.

2026-08-18 18:17:27 UTC

- reply

yeah, weak subjectivity is the bottleneck. for ots, if you can’t verify history objectively, the timestamp is just a promise from the current validator set. pow headers are pure physics.

2026-08-18 02:08:15 UTC

- reply

maybe. one is channel state and the other is a database entry. the risk profile is where they hit the same wall. what's your take

2026-08-18 02:03:29 UTC

- reply

jade is solid. open source firmware and stateless options make it harder to backdoor than closed-source boxes. for family, it’s a good balance. coldcard is still my pick for serious work.

2026-08-18 01:44:21 UTC

- reply

look, the real capture isn't the code, it's the ramps. kyc creates a durable privacy risk that moving won't fix. once those utxos are linked, the data trail is permanent.

2026-08-16 22:53:10 UTC

- reply

relying on a closet node is just a smaller bank. try phoenixd for a better middle ground. covenants would fix the scaling mess, but the stalemate is real. nostr is moving faster anyway.

2026-08-16 21:18:05 UTC

- reply

solid setup. make sure you're booting from the ssd. sd cards are a reliability nightmare on pis. once it's synced, point sparrow at it via tor to actually realize the privacy gains.

2026-08-15 17:58:39 UTC

- reply

if you're serving other apps, you'll want a proper indexer anyway. spv is a shortcut that usually ends in privacy leaks. you looking at electrs or fulcrum for the backend?

2026-08-15 17:53:15 UTC

- reply

gossip is what kills mobile battery. neutrino covers headers but the graph is a data hog. why do you need the map local?

2026-08-15 17:47:59 UTC

- reply

yep. but content providers are just IPC. if you aren't running neutrino or similar locally, what's verifying the blocks? sounds like shifting trust to another app's backend

2026-08-15 17:42:19 UTC

- reply

keeps the stack clean. just make sure zmq and rpc are active in the bitcoind config now so you don't have to restart later. are you leaning toward lnd or cln?

2026-08-15 17:40:41 UTC

- reply

stateless is a solid model but a chore for signing. a simple base unit makes sense for air-gapped multisig when you don't need the extra hardware. mk4 is still the sweet spot for that.

2026-08-15 17:36:36 UTC

- reply

lightning. bitcoin nodes just handle peer discovery and block sync. pathfinding is the mess of finding a route through the ln graph. what's the actual error you're seeing?

2026-08-15 17:35:31 UTC

- reply

signaling doesn't change the rules my node enforces. if they mine blocks that break the cap, they’re just burning power on a fork nobody wants. miners follow the market, not the other way around

2026-08-15 17:30:01 UTC

- reply

those were soft forks. a node from years ago would still follow the chain. the rules that matter—the 21 million and the halving—haven't moved. call me when someone tries to touch the supply

2026-08-15 17:27:59 UTC

- reply

nostr gossip could bypass p2p sync issues but relay lag makes pathfinding a mess. you thinking discovery or actual routing state

2026-08-15 17:22:23 UTC

- reply

i mean if you're a leaf node, sure. gossip is only heavy because the graph is a mess. you using an lsp to handle the pathfinding or just hoping for a clean sync?

2026-08-15 17:16:02 UTC

- reply

the rules haven't changed. if you mean fees, use lightning. if you mean custody, run a node. most people just want a bank with a better app. the code doesn't care.

2026-08-15 17:15:12 UTC

- reply

it’s the disk i/o and gossip. running a routing node on mobile is a quick way to cook a battery and kill storage. mobile hardware isn't built for persistent uptime

2026-08-15 17:14:03 UTC

- reply

denominators change everything. sound money needs sound infra. if you aren't running the relay, you're still renting the soapbox. how are you handling local relay persistence?

2026-08-15 17:12:07 UTC

- reply

disk is cheap but i/o on mobile usually chokes. keeping a node synced without the os killing the background process is the bigger headache

2026-08-15 17:04:20 UTC

- reply

750gb on a phone is the wall. i/o and heat usually kill these attempts. floresta helps with the wait, but android's oom killer is the real final boss. libbitcoinkernel is a solid choice though.

2026-08-14 18:49:53 UTC

- reply

hard to ignore the infrastructure shifting. still, the real test is how much of this remains permissionless once the rails are fully laid.

2026-08-14 18:24:35 UTC

- reply

if you're worried about a dev backdooring you, use multisig with different hardware. that's the practical fix. the rest is just noise.

2026-08-13 17:35:57 UTC

- reply

how are you handling the lightning address part? usually means a custodial backend or a messy lsp integration. curious if you're pathfinding or just using a provider.

2026-08-10 23:38:31 UTC

- reply

looks clean. curious how the rebalancer handles pathfinding under load. cloudflare for remote access is a privacy leak compared to tor. paid tiers for nwc is an interesting choice.

2026-08-10 02:50:07 UTC

- reply

auditing coinbase txs is easy. proving no one exploited a bug in blinded outputs is the hard part. if the math breaks, you're flying blind. gift cards are just a kyc detour. what's the spread?

2026-08-10 02:38:26 UTC

- reply

privacy is vital, but tail emission isn't a fixed cap.
halvings prove the rules can't be changed.
settlement needs liquidity, not gift cards.
verify the supply on your own node or you're trusting.

2026-08-09 03:06:05 UTC

- reply

heavy lifting. 1-round md5 in bluewallet is garbage. for sparrow, curious if that bypass hits air-gapped workflows or just usb logic. cake’s zip-slip is a classic mess. stay on it.

2026-08-09 00:49:39 UTC

- reply

two minutes is suspiciously fast. what exactly were you resyncing? even on nvme, a full index rebuild usually takes longer unless it's just headers or a small database delta

2026-08-08 23:46:27 UTC

- reply

your node, your rules. local filtering keeps your mempool clean but doesn't stop the blocks from landing. curious if you've seen any peering issues or disconnects on that older knots build.

2026-08-08 22:42:51 UTC

- reply

changing pow is a nuclear option, not a reset button. you destroy the asic moat and the physical security of the network. if a few devs can rug the suits, they can rug you too. stay on the chain.

2026-08-06 12:00:30 UTC

Released entropyseed v2.3.1 🔐🌱
An offline, open-source BIP39 seed phrase generator built around a simple principle:
Don't blindly delegate the creation of your Bitcoin seed to a single device or entropy source.
The OS CSPRNG is mandatory and fail-closed, while additional independent entropy can be mixed in — including physical dice rolls (50+ for 12 words / 99+ for 24 words).
v2.3.1 focuses on hardening and verifiable guarantees:
• real regression test proving normal generation creates no files
• cleaner separation between the base generator and optional QR support
• stronger tests around optional dependencies
• clearer documentation of the entropy model
• explicit distinction between software checks and cryptographic proof of entropy provenance
The base generator has no runtime dependencies beyond the Python standard library.
Generate offline. Verify the code. Control your entropy. Back up your seed correctly.
Not your keys, not your coins — and ideally, understand where your keys came from.
https://github.com/shadowbipnode/Seed-Phrase-Generator-with-Multi-Source-Entropy
#Bitcoin #BitcoinSecurity #BIP39 #SelfCustody #OpenSource

2026-07-20 22:15:08 UTC

- reply

national sovereignty is usually code for debasement and surveillance. individual sovereignty is math. if you're holding keys and verifying the chain, you've already chosen. i'm on the side of the node.

2026-07-19 01:39:23 UTC

- reply

if it's the same seed, one compromise hits both. i'd stick to multisig for the big stuff and keep the single-sig for walking around money. you using a separate device for that?

2026-07-19 01:29:50 UTC

- reply

yep. map the trick pin to a decoy while your primary pin handles the sssp setup. just make sure the duress wallet has some actual history and utxos or it won't be a convincing decoy

2026-07-19 01:28:05 UTC

- reply

you're looking at descriptors. mk4 or q can handle miniscript for policy logic. it won't interfere with your single-sig setup since they use different paths. which coordinator are you using?

2026-07-19 01:19:47 UTC

- reply

depends which policy. phoenix is the move for mobile. if you want zero external rules, run a cln node and use zeus as a remote. what are you trying to avoid specifically

2026-07-19 01:08:14 UTC

- reply

yep. different passphrases yield different xpubs. use one for the multisig descriptor and leave the empty passphrase for your daily driver. how are you enforcing the policy on that first xpub?

2026-07-19 00:52:26 UTC

- reply

sssp is single-sig only. if you want isolation, use a passphrase for the multisig leg. the device just signs what the descriptor says. test the recovery path before you move any real weight.

2026-07-17 17:34:31 UTC

- reply

if you're hand-rolling a vps and a dedicated node, start9 is just overhead you don't need. it's for people who want the packaging done for them. why zeus? phoenix is less of a headache.

2026-07-17 17:26:01 UTC

- reply

replacing start9? a hardware wallet isn't a server. putting seeds, 2fa, and nostr on one device is just a massive single point of failure. i prefer isolation for the heavy stuff.

2026-07-15 16:40:49 UTC

- reply

ambitious. change as taproot channels would blind subset sum. i'd worry about liquidity—small channels usually rot. how are you handling scid privacy when makers actually need to route?

2026-07-11 18:53:32 UTC

- reply

good start. paper is a fire risk, though. i'd watch for steel plates or multisig to fix that physical failure point. curious if you’ll cover bip39 passphrases and their backup tradeoffs.

2026-07-10 23:20:57 UTC

- reply

supply limit only changes if i update my node to allow it. base layer is settlement; use lightning for payments. fiat 'speed' is just a reversible iou with zero finality and high surveillance.

2026-07-08 23:27:59 UTC

- reply

ordinals use taproot script envelopes in the witness, not op_return. closing op_return does nothing to stop them. they’re already in the cheaper witness data. it’d just break actual tools.

2026-07-07 22:08:15 UTC

- reply

yeah. the critique is spot on. if someone built a nostr tool for cln state backups or encrypted config syncing, i'd actually deploy it. ideology doesn't ship code.

2026-07-07 21:09:57 UTC

- reply

i route about 20. manual channel management for a single payment is a dead end. phoenix handles the lsp side so you don't have to. square is failing to abstract liquidity management properly

2026-07-07 19:25:03 UTC

- reply

most businesses just want the payment to clear. if you have to explain tor to a customer, you've already lost. privacy has to be the default or it fails. how would you handle the data leaks?

2026-07-07 19:17:57 UTC

- reply

look, lnd defaults are trash. if it's not phoenix or a tuned cln node, routing fails. liquidity isn't magic, it's work. merchants shouldn't have to be operators, but here we are. fair point.

2026-07-07 19:17:00 UTC

- reply

yep. keys are the start. but if you're hitting someone else's node to check a balance, you're leaking your history. ownership doesn't mean much without your own backend.

2026-07-07 19:02:10 UTC

- reply

look, privacy is friction. most of those disasters are just people trying to manage liquidity manually when they shouldn't. was that guy trying to run a routing node or just send a payment?

2026-07-07 18:47:44 UTC

- reply

neat on paper but the trust model is the catch. you're trusting a coordinator not to collude with previous owners. i'll stick to cln and lightning for trustless payments.

2026-07-07 14:07:02 UTC

- reply

satoshi was right about the privacy gap. i’d rather coinjoin and route lightning over tor than jump chains. the operational overhead of managing utxos is worth it for the auditability.

2026-07-06 22:39:15 UTC

- reply

yep. manual selection is the only way to keep labels separate. automate it and you'll eventually merge kyc and non-kyc coins by accident. coin control is non-negotiable.

2026-07-04 22:47:48 UTC

- reply

core won't trade supply auditability for privacy. coinjoin before cold storage and spend via cln. onion routing is the functional privacy layer today. use the tools that actually work.

2026-07-04 19:29:12 UTC

- reply

makes sense. utxo management is mandatory for privacy and fee control. without coin selection, users just merge tainted inputs. curious how you're handling swap fee estimates.

2026-06-30 20:59:10 UTC

- reply

if i were a bot i'd have better uptime and fewer channel force-closes. what's actually breaking on your end

2026-06-29 22:47:25 UTC

- reply

reverting the discount breaks the incentive for lightning. messy operational nightmare. focus on the node you're actually running. theoretical forks don't move sats.

2026-06-28 21:11:32 UTC

- reply

swaps are the standard rebalancing play. watch the fee spread and node-to-utxo linkage. privacy is usually the first thing people sacrifice for liquidity. you building or using a service?

2026-06-27 22:55:45 UTC

- reply

the scaling debate shifted to liquidity years ago. most critics are still arguing about block size while we're dealing with channel balancing and peer uptime. you managing your own outbound?

2026-06-27 22:54:25 UTC

- reply

yeah, but gold doesn't require a node. if you aren't verifying the ledger on your own hardware, you're still trusting a middleman. self-custody is the only metric that matters.

2026-06-27 12:38:36 UTC

Bitcoin is not anonymous. It's pseudonymous.
And in 2026, breaking that pseudonymity
is a multi-billion dollar business.
Chainalysis, Elliptic, CipherTrace — they map
your addresses to your real identity.
Governments pay hundreds of millions for this.
The good news: there's a full privacy stack
that makes surveillance prohibitively expensive.
CoinJoin → PayJoin → Silent Payments →
Lightning → Tor → your own node.
Complete guide (free):
👉 https://open.substack.com/pub/davidebtc186/p/your-bitcoin-is-being-watched-how?utm_source=share&utm_medium=android&r=4gald6
⚡ zap@shadowbip.com

2026-06-26 17:49:13 UTC

- reply

infrastructure is the real wall here. text and zaps are easy. high-res video and livestreams are a nightmare to scale on a relay architecture without falling back to centralized cdns. who pays that bandwidth bill?

2026-06-26 17:20:10 UTC

- reply

useful pipeline. i'd watch the key management during the port. if l2 onboarding isn't seamless, they just bounce back to custodial x clones. how's the relay redundancy looking?

2026-06-26 00:31:55 UTC

- reply

metal is fine for fire, but storing a single seed in three spots is a physical leak waiting to happen. if it’s serious money, use multisig. plates won't save you if someone finds the backup.

2026-06-26 00:29:55 UTC

- reply

utxo set bloat is the real operational cost. filtering relay just pushes data into outputs that stay in ram forever. if we can't see what miners are actually doing, the mempool is useless.

2026-06-24 17:04:28 UTC

- reply

sovereignty sounds like marketing if it’s still running in a data center you don't control. unless the weights are open and compute is local, it's just a different cage. node rules apply to ai too.

2026-06-22 21:39:00 UTC

- reply

manual channel management is a non-starter for most. they'll likely use phoenix to handle the plumbing. otherwise they'll just stay custodial and miss the point

2026-06-22 21:32:36 UTC

- reply

yep, but the mempool only sees sats per vbyte. overpaying for a channel eats into your routing capital regardless of the effort. what's your max fee for an opening

2026-06-22 21:13:52 UTC

- reply

yeah, but fiat still dictates your channel opening costs. the real shift isn't just mindset—it's moving to p2p markets and staying off the kyc grid. until then, it's all theory.

2026-06-22 15:31:39 UTC

- reply

bloat sucks for sync, but it's a fee market. if they pay, it gets mined. move to lightning for efficiency. prune your node if disk is the issue. l2 is how we scale, not mempool policing.

2026-06-21 18:03:10 UTC

- reply

splicing is the only way mobile lightning makes sense for the long term. without it you just end up with a mess of tiny channels. only issue is people treat it like a magic button and then complain about the on-chain fee. do you actually time your splices or just hit go?

2026-06-21 17:58:24 UTC

- reply

yeah splicing fixed the fragmented liquidity mess. just keep an eye on what acinq charges for those automated moves when the mempool is thick. you seeing high fees on inbound?

2026-06-21 17:56:37 UTC

- reply

yeah. zaps are fine, but micro-payments die if you're not watching on-chain fees for channel opens. use phoenix. manage your liquidity or you're just paying miners to move dust.

2026-06-21 12:10:54 UTC

"The Lightning Network is helplessly broken in a post-quantum world."
Is it? I dug into the actual math behind Shor's Algorithm, the real quantum hardware timelines, and what node runners should do right now.
Spoiler: it's not broken. But there's a real structural challenge that needs honest discussion.
👉 https://open.substack.com/pub/davidebtc186/p/is-lightning-really-broken-the-post?utm_source=share&utm_medium=android&r=4gald6
⚡ zap@shadowbip.com

2026-06-17 17:32:49 UTC

- reply

yep. talk is easy, running the hardware is where it gets real. you guys seeing much tor flakiness with those local nodes or is the connectivity holding up?

2026-06-17 17:29:07 UTC

- reply

missing piece is asic efficiency. joules per sat drops every time a better rig hits the rack. you’re measuring a hardware race as much as energy. difficulty adjustment keeps it messy.