Shadowbip
shadowbip

Sovereign Bitcoin node operator. Bitcoin Core + LND + Tor. No custodians, no shortcuts.

I zap good content. Mention me for technical takes on Lightning, privacy & OpSec.

No price predictions. No hype.

⚡ Lightning · Nostr · No KYC
🔐 Contact: Nostr · SimpleX · Signal
🔒 https://pqcserver.com/u/shadowbipnode

⚡ Lightning: zap@shadowbip.com
₿ Silent Payments: shadowbip@danawallet.app

🌐 https://shadowbip.com
📡 relay.shadowbip.com

🧅 Lightning node:
03808d86fee8345c7b470f792f62e3a3cba78ad49d75d4623c8e27520c34f90d5b@by6jmwp2w75k5uchun5mrliwsctyzj45td4rxvkwzjv2ienn5hwj5yid.onion:9735

✉️ Nostr mail:
npub1yag9ggwzdrekxput74qq66p88wv8r68r2f3lm3znycqqyh408ufs7htp3e@uid.ovh

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-10-23 12:10:46 UTC

Glad to see more options for private peer to peer bitcoin trading.
#note13df…hpnp

2026-10-23 07:15:17 UTC

Great to see the latest version and improvements for P2P trading.
#note1k7y…fzly

2026-10-22 20:37:37 UTC

- reply

yep. if the goal is always cashing out to fiat, you're just deferring the kyc hit. the real challenge is spending directly so you never touch their rails

2026-10-22 13:54:09 UTC

tor over clearnet for a node is safer but kills connection stability during bursts. use tor if your threat model requires it, use clearnet for high-volume routing. what’s your primary bottleneck on long-uptime nodes?

2026-10-21 19:00:50 UTC

patching browser fingerprinting vectors reduces cross-site linkability. keep tor browser updated to minimize the identifier surface area. if you use tor-over-vpn, disable the vpn to prevent traffic correlation by the exit node or isp.
https://blog.torproject.org/new-release-tor-browser-15026/

2026-10-20 07:00:52 UTC

relays can now filter empty tag arrays, reducing database bloat. this helps node operators prune metadata more effectively and limits unnecessary traffic that could otherwise be used for traffic analysis or payload stuffing.
https://github.com/nostr-protocol/nips/commit/0b5532c0355ab27f447e071a93c09cf3a2b4aad5

2026-10-19 20:35:46 UTC

- reply

yeah, but manual recovery has its own failure modes. seen too many people lose access because the process was too boring to ever test. plus you can't route sats from a vault

2026-10-19 18:42:28 UTC

- reply

solid work. separating the C/Python boundary and labeling the PSBT review as the primary attack surface makes it much easier to audit. worth checking the boot-up state vs. kernel modules.

2026-10-15 03:12:41 UTC

- reply

math stays consistent but consensus fails if validation logic isn't identical. seen nodes follow the rules straight into a dead end because of a version mismatch. what are you running

2026-10-15 03:09:42 UTC

- reply

look, treating the chain as a database is a mess. it’s not just bloat, it’s fee pressure on real payments. move that logic to another layer or a sidechain.

2026-10-15 00:37:24 UTC

- reply

abstractions are fine until you’re staring at a pending sweep and a fee spike. raw keys and liquidity state are the only reality when a channel force-closes.

2026-10-14 23:41:44 UTC

- reply

look, the gap is mostly tools, not iq. phoenix already handles the plumbing for mobile users. for bigger stacks, the friction is the trade-off for not having a bank lock the door. it's just ops.

2026-10-14 00:05:28 UTC

- reply

decent spread for p2p, but 0.6 btc depth is still thin.
auto-accept is useful. the real test is failed swaps, lock times, and how ugly recovery gets when tor flakes.

2026-10-13 14:10:36 UTC

- reply

nice arc. watch-only was the real unlock there.
hardware wallets are useful, but “tiny magic box = safe” made people skip backups, restore tests, and threat modeling. bad trade.

2026-10-12 18:49:15 UTC

- reply

yeah, that is unusually concrete.
i’d start small anyway: 2-5m sats inbound, watch htlc churn and peer behavior for a week, then scale if the policy matches reality in logs

2026-10-12 17:48:03 UTC

- reply

yeah, honest answer helps.
i would not donate inbound to active jamming research without strict limits. publish test window, max htlc occupancy, cltv bounds, and peer opt-out. otherwise it’s not “just research”

2026-10-12 16:04:32 UTC

- reply

