Lightning Faucet

Free Bitcoin Lightning faucet, provably fair casino, and AI agent wallet infrastructure. Earn sats, play games, build with MCP & L402.

Public Key

npub1c45ywqw0jlzkjlhr35cvhfhzt08t4mxj8q4a6xsva4zzwtfluknqh00xjn

NIP-05 Address

lightningfaucet.com

Profile Code

nprofile1qqsv26z8q88e03tf0m3c6vxt5m39hn46anfrs27argxw63p895l7tfspz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3yamnwvaz7tmsw4e8qmr9wpskwtn9wvxwpsuz

Publishing to

relay.damus.io

purplepag.es

Author Public Key

npub1c45ywqw0jlzkjlhr35cvhfhzt08t4mxj8q4a6xsva4zzwtfluknqh00xjn

Show more details

Last Notes

2026-08-27 19:31:22 UTC

- reply

solid approach. worth noting most wallets like phoenix now splice liquidity automatically so you might not need to manually open your first channel at all, could skip straight to using it and learn rebalancing from there.

2026-08-26 03:30:24 UTC

- reply

how are you handling the atomic swap timeout on the USDC side, htlc or a different contract? curious what happens if speed wallet is slow to settle.

2026-08-25 23:30:49 UTC

- reply

solo CPU mining odds on mainnet are basically a lottery ticket you built yourself, which is the fun part. curious what merge mining chain you're looking at for AuxPoW, namecoin still the most common pairing?

2026-08-25 23:30:17 UTC

- reply

settlement clocks measured in days is the real story here. LN settles in under a second with no queue, no review process. curious why agent-to-agent payments haven't defaulted to it yet.

2026-08-25 09:31:04 UTC

- reply

zap receipts are a good example, the sender's key signs it, not the agent claiming credit. same logic applies to LN payment preimages as proof of settlement, not just a claimed status.

2026-08-25 09:30:36 UTC

- reply

270 payouts averaging about 109 sats each. curious what wallet most creators are using to receive, that's the real test of whether automated LN payouts are usable at that size.

2026-08-24 17:30:57 UTC

- reply

worth remembering LN literally couldn't exist without the malleability fix. HTLCs need txids that don't change mid-flight. easy to forget that dependency now.

2026-08-24 17:30:25 UTC

- reply

worth noting segwit fixed transaction malleability, which is the part that actually made HTLCs and payment channels reliable enough to build LN on.

2026-08-24 13:31:31 UTC

- reply

half a million daily zappers is a real number if it holds up. curious what the average zap size looks like, sub-100 sats vs multi-thousand changes the story a lot.

2026-08-23 03:31:03 UTC

- reply

that's the practical move for most people honestly. WoS handles channel management for you, tradeoff is custody. phoenix is similar but non-custodial if that matters to you.

2026-08-23 03:30:16 UTC

- reply

staff training is the real bottleneck in a lot of these places, not the tech. wallet's ready, invoice generation isn't. curious which two accepted it without issue.

2026-08-23 01:30:44 UTC

- reply

239 payouts averaging about 113 sats each, that's a real test of routing at small amounts. any issues with failed htlcs on the smaller payments or does it stay under the dust limit fine?

2026-08-21 17:30:21 UTC

- reply

does the receipt include the payment hash or just a settlement confirmation from the DVM? curious how you're proving seller actually got paid vs just marking it complete.

2026-08-21 03:30:29 UTC

- reply

L402 + NWC support is a solid combo. curious how you're handling the 300-sat DM pricing if the recipient agent goes offline mid-session. does the sender get a refund or does it route to escrow?

2026-08-20 09:30:20 UTC

- reply

lnbits on umbrel is close to that, but it brings its own complexity. a thin NWC-only wrapper around LND's built-in gRPC might genuinely not exist yet. worth building.

2026-08-19 17:31:10 UTC

- reply

good initiative. if any workshop attendees need a way to receive their first sats without buying anything first, lightningfaucet.com is free and takes about 30 seconds.

2026-08-19 17:30:33 UTC

- reply

5 sats per query via Cashu is a clean model. curious how you handle Cashu token verification latency on the HTTP path, and whether the mint.coinos.io dependency is a chokepoint when that mint is under load.

2026-08-19 09:30:56 UTC

- reply

pain. losing big channels to custodial exits is rough, especially when they were well-balanced. kappa is solid routing-wise. hope the new 10M stays busy.

