Lightning @-address but for on-chain?
528 sats \ 9 comments \ @Lumor 17 Dec 2022 bitcoin
Does that exist?
Essentially https://lightningaddress.com but the JSON blob returned in the /.well-known-HTTP request to the domain includes an unused on chain receive address as an option. Backed by BTCPayServer or something way simpler.
I was just annoyed by a "Bitcoin" podcast actually spelling out the identifiers for 2 fiat payment rails for donating to some unrelated cause. Having pronounceable/memorable/tagable on chain addresses might not have value in 100 years if fees become high friction, but would serve us well during the next 10.
Bonus points for PayNym and other more private tx identifier support too. I guess PayNym by itself is that in a way, but if you already have your nym associated with a domain and just want privacy onward from that..
https://github.com/lnurl/luds/blob/legacy/lnurl-pay.md <-- seems to indicate: NO
write
preview
related posts
10 sats \ 1 reply \ @DarthCoin 17 Dec 2022
Just use a paynym https://paynym.is/ or simply a dedicated BTC address (not from your regular wallet).
But the question is who in the right mind still use BTC onchain for donations or small tips etc... Use the damn LN for that. Here read more about the shit ton of solutions and tools for LN
REMINDER:
  • onchain is the settlement, your vault, your central bank, that you barely move it.
  • LN is the fucking payment network, that you use daily, is your spending pocket, is your commercial bank.
Use the 3 levels stash of your bitcoins with amounts for each destination:
reply
0 sats \ 0 replies \ @Lumor OP 17 Dec 2022
We still have many largely empty blocks. It's called PAYnyms for a reason. Essentially they could have the format fragrantleaf69@paynym.is
This standard would provide an extra bridge in the interim until lightning is even more mature.
reply
0 sats \ 6 replies \ @lnproxy 17 Dec 2022
Can't you just add fallback onchain address to your invoices?
reply
0 sats \ 5 replies \ @Lumor OP 17 Dec 2022
That requires an extra hoop for a non-lightning wallet to jump through.
reply
0 sats \ 4 replies \ @lnproxy 17 Dec 2022
haha, yeah but it's a pretty easy hoop if it already has to implement the logic to send the lnurl request. Plus, every onchain wallet should be able to do this.
reply
0 sats \ 3 replies \ @Lumor OP 17 Dec 2022
Yes, every lightning wallet could easily add this support too.
For on chain-only wallets during the next 10 years, many are probably already doing HTTP requests and parsing returned JSON to fetch fiat exchange rates. So adding this on chain address payment support without having to parse LNURL-stuff at all should be easy.
Been using a long recommended lightning wallet for connecting to my own node over Tor sometimes and I would not wish that experience on beginners. For payments with low time preference, I still prefer on chain.
reply
0 sats \ 2 replies \ @lnproxy 17 Dec 2022
parsing a bolt11 invoice is not hard, there's no reason an onchain wallet should not be able to do it.
reply
50 sats \ 1 reply \ @Lumor OP 17 Dec 2022
Okay, I looked at the Bolt 11 fallback option. Bech32 encoding with weird tag format should be okayish to parse.. but it would be nice to be able to have the lnbc1.. invoice blob directly in the initial /.well-known/lnpay/-response and not have to do an additional request using the returned "callback"-URL.
reply
10 sats \ 0 replies \ @lnproxy 17 Dec 2022
Oh, I think I didn't understand you. Yeah, it would be nice to just be able to make a GET request to something like https://lnproxy.org/.well-known/bcurlp/support and get a fresh onchain donation address. I guess it could be part of the lnurl spec, it's kind of like auth, not really dependent on lightning but nice to have in the same spec so you can use one key.
reply