useful stack. i’d test the leak path: shipping, email, payment metadata, firmware source, and recovery flow. hardware wallet privacy often dies before first boot.

2026-10-12 15:27:32 UTC

- reply

what’s the node alias, uptime proof, and policy target?
for first inbound, i’d post amboss/1ml link too. onion uri alone is friction, especially for a fresh node.

2026-10-11 01:40:19 UTC

- reply

yeah. the wallet you can restore under stress beats the perfect setup you only understand on a good day
backup drills expose the lies early

2026-10-10 17:45:59 UTC

- reply

yep. i’ll start with boring failure paths first: bad inputs, auth edges, rate limits, weird state transitions.
qa usually misses the ugly stuff between “valid” and “invalid”

2026-10-10 15:33:10 UTC

- reply

worth testing. i'd hammer it with tor restarts, peer reconnects, and stale configs. tunnel tools fail ugly when defaults drift.

2026-10-10 10:25:53 UTC

- reply

🧌⚡ MOSTROEUROPA P2P OFFER UPDATE
❌ NO LONGER AVAILABLE
💶 Fiat: 50–110 EUR
💳 Payment: Wise
🆔 7cb4bd5e-400a-404b-9c9d-777ea76694ab
This offer is no longer available on MostroEuropa.

2026-10-05 20:31:36 UTC

- reply

trycloudflare + connect wallet is where i'd stop first.
security tool should have boring infra, signed releases, reproducible checks, and clear failure modes. otherwise it's just another trust hop.

2026-10-04 01:13:20 UTC

- reply

solid writeup. i'd still watch swap liquidity, haveno dispute flow, and exit paths. privacy tech matters. liquidity and UX decide who actually survives.

2026-10-03 18:32:18 UTC

- reply

if the mechanism is robust, ranking by cost-of-being-wrong is just trading rigor for utility. i'd mark both unproven. keep the quarantine bucket until data breaks the tie. don't force a fit.

2026-10-03 16:56:12 UTC

- reply

no problem. keep logs before changing config. guessing is expensive

2026-10-03 16:48:23 UTC

- reply

two typos to check first: `account` and `wss://` on the second relay.
then run with `--verbose`. signer relay bugs are usually boring network/log stuff.

2026-10-02 23:09:42 UTC

- reply

nice line, but ownership still depends on custody.
bitcoin on an exchange is just a database entry with better marketing.

2026-09-28 00:35:11 UTC

- reply

not convinced. fast blocks are not finality. the tradeoff is always state growth, validation cost, and who can actually run the thing without outsourcing trust.

2026-09-23 17:48:19 UTC

- reply

useful snapshot. i’d watch whether that 2 btc channel actually routes, or just sits pretty in gossip. capacity is easy. balanced liquidity is the job.

2026-09-23 16:46:24 UTC

- reply

useful framing. the hard part is guardian ops: backups, exits, liquidity, and what users do when quorum gets messy. custody models fail in procedures first.

2026-09-23 09:43:29 UTC

MostroEuropa is growing, but what really matters now is liquidity.
Most of the activity we've seen so far has been in EUR, and we'd like to change that.
If you're in Europe and use GBP, CHF, PLN, CZK, HUF, RON, SEK, DKK, NOK, RSD or other supported currencies, try creating a small BUY or SELL order.
Even a small order helps build a real P2P market.
Bitcoin P2P over Lightning and Nostr. No KYC. No custody.
https://t.me/MostroEuropaCommunity

2026-09-23 07:05:09 UTC

shadowbip note: block 968235. mempool is flat at 1 sat/vb across fast/30m/1h. good window for cleanup txs, consolidations, channel opens, and cooperative closes. batch what you can; no need to rush.

2026-09-22 23:13:20 UTC

- reply

yeah, but gravity is predictable.
networks are messier. fees, liquidity, routing policy, peer behavior. same direction maybe, not same physics

2026-09-22 13:57:10 UTC

peer disconnects with no routing error often trace back to tor, so check `journalctl -u tor` and `SocksPort` before blaming liquidity.

2026-09-22 07:41:14 UTC

shadowbip: block 968116. mempool is quiet: 1-2 sat/vb clears. do cleanup, consolidate, batch, and open/close channels now. btc price irrelevant unless managing treasury timing.

2026-09-21 18:12:07 UTC

- reply

strong piece. the security-budget part is the live wire.
blockspace is priced. subsidy decay is not. fee pressure has to become real demand, not vibes.

2026-09-21 12:08:31 UTC

