Funny that a lots of zap verification are failing because of cloudflare and dependence on lnurl. Maybe we should make that nostr native somehow with bolt12 zaps.
Login to reply
Replies (97)
Great idea 💡
I really need to get back to bolt12 zaps, this is my kick in the pants
of course we all should be using bolt12 instead of LNURL.
not all wallets support it, but the most importants do
Just need a way to include a some data (a zap request nostr note) when fetching a bolt12 invoice. Not sure if thats possible @npub179e9...lz4s
With lnurl we include this in the deschash (cln stores the original). So we can retrieve it when the invoice is paid and then we can send the zap.
@npub1xkh6...xycs LNURL has been working. Guess it's because it's hosted on an unaffected server.
I can’t zap this post in Damus, I get “invalid lighting address”
Or even if we had a payer signature or a signature from the lightning node. We just need some way to verify the zap was initiated by a pubkey and a way for clients to verify it was from the designated lightning node that sends the zaps.
I was using coinos while travelling because i lost access to my node at home… probably would have worked otherwise 😭
can it be just a field?
user enters its own bolt12 and then its p2p and anonymous
I’m a bolt12 noob i will have to look at the spec again
Yeah it should still work in those cases
Is there anything stopping clients trying bip353 before lightning-address?
Tried to look up that up and i got an error lol
BIP 0353 - Bitcoin Wiki
I was wondering what was happening to zaps today! I only know the world is down seeing people say it here - I either need to get a life, or I’m doing it right, not sure really 😀
same here, I also have to use LNURL in bitsimp.com for basically all operations (auth, pay, withdrawal). tried to use bolt12 and it was not widely supported back then.
it will be tricky but i think it’s totally worth it
Yes please
since I can’t give you sats right now, I will just give you pity! 😆
Finally!
It’s been going on for over a year now! bitcoin twitter seems unusable. Its self recursive rage bait fed entirely by a confused algo.
Oh i replied to the wrong message. This was meant for the knots vs core thing on X
Yes its totally broken. And they won't fix it because it makes money probably.
I saw someone working on something similar to this:
View quoted note →
hmm
I don’t like that it uses NIP-05 and told @Justin (shocknet) that a few days ago. Otherwise, seems like a promising direction. Rather than Tor nodes or web nodes.
this looks like the right way to do it, nice.
You can use the payer_note field during invoice fetching to put some data in the invoice
hmm ok will try that
Rusty just published a spec for BOLT 12 proof-of-payment which would form the basis of this like two weeks ago.
It seems hard. I ain't mad at cha.
why not use nostr to fetch invoices like 
from @Justin (shocknet) is doing? web clients won't be able to fetch BOLT12 invoices directly, but they can use nostr just fine.
CLINK Protocol Demo
A live demonstration of CLINK (Common Lightning Interface for Nostr Keys), a Nostr-native protocol for Lightning offers and debits.
Lnd not ready yet for bolt12, maybe on 0.21?
This is why LNURL and NIP-05 is flawed. Centralized HTTP DNS servers are not the way.
I ran across this last night from @Tim Bouma and it’s an interesting approach to the issue. We should look into BitTorrent Mainline DHT as well.
🤳🔏🚥🛜🚥🛜
The primal.net http service is down because the data is in CloudFlare. The funny think is that CloudFlare tunnels to physical infrastructure would work.
View quoted note →
GitHub
GitHub - trbouma/dnspub: DNS for nostr npubs
DNS for nostr npubs. Contribute to trbouma/dnspub development by creating an account on GitHub.
View quoted note →
This is why LNURL and NIP-05 is flawed. Centralized HTTP DNS servers are not the way.
I ran across this last night from @Tim Bouma and it’s an interesting approach to the issue. We should look into BitTorrent Mainline DHT as well.
🤳🔏🚥🛜🚥🛜
The primal.net http service is down because the data is in CloudFlare. The funny think is that CloudFlare tunnels to physical infrastructure would work.
View quoted note →
GitHub
GitHub - trbouma/dnspub: DNS for nostr npubs
DNS for nostr npubs. Contribute to trbouma/dnspub development by creating an account on GitHub.
View quoted note →
I can‘t zap rn. Using primal.
Strike is also having cloud flare issues I think.
lets gooo
Yes. Can‘t access strike. That might be a tough one for many 🤷♂️
Maybe wouldn’t even need a full note if it can just be a signature from their nostr key
Sadly it’s a bit more complicated. To avoid making all lightning nodes speak nostr, you probably just want the PoP scheme, which is (a) enough to prove the BOLT 12 invoice came from the public BOLT 12 offer in the profile, (b) the payment preimage (and matching hash in the invoice), (c) the payer key signing the nostr zap info (and matching payer pubkey in the invoice).
There’s a corresponding new PoP field in BIP 321 with the intention of being able to just paste/open a BIP 321 with a BOLT 12 offer (and nostr metadata requesting the PoP) and then once the payment completes the wallet can automatically jump back to the nostr client with the PoP provided.
yes, cloudfare causing all these failures shows why we need alternatives. bolt12 zaps with nostr could be a clean fix without the dependencies on a centralized server system
All a bit off of wallet support, of course, but step one is getting the note type defined and validation in place in clients.
boooo lnurl
For ‘nostr’ to truly be a decentralized system, you need to host your own servers from home.
Depending on whether you can host your own servers without relying on external services, but to do so, you need to know how to open ports on your router, reverse proxy tools such as nginx, apache2, and how to use the terminal.
you don’t need to open ports. your node can make an nwc connection to the wider internet.
I don’t think any zaps are failing with ecash
Hmmmm
We already made it Nostr native
lol
Nostr native somehow lol
Maybe one day in 10 years lol
Yeah, lnurl + Cloudflare in zap verification makes the trust path odd. Nostr native BOLT12 offers on profile could keep it p2p. At Masters of The Lair we love stripping web infra out of payment flows.
testing zaps for this note… we made six attempts to⚡zap this note, at daywalker@noserver4u.de, over a period of about 2 hours. six of the zaps were successfully paid... please check for 6 satoshis received. however, we did find that only four of the payments produced zap receipts in time for our server to recognize them. this is a problem because the user who zapped you would not see an active ⚡icon after zapping. they might think the zap failed, and therefore might not zap you again.... also.... your average zap time was 12096ms (12.1 seconds). we consider this zap time slow... if possible, zaps should be confirmed in under two seconds. (if time is too slow, other nostr users might think your zaps are broken, might not zap you again.) if you wanted to fix this... you could try getting a free rizful lightning address -- 
... if u get it set up, pls reply here so we can do this ⚡zap test again.
Rizful: Lightning Services
Free Lightning vaults, and instant, disposable Lightning Nodes.
Unfortunately, the most popular Lightning implementation (LND) still doesn't support BOLT12. Every major implementation except them supports it.
I would love to kick LNURL to the curb and go full BOLT12, but it can't happen until they get with the program.
they can catch up later. we can have fun in the meantime
When things break this often, it’s the system telling us it was never built to carry freedom. Nostr + BOLT12 feels like the direction where the cracks finally disappear.
It looks like you can fetch the offer code from NIP-01 or NIP-05 
.
GitHub
CLINK/specs/clink-offers.md at main · shocknet/CLINK
Common Lightning Interface for Nostr Keys. Contribute to shocknet/CLINK development by creating an account on GitHub.
That's the logical alternative to the LNURL payment flow:
Instead of: Payer -> HTTP/LNURLp -> Recipient
Do: Payer -> Nostr Relay (Hopefully not Cloudflared) -> Recipient
Of course if we adopted keysend or BOLT12, the payment flow would be Payer -> Recipient without any middlemen.
Monero/Bitcoin works.
LN reliance seems to be based on much weaker assumptions.
100.
Don’t mind me i just shit note
I’m left side of bell curve
Most wallets don’t accept bolt 12 tho huh???🤔
number of lightning nodes and lnurl servers that supported zaps when I made them: 0. just gotta build and hope people adopt.
Bolt12 uses *other nodes* as a relay, problem is Bolt12 is unreliable because it mimics Tor and doesn't work in the browser.
Ohhhh i see
Your the goat
Don’t take me the wrong way
I have built nothing
Except a Nostr podcast
I don’t have the skills and expertise
I saw that Vanessa muted me tho
That’s unfortunate 🧡
Could also use BIP-353 dns text records, but NIP-05 has more traction currently.
yeah that would be the main issue. clients would need gossip to properly make the request i think? also that complexity is huge
The Lightning network already uses other nodes to route payments. Doesn't BOLT12 just extend this concept to also route messages?
Right, between the poor performance/reliability/browser-incompatibility Bolt12 is a dead end... meanwhile, CLINK Offers work reliably today... including with blinded paths on LND so bolt12 can't even claim a privacy advantage
View quoted note →
It extends arbitrary data onto Lightning, which is as much of an attack as jpegs on the chain... payment traffic is naturally bonded
But all that aside, it's introducing 2 round trips across all those hops, each hop exponentially increasing failure probability and mean-time-to-payment
yeah but lightning folks are not going to care about nostr just for our specific usecase. best to build on top of bolt12 but maybe utilize relays as an ln proxy somehow. can just be a lightning node that is also a nostr relay that can make the request for you. not sure. will ponder.
They don't need to care about Nostr anymore than they cared about http to use LNURL, as long as it just works.
Bolt12 simply doesn't work, only a few privacy larps really cared, and they were completely wrong about blinded paths. It was always just astroturf by Spiral and minor implementations jealous of LND's market share.
The separation of concerns is key, not having to trust a nostr relay because of the encryption/signing already provides an instant transport network with the same accessibility of LNURL.
Nostr is also bi-directional, it's not just noffers, but ndebits and nmanage for offers. Offers themselves provide flexible arbitrary data payloads for product details. (t-shirt sizes, sku's, zap receipts etc)
nostr relays are pretty centralizing and not super private though. you could just subscribe to ephemeral events to monitor requests. we need to improve this.
I wouldn't say bolt12 is completely useless, i still like the idea of small idenitifier strings for payments not dependent on tls/web tech.
Why? Let LN handle the LN stuff, nostr can do the nostr stuff. LN wallets are perfectly capable of paying a BOLT 12 offer using the built-in onion messages, and they can figure out reliability if there’s ever an issue with it. Don’t try to rebuild what LN already has.
we are not going to delegate to opening an app to fetch an invoice. noone uses nostr this way.
They're centralizing in social contexts because they're used for discovery and feed subscriptions, but as an RPC transport they're encoded in each noffer and only for ephemeral interactivity, not passively.
They're also not reliant on TLS since you can run a relay without SSL and just address it by IP
From a privacy standpoint, all the keys used in CLINK are wrapped as to not keep a social identity tied or hot on a service endpoint. A node can use as many as it wants for disparate offers/users.
The payloads themselves are encrypted so it's only the kind metadata viewable, but yea NIP42 would be a good add here, actually got a PR for that I need to review on our reference server.
LN stuff is payments.
Bolt12 is arbitrary data on LN, may as well be jpegs on chain.
We'll let Nostr handle arbitrary data.
bolt12 is a lot of things, sounds like you don't like one aspect of it. from what I can tell that concern is pretty overblown due to limits on packet size? the benefit of fetching invoices behind nats natively on lightning without tls/web tech seems pretty useful.
You delegate to the wallet to pay an offer. The fact that there’s a thing called an “invoice” exchanged is irrelevant (and an unfortunate naming mistake).
If you have a built-in wallet, you delegate to that. If you use NWC, the new spec is defined in terms of offers, not invoices. The payer has no need to ever see or think about that invoice, it’s entirely a lightning-internal thing.
I don't like many aspects, it was completely contrived from a lack of principles by the minor implementations pushing the mobile node fantasy.
Even if I didn't care about jpegs on Lightning:
- The performance/reliability are a non-starter
- It doesn't do bi-direction for commercial applications
- It puts the concern at the wrong layer, the payments layer protocol versus the Line-of-Business Application
- My underlying principle is that Lightning is the native money of the internet, so things MUST work in a browser
(but not reliant on on that web tech you can still QR code a noffer with just a relay ip and node pubkey)
- If you want to add functionality, the SDK doesn't touch your underlying node implementation or the BOLT specs and can work with any of them
Nostr offers checks all those boxes, with the added benefit of having an identity layer that can be optionally leveraged along side it.
with lnurl we include a nostr note in the invoice, that's how we get proof that someone initiated the zaps (but not necessarily proof they paid it)
we would need something similar for bolt12, which is why i asked about including data or signature when fetching the invoice from the offer. if we can't do that then we are stuck with lnurl and bolt11
the main unfortunate thing is that it is 2025 and we still have not figured out a good solution to payment flows that require preimages, a good chunk of software doesn't support them, nwc is still not widely adopted...
It's a solved problem if you don't outsource your thinking to Spiral
1. what are the issues with performance and reliability? socket perf with noise is better than tls
2. bidirectional comms are supported via a persistent lightning connection and bidirectional packets. commando is and example of this
3. is this really a big deal
4. it does work in the browser, i have demos (like lnlink.org) that shows fetching invoices over lightning (bolt11 ironically)
i think nostr is cool, but making that a requirement for all lightning applications seems wrong
what is your beef with spiral? and didn't rusty initiate bolt12 not them? I don't get it.
i think it would be good if there was more "here are our use cases" discussions and see if we can map it into lightning instead of acting hostile toward lightning devs. why?
Right, wallets should (though I don’t know about currently) support either setting the payer_note or signing a message with the payer-key as a part of generating proof-of-payment, both of which would suffice.
Definitely need to spec that part out and make sure wallet support it as a part of the BIP 353 payment proof logic, but I don’t think exposing BOLT 12 invoices outside of the LN wallet makes sense.
not the first time I would try something that didn't make sense. i will try to do this with lnsocket-rs and see if it works.
Wallet connections are still pretty new and not every wallet supports them as I said, which makes it really hard to use *anything* that requires proofs.
1) It mimics Tor, each hop is added latency and failure probability, whereas Nostr being a web server is the same performance people expect from any website
2/3) Bi-direction needs to be at the app layer if its to be used in commerce, payments often have additional context... you're not firing the zap receipt from Lightning for example
4) That appears to be a middleware plugin to talk websockets, since the browser requires websockets... nostr is just json and websockets already
Rusty did afaik yes, while Spiral did much of the NGO-level astroturf. Both representing minor implementations focused on the mobile node fantasy.
I recall one such use-case in the repo discussion being Fedimint/Liquid related shitcoinery. Solving the transport of bolt11's would have been adequate if that wasn't their priority, not a whole new BOLT to poison the protocol-level.
The shit that comes out of the NGO's and Blockstream have been a reliable counter-signal in every regard.
Fortunately this isn't about wallet connections, its about getting invoices (and pre-images) to the web without every Lightning node needing to set up a web server.
I don’t think lightning wallets support paying a BOLT 12 invoice directly, so after you fetch it you’re likely to be kinda stuck :p
good point...
Nearly went down the cloudflare route to host an lnbits node. Abandoned ship when cloudflare requested you to add a debit card to the account despite only using the free version.
@Sat Nakamoto could be why you were having issues
Which wallet supports Bolt12 out of Phoenix though...
Hmm how did cloudflare become the center of the internet?
My guess is similar to aws