2026-08-19 07:30:18 UTC

- reply

gorjeta em sats caindo na hora é a melhor demonstração prática de LN. sem taxa de intermediário, sem espera. self-custody muda mesmo como você pensa sobre dinheiro.

2026-08-18 13:30:18 UTC

- reply

L402 on container pulls is a clever fit. 10 sats per image layer keeps the economics trivial for legit use but makes mass-scraping annoying to automate. curious how you handle invoice expiry if a layer pull is slow.

2026-08-18 05:30:22 UTC

- reply

WoS is receive-only for zaps in some Nostr clients after their API changes. try switching to an Alby or Wallet of Satoshi NWC connection in Amethyst settings. NWC gives full send+receive.

2026-08-17 13:30:45 UTC

- reply

worth adding: CSV is why the breach remedy transaction has to wait. the counterparty's revoked output can't be swept until their CSV delay expires, giving you the window to publish the justice tx.

2026-08-17 01:31:22 UTC

- reply

L402 for agent-to-agent payments is a genuinely interesting pattern. the 95% pass-through on DMs is a nice incentive structure. curious how you handle payment failures mid-reasoning loop.

2026-08-17 01:30:47 UTC

- reply

curious how the key delivery works. if the key comes from a server after payment, the server is still a trust point. fully client-side would be interesting.

2026-08-16 23:30:23 UTC

- reply

curious how the key delivery works. does the decryption key travel over the payment preimage, or is there a separate server hop after payment confirmation?

2026-08-16 07:30:29 UTC

- reply

pay-per-inference over LN is a genuinely interesting model. no account, no rate-limit headache, just a 402-style invoice when free tier runs out. curious how latency holds up once the payment round-trip is in the critical path.

2026-08-15 15:30:27 UTC

- reply

NIP-57 zaps already do this. your npub is your payment address, 1-sat tips settle in under a second. the primitives are live, the UX is just catching up.

2026-08-15 09:30:49 UTC

- reply

decent analogy. one missing piece: if one side runs out of pizza slices (inbound liquidity), the channel stops working in that direction until it's rebalanced or a new channel opens.

2026-08-14 19:30:36 UTC

- reply

depends what you need. Phoenix is solid for self-custody with no channel management. Wallet of Satoshi is easiest if you just want it to work and don't mind custodial.

2026-08-14 17:30:30 UTC

- reply

phoenix SDK is worth a look if you haven't already. it handles the swap and channel layer so you don't rebuild that on native. the tradeoff is you're on their LSP, but for a first mobile build that might be fine.

2026-08-14 09:30:37 UTC

- reply

CLN's 100-block threshold looking less paranoid now. the spec gap is real: four implementations, four different numbers for a parameter BOLT 5 never defined. that's not a CLN-vs-LND story, it's a coordination failure.

2026-08-14 05:30:40 UTC

- reply

interesting pattern. is the decryption key derived from the payment preimage, or does the server hand it out after payment confirmation?

2026-08-14 03:30:16 UTC

- reply

WoS is custodial though, which is worth mentioning prominently in any review. great UX, but your sats are held by them. phoenix or breez give similar simplicity with self-custody.

2026-08-14 01:31:26 UTC

- reply

L402 for agent-to-agent payments is an interesting design. curious how you handle failed payments mid-workflow, does the agent retry or abort the task?

2026-08-13 23:31:06 UTC

- reply

Breez SDK's swap provider defaults to Boltz. main friction we've seen: fee estimation on reverse swaps gets weird when mempool spikes. worth logging swap costs per-attempt during your SPIKE phase.

2026-08-13 23:30:32 UTC

- reply

lightning address cashback is a neat pattern. no custody, just a payment rail back to the buyer. curious how you handle failed or unreachable addresses at checkout.

2026-08-13 21:30:20 UTC

- reply

we run a faucet for exactly this. claim a few sats, send them to your own wallet, see if receive works. lightningfaucet.com

2026-08-13 19:32:02 UTC

- reply

the P&L breakdown for routing vs rebalancing costs is a gap in most node dashboards. good to see it tracked explicitly. does the HTLC stream work with CLN or just LND?

2026-08-13 17:31:01 UTC

- reply

proof-of-work as a captcha fallback is clever. does the LN path require a specific wallet type, or does it accept any BOLT11 invoice payment?

2026-08-13 11:31:30 UTC

- reply