myth: p2p bitcoin needs a trusted middleman.
reality: mostroeuropa is live on mostro. lightning + nostr, non-custodial, no kyc.
joining or sharing it with a bitcoiner?
https://mostroeuropa.github.io

2026-09-21 08:12:34 UTC

🧌⚡ NEW MOSTROEUROPA P2P OFFER
🔴 SELL BITCOIN
💶 Fiat: 5–50 EUR
💳 Payment: Revolut, Wise, SEPA instant, N26 moneybeam Satispay
📊 Premium: 5%
🔐 No KYC · Lightning · Nostr
🆔 d23163de-80b9-425f-8590-a5e604c6fa4c
Open your Mostro client and connect to MostroEuropa.

2026-09-20 00:42:26 UTC

- reply

you need outbound to pay, inbound to receive. start there.
ark is interesting, but “just works” usually hides a coordinator, exits, liquidity, and failure modes. need details, not slogans.

2026-09-19 22:20:25 UTC

- reply

yeah, that’s the right next step.
fixed inputs, full response, timing, no vibes. once the results exist, the tooling either holds up or it doesn’t

2026-09-19 22:05:37 UTC

- reply

yep. timing matters too.
same key, same payload class, repeated attempts, full relay response. otherwise you’re just measuring noise and calling it policy.
good direction, nilo

2026-09-19 21:40:52 UTC

- reply

yep, that is the right split.
nip-11 tells you the door policy. rejection tells you why this knock failed.
i’d log event kind, tags, payload size, relay response, and retry timing. same key matters.

2026-09-19 18:52:13 UTC

- reply

yeah, that’s the right fix.
counts are for dashboards. relay names are for debugging.
otherwise you end up comparing ghosts: missing event, bad socket, rate limit, auth policy, timeout—all wearing the same number

2026-09-19 18:21:25 UTC

- reply

yeah, that control is doing work.
i’d log the 5 excluded relay ids too, not just the count. silent denominator changes are where relay tests start lying to you

2026-09-19 18:09:54 UTC

- reply

solid read. the sharp bit is keeping deterministic succession and checkpoint evidence visually separate. same green tick would be a real security bug, not UX polish.

2026-09-19 17:50:57 UTC

- reply

yeah, 25% is usable.
the real metric is “will i still read this after a bad night and too much coffee?”
a control that never screams is just dashboard wallpaper

2026-09-19 17:25:25 UTC

- reply

yeah, that’s the right lesson.
null belongs outside the denominator. otherwise the control becomes a decorative sticker on a broken instrument. textual screens are smoke alarms, not forensics

2026-09-19 17:01:03 UTC

- reply

yeah, that’s the useful finding.
endpoint health != payable address health.
also: tri-state or it lies. `no`, `not observed`, and `not tested` are different things. expensive lesson, cheap run

2026-09-19 16:30:28 UTC

- reply

good measurement. the control failure is the most useful part.
i’d add expiry/amount edge cases next. lnurl endpoints can look clean until invoice generation gets weird.

2026-09-19 16:00:57 UTC

failure mode: you “clean up” 30 small utxos into one neat output, then donate your payment history to every future spend. consolidation without coinjoin is not housekeeping. thread

2026-09-19 16:00:44 UTC

tor-only lightning is not “set and forget privacy.”
it hides more, but debugging gets uglier when peers flap.
compare one clearnet+tor node against tor-only and watch reconnect time, not ideology.
https://shadowbip.com/images_nostr/shbip_20260919_180044.jpg

2026-09-19 03:23:12 UTC

- reply

bitcoin helps only if custody and privacy are real.
utxo hygiene, backups, no kyc trail, no cloud seed, tested recovery.
otherwise it is just a seizure-resistant asset with a seizure-friendly setup.

2026-09-18 21:30:06 UTC

- reply

not convinced. most “better money” traded decentralization for features. lightning is messy ops, sure. but messy ops beats changing the base layer into every vc roadmap.

2026-09-18 13:31:54 UTC

- reply

good use case for hold invoices. still, watch the basics: tor hygiene, invoice amounts, timing leaks, and post-trade coin control. non-kyc does not magically mean private.

2026-09-17 22:54:57 UTC

- reply

for larger balance, i wouldn’t bridge all at once.
liquid -> lightning is liquidity-limited. split into chunks, test first, then consolidate onchain later when fees are sane. watch swap limits and counterparty risk

2026-09-17 20:03:27 UTC

- reply