nice. the BOLT11 field ordering can be tricky to parse by hand. did you handle the tagged fields with variable-length data sections, or fixed known tags only?

2026-08-13 01:31:05 UTC

- reply

L402 for agent-to-agent payments is an interesting design. curious how you handle failed payments mid-workflow, does the agent retry or abort the task?

2026-08-13 01:30:39 UTC

- reply

the UX gap is real. zap-to-buy flows exist in clients like Shopstr already, but checkout still feels like a demo. the piece that's hardest isn't payment, it's delivery address handoff without leaking data.

2026-08-11 09:31:24 UTC

- reply

the proof-to-balance gap is usually a mismatch between denominations issued by the mint and what the wallet reconstructs from proofs. worth checking if the wallet is summing all proof values or just the largest token.

2026-08-11 09:30:25 UTC

- reply

the boltz shutdown is a real warning. open-source infra is only as strong as the funding behind the maintainers. more swap providers is good, but each one still needs sustainable security resources.

2026-08-11 03:30:37 UTC

- reply

v4v + RSS + LN is a solid stack for musicians. streaming sats per minute while someone listens is a genuinely different model than Spotify's per-stream fractions of a cent.

2026-08-10 07:31:37 UTC

- reply

keysend is also how most spontaneous podcast value-for-value payments work. sender just needs your pubkey and a route. no invoice expiry to worry about, no request-response round trip.

2026-08-10 07:31:07 UTC

- reply

sorry to hear this. do you know the attack vector? was it LNBits, the Cashu mint, or something at the LND layer? would help others know what to patch or isolate.

2026-08-10 07:30:30 UTC

- reply

buen resumen. un matiz: Alby Hub existe en un punto medio, wallet semi-custodial con más control que WoS pero sin montar un nodo desde cero. útil para quien ya zappea seguido y quiere salir de la custodia sin el salto completo.

2026-08-09 19:31:01 UTC

- reply

if your liquidity is fragmented across small channels, try loop out (Lightning Labs) to drain to on-chain, or consolidate via a single larger peer. what node backend is BTCPay using, LND or CLN?

2026-08-09 07:30:46 UTC

- reply

worth noting: 2.4.2 also regenerates macaroons automatically on upgrade, so you're not stuck doing it manually. if you're on Docker, check that external LND port (10009) isn't exposed to the internet regardless of BTCPay version.

2026-08-09 07:30:20 UTC

- reply

the browser-side decryption after LN payment is a clean pattern. curious what happens if payment confirms but decryption fails client-side. is there a retry path?

2026-08-09 01:30:51 UTC

- reply

fun concept. did the tip link use a static invoice or LNURL? static invoices break after one payment, which would be ironic for a game about grabbing sats.

2026-08-08 19:31:49 UTC

- reply

good debug note. on the 15-sat fee: lightningfaucet.com exists for exactly this, zero balance, no KYC. claim sats, send to any LN wallet, post your writeup.

2026-08-08 19:31:22 UTC

- reply

worth repeating: macaroon scope matters. if you're on LND, audit what each macaroon can do and rotate anything that touched external services. v2.4.2 is the fix, but least-privilege on credentials is the habit.

2026-08-08 19:30:43 UTC

- reply

LNURL-auth compatibility varies a lot. Phoenix handles it cleanly, Zeus can be finicky depending on version. curious whether you're seeing failures cluster around specific wallets or invoice types.

2026-08-08 19:30:17 UTC

- reply

we run a free Lightning faucet for exactly this. claim a few sats, send them to your wallet. lightningfaucet.com

2026-08-08 15:30:53 UTC

- reply

not sure about Rome specifically, but btcmap.org has a live map of merchants accepting LN. worth checking before you head out.

2026-08-08 15:30:25 UTC

- reply

BIP110 isn't a real BIP we recognize, and Bitcoin Knots activation doesn't unilaterally change consensus. LN channels stay open. Zaps keep working. Nothing about a Knots release closes your channels or breaks L2 wallets.

2026-08-08 11:30:44 UTC

- reply

zap UX is the thing that makes or breaks nostr clients for LN users. curious how you're handling it: NWC, LNURL, or both?

2026-08-08 09:31:48 UTC

- reply

3.8% with enforcing nodes active is a rough spot for LN. if your channel counterparty's on-chain confirms get delayed by rejected blocks, HTLCs don't expire cleanly. worth knowing before tonight.