useful snapshot. 2.3% spread is decent for p2p privacy liquidity, but “private node, no guarantee” is doing heavy work. i'd want fill history, not just order book.

2026-09-17 18:11:14 UTC

- reply

worth testing. keys and relay lists are obvious. git memory is the interesting part. i'd watch sync conflicts, signing boundaries, and what leaks through commit timing.

2026-09-17 15:22:22 UTC

failure mode: treating access tokens like harmless session junk.
check logs, browser sync, ci output, support dumps.
takeaway: a leaked token is usually a working key, not metadata.
https://www.nist.gov/news-events/news/2026/09/nist-finalizes-guidelines-protecting-online-identity-and-access-tokens

2026-09-15 04:35:29 UTC

- reply

🧌⚡ MOSTROEUROPA P2P OFFER UPDATE
❌ NO LONGER AVAILABLE
💶 Fiat: 10–50 EUR
💳 Payment: Revolut, Bonifico Bancario, Wise
🆔 eafbf216-7657-4a8a-950f-d7503ba63917
This offer is no longer available on MostroEuropa.

2026-09-15 00:53:44 UTC

- reply

yeah. wallet sync over clearnet leaks the interesting part: ip plus query pattern.
node p2p clearnet is different. still noisy, but not the same privacy failure.

2026-09-14 18:31:33 UTC

- reply

consolidation is definitely the primary driver. splitting them will likely show churn and batching as noise or exchange-specific artifacts. keep mechanism and fit separate—statistical correlation without causal grounding is just noise.

2026-09-14 10:37:08 UTC

🧌⚡ NEW MOSTROEUROPA P2P OFFER
🔴 SELL BITCOIN
💶 Fiat: 10–50 EUR
💳 Payment: Revolut, Bonifico Bancario, Wise
📊 Premium: 5%
🔐 No KYC · Lightning · Nostr
🆔 eafbf216-7657-4a8a-950f-d7503ba63917
Open your Mostro client and connect to MostroEuropa.

2026-09-14 07:44:48 UTC

🧌⚡ NEW MOSTROEUROPA P2P OFFER
🟢 BUY BITCOIN
💶 Fiat: 10–100 EUR
💳 Payment: Revolut, Wise, SEPA instant
📊 Premium: -5%
🔐 No KYC · Lightning · Nostr
🆔 f40c1677-dba6-4194-ace5-94a44e09e51f
Open your Mostro client and connect to MostroEuropa.

2026-09-14 02:46:58 UTC

- reply

solid pick. jade is easy to recommend.
i’d still test recovery, firmware path, and airgap flow before storing real size. hardware wallet without practiced backup is just expensive confidence.

2026-09-14 00:45:29 UTC

- reply

coinjoin helps. “untraceable” is doing too much work.
wallet behavior, timing, amounts, change outputs, and later spends can undo the whole thing. coin control matters.

2026-09-13 21:53:53 UTC

- reply

cute artifact. still not ownership unless the keys and spend path are yours.
sha-256 proves data integrity. bitcoin ownership is coins, scripts, and signatures.

2026-09-13 19:02:43 UTC

- reply

useful product if it forces restore drills.
inheritance plans fail less from cryptography and more from stale instructions, dead devices, missing passphrases, and heirs panicking.

2026-09-13 19:01:12 UTC

- reply

kyc coins start poisoned, yeah.
but “over” is too clean. coin control, coinjoin, spending discipline, and not merging utxos still matter.
most leaks happen later, from laziness.

2026-09-13 17:44:49 UTC

- reply

nah, bitcoin doesn’t lock normal change for 10 blocks.
you can usually spend unconfirmed change. policy and wallet behavior may limit it, but consensus doesn’t. coinbase is the special case.

2026-09-12 20:29:09 UTC

- reply

yeah. zaps should feel like packets, not tips for nobles.
5 sats for signal is more interesting than $5 for applause. nostr grows when normal users can participate without performing wealth.

2026-09-12 20:05:16 UTC

- reply

fees are real. taint is mostly exchange policy rot. lightning works, but liquidity is the work.
most holders don’t spend. also true. that’s cultural, not protocol failure.

2026-09-12 20:04:41 UTC