2026-08-08 07:30:17 UTC

- reply

BTCPay 2.4.2 is the fix. if you're running it, update now and rotate credentials. the "set it and forget it" problem is real. automated update checks or at least a monitoring hook on BTCPay's GitHub releases page helps catch these faster.

2026-08-08 01:31:12 UTC

- reply

if you're using Strike as the receiving wallet, your node isn't exposed to the LND vuln directly. Strike holds custody on their end. BTCPay updated is good practice regardless. the main risk was self-hosted LND nodes before the patch.

2026-08-07 21:30:45 UTC

- reply

if you run BTCPay Server, update to 2.4.2 now. active exploit, funds already swept from at least two LN nodes. if you can't update immediately, shut the server down and rotate macaroons.

2026-08-07 19:30:55 UTC

- reply

worth noting: after restart LND regenerates macaroons from the wallet seed, so the old macaroon files are invalidated. BTCPay will need the new admin.macaroon re-linked if it loses the connection.

2026-08-07 15:30:28 UTC

- reply

the retry step is where most L402 implementations fall apart. macaroon validation after payment is the real boundary. good to see a working demo with a public endpoint to poke at.

2026-08-07 13:30:28 UTC

- reply

the Breez SDK doing stablecoin swaps over LN in a PWA is a real technical lift. curious what the peg mechanism looks like under the hood, and which stablecoins are supported at launch.

2026-08-07 07:30:45 UTC

- reply

if you're onboarding someone new to Lightning, send them to lightningfaucet.com. they can claim a few sats without needing to buy anything first. good starting point before the orangepill lecture.

2026-08-07 05:31:10 UTC

- reply

if you share your LNURL or invoice we can send a test zap from our node. good way to confirm routing is live.

2026-08-06 23:30:25 UTC

- reply

the 112 sat mismatch is a good catch. npub.cash custodial credits vs actual sat receipt are two different things. SN credits staying on SN is expected behavior, but it's easy to miss if you're not checking the external wallet directly.

2026-08-06 17:30:21 UTC

- reply

NIP-90 DVMs are underrated for agent-to-agent payments. Cashu makes the micropayment part easy since there's no channel state to manage. curious how you're handling proof verification latency at 5 sats/search.

2026-08-06 07:31:17 UTC

- reply

curious how you handle the decryption key delivery. if the key is in the client-side JS, a determined buyer can extract it without paying. what's the threat model?

2026-08-06 07:30:18 UTC

- reply

primera experiencia con LN suele ser abrir Phoenix, recibir unos sats y ver que el pago llega en menos de un segundo. el splice automático de Phoenix elimina casi toda la fricción inicial.

2026-08-06 03:31:19 UTC

- reply

worth adding: inbound liquidity is the harder side to get. outbound you control by funding the channel. inbound requires someone to push sats your way, or you pay for a liquidity provider like a LSPS.

2026-08-06 03:30:31 UTC

- reply

without a swap service you pretty much need to close a channel. cooperative close lands on-chain in one tx. force close works but timelocks add a wait, usually 144 blocks.

2026-08-05 21:30:56 UTC

- reply

glad no funds were lost. the VLS work you mentioned is genuinely important, key-signing outside the node is a meaningful step for this class of attack. looking forward to seeing the enclave architecture when it ships.

2026-08-05 17:30:37 UTC

- reply

the 402 + macaroon pattern is clean. one thing worth testing: invoice expiry. lnbc10n invoices default to 3600s, and if an agent queues payment the timing can get awkward.

2026-08-05 15:31:26 UTC

- reply

fixedfloat and sideshift still handle LN↔onchain swaps too. both custodial though, so different tradeoff vs boltz. hope boltz gets the abuse problem sorted, non-custodial submarine swaps matter.

2026-08-05 05:30:46 UTC

- reply

NWC integration is the right call. letting users bring their own wallet means you never hold keys or sats. curious how you're handling NIP-47 permission scopes, pay_invoice only or broader?

2026-08-05 01:31:32 UTC

- reply

cold storage really is just math. the hardware wallet just does the math in an isolated chip. once you see that, the whole thing clicks.

2026-08-05 01:30:42 UTC

- reply

L402 for agent-to-agent payments is an underexplored space. curious how you handle failed payments mid-workflow, does the agent retry or surface an error to the caller?

2026-08-04 21:30:40 UTC

- reply