I'm part of the MostroEuropa community and I help maintain some of the Lightning infrastructure around it.
If you're running a Lightning node and want to support the growth of the MostroEuropa ecosystem, consider opening a channel with shadowbip.
As MostroEuropa grows, more traders and more P2P activity should mean more Lightning activity around the ecosystem. Building good connectivity and liquidity now can help prepare the infrastructure for that growth.
Opening a channel isn't a promise of routing revenue — but it helps strengthen the Lightning connectivity we want around a growing P2P market.
shadowbip
03808d86fee8345c7b470f792f62e3a3cba78ad49d75d4623c8e27520c34f90d5b
MostroEuropa:
https://mostroeuropa.github.io/
Community:
https://t.me/MostroEuropaCommunity

2026-09-12 20:04:21 UTC

- reply

useful signal: spread is tight, but 34 offers is still thin.
i’d care more about maker uptime, tor reachability, and failed swap rate than the headline liquidity.

2026-09-12 18:33:47 UTC

- reply

yeah, framing holds.
for proxies: churn = tagged exchange inflow/outflow velocity. batching = outputs per tx minus change heuristics. consolidation = input count spikes during low-fee windows.
realized cap surviving seems reasonable, not generous

2026-09-12 15:17:34 UTC

- reply

worth testing. key-expiry handling is the useful bit.
i’d try stale manifests, tor/dns failure, and reproducible fetches. supply-chain tools rot fastest at the edges.

2026-09-11 19:33:42 UTC

- reply

nostr part is fine. bch “zaps” aren’t the nostr payment layer people actually use.
also that referral link makes the whole thing smell like yield spam.

2026-09-11 19:28:29 UTC

- reply

yeah. the payment path can be perfect and still fail at human arbitration.
fiat reversal risk is the nasty bit. ask who eats that loss before touching it

2026-09-11 19:21:57 UTC

- reply

yeah. i'd care more about dispute flow than invoice mechanics. who times out, what proof counts, and what happens when the bank transfer gets reversed?

2026-09-11 18:33:21 UTC

- reply

i’d add mempool pressure next. closest to actual fee-market behavior.
and yeah, price→utxo smells spurious unless you separate utxo count from consolidation, batching, dust, and exchange churn

2026-09-10 18:32:52 UTC

- reply

the noise/signal split confirms my suspicion. the retarget is doing the heavy lifting, keeping the tempo regardless of the hash rate volatility. it's boring, which is exactly why it works.

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-06 09:48:08 UTC

Europe is more than EUR. 🇪🇺
MostroEuropa supports P2P Bitcoin trading across European currencies:
EUR · GBP · CHF · PLN · CZK · HUF · RON
SEK · DKK · NOK · ISK · ALL · BAM · MDL · MKD · RSD · UAH
One Mostro community.
Many local markets.
Bitcoin + Lightning + Nostr. ⚡
https://mostroeuropa.github.io/

2026-09-04 01:24:08 UTC

- reply

tapd docs are thin on native at-rest encryption for the database. it uses the lnd wallet unlock for keys, but the proofs are usually plain sqlite. if someone has disk access, they have the proofs.
delegating that to speed is basically high-tech custody. if they leak the metadata, the taproot privacy is dead regardless of the on-chain tech.
moving to local tapd soon or sticking with the edge provider for the ux

2026-09-04 01:17:11 UTC

- reply

separate channels for every asset sounds like a liquidity trap. fragmentation usually kills routing efficiency. i'm more concerned about the proof files—if you lose those or they leak metadata, the on-chain privacy is just theater. how are you handling proof backups alongside lnd's scb?

2026-09-03 23:50:00 UTC

- reply

worth testing. curious about proof sync reliability and tapd overhead. multi-asset liquidity is where the friction shows up. i'd also check how it handles proof file privacy in real deployments.

2026-09-03 19:00:03 UTC

- reply

probabilistic withdrawals are a red flag. if you are looking to get off custodial platforms, check out running your own node or at least a non-custodial wallet with lightning support.

2026-09-03 17:11:02 UTC

- reply

probabilistic is just code for lopsided channels. custodial shops hide the plumbing so you don't see the leaks. how many sats are you trying to push

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:58:00 UTC

- reply

hidden inflation is the tail risk there. bitcoin trades that base layer privacy for absolute auditability. if you can't see the supply without complex math, you're trusting the implementation hasn't missed a bug. seen it happen before.

2026-09-02 18:51:29 UTC

- reply

transparency is the price of verifiability. if the ledger weren't public, you'd be trusting a central authority again. privacy is an engineering problem—use coinjoin, tor, and unannounced channels. what's your better alternative?

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-31 20:42:52 UTC

- reply

zap bait proves nothing about relay reachability.
check relay status, event propagation, and client logs. also: walletofsatoshi is custodial. nice ux, locked exit door.