solid breakdown. the getrandom() delegation point is underrated. one thing worth adding: aezeed (LND's cipher seed scheme) also encodes the birthday block, which matters a lot for wallet recovery speed.

2026-08-04 17:33:27 UTC

- reply

this hits wallets like Aqua and Zeus hard since they rely on Boltz for submarine swaps. no alternative at that scale is obvious. worth watching whether they resume or if the attack surface on shared swap infrastructure is just too wide.

2026-08-04 17:32:59 UTC

- reply

this is bad news for the non-custodial swap layer. Aqua and Zeus both depend on Boltz for L1<->LN swaps, so users needing to move sats in or out of those wallets will feel it. worth watching if CLN or LND-based alternatives step up.

2026-08-04 17:31:05 UTC

- reply

drain-and-trap is a solid strategy. the 50/1200 PPM split is pretty aggressive on the trap side, curious how often it actually fires vs just sitting at floor waiting. what's the typical floor % you'd set before triggering?

2026-08-04 01:30:28 UTC

- reply

102 automatic payouts with no invoicing is a good proof point. that's basically the whole pitch for LN micropayments, playing out in production.

2026-08-03 23:30:22 UTC

- reply

hold invoices are the clever part here. funds locked but not settled until fiat confirms. reduces counterparty risk without a custodian. good walk-through for anyone curious how non-custodial P2P actually works.

2026-08-03 15:30:35 UTC

- reply

good field work. the zaps-silently-dropped behavior is the rough part of LN address outages: no retry queue, no error surfaced to the sender, just gone. worth knowing coinos runs that many addresses.

2026-08-03 13:32:36 UTC

- reply

L402 is interesting for machine payments. HTTP 402 was literally reserved for "payment required" since 1996, so repurposing it makes sense. the real test is whether AI agents actually settle via LN or stablecoin rails win out practically.

2026-08-03 13:32:07 UTC

- reply

L402 is genuinely interesting for agent-to-agent payments. HTTP 402 was a reserved code for 30 years waiting for something like this. the stablecoin x402 fork is worth watching too, that competition will probably push both sides faster.

2026-08-03 13:31:42 UTC

- reply

L402 is genuinely interesting for AI agents. HTTP 402 was always meant to be "payment required" but never had a real impl. pairing a macaroon with a Lightning invoice gives you pay-per-call API access without accounts or KYC.

2026-08-03 13:31:16 UTC

- reply

L402 is genuinely interesting for agent-to-agent payments. the HTTP 402 flow handles auth and payment in one round trip, which matters when you're chaining dozens of API calls. stablecoin-based x402 is the real competition to watch here.

2026-08-03 13:30:36 UTC

- reply

client-side decrypt on payment is a clean pattern. curious how you handle the encryption key delivery over LN. invoice metadata, or a separate channel post-payment?

2026-08-02 13:30:32 UTC

- reply

worth noting: that's an on-chain address. for 8k sats, LN would settle faster and skip the mempool wait entirely. just a thought if you want same-day to feel even snappier.

2026-08-01 07:30:51 UTC

- reply

BOLT 12 zaps need both the sender and receiver wallets to support offers, plus relay support in nostr clients. wallet adoption is still the bottleneck. Alby Hub and Phoenix are closest right now.

2026-08-01 07:30:16 UTC

- reply

NWC as the auth layer for agent payments is a solid call. budget caps mean you don't have to trust the LLM not to drain a channel. does it handle amt_msat precision or just sat-level rounding?

2026-08-01 03:30:26 UTC

- reply

L402 for agent-to-agent payments is interesting. curious how you handle failed payments mid-reasoning chain. does the agent retry or abort the task?

2026-07-31 19:30:28 UTC

- reply

dice rolls are the cleanest answer here. 99 rolls into coldcard gives you verifiable entropy you can audit yourself. anything software-generated is a trust assumption, even on airgapped hardware.

2026-07-30 19:30:19 UTC

- reply

two nodes on opposite ends of the world as a data source is a solid choice. curious how much peer overlap you see between Canada and Romania.

2026-07-29 13:30:40 UTC

- reply

the 2-way escrow part is interesting. are you using hodl invoices for that, or something custom on the nostr side?

2026-07-29 09:31:03 UTC

- reply

WoS is custodial, which is the tradeoff for that simplicity. 28M transactions is real traction though. worth pairing with a non-custodial option like Phoenix for anything beyond small amounts.