static lightning address

[KarolStrzelec]

Do you plan to add a static lightning address to your wallet? This should now be possible, and this is very important for youtubers and other promoters to receive donations. Payment processors like coingate already accept LN so it's time for that.

Thank you.

[t-bast]

Why not use ln-url? This is exactly what it was made for, and Phoenix already supports it.

[pm47]

Phoenix supports LNURL-withdraw, user is looking for LNURL-pay.

[t-bast]

What I meant is that it shouldn't be Phoenix' role to generate such invoices on-the-fly and be always online. If a user wants to receive donations, it seems to me that this is best addressed by having the user run a node (because Phoenix can't be always online to receive donations, you don't know when those donations will arrive - even with a static lightning address). So you'd need a node that generates invoices on the fly with lnurl, and donators can pay those with Phoenix.

[pm47]

Right, I thought @KarolStrzelec meant: being able to pay those donation invoices.

[KarolStrzelec]

Do you think that there is no chance for a static LN address? Maybe phoenix should block funds in the wallet until the recipient logs in? Until someone logs in, the transfer could be canceled. Do you think that a large list of waiting transfers is a big problem?

[t-bast]

Maybe phoenix should block funds in the wallet until the recipient logs in? Until someone logs in, the transfer could be canceled. Do you think that a large list of waiting transfers is a big problem?

I think the best we can offer is a notification to a Phoenix user if offline, and holding an incoming payment for a max of 30 seconds. Otherwise this would be hurting the network too much (while a payment is blocked, liquidity from all routing nodes in the payment route is blocked) and considered as spam.

I don't believe this would work for donations that can arrive at any time of the day if user action is necessary (clicking on a notification). I really believe that for your use-case of accepting donations, you need something that runs 24/7, hence some kind of lightning node (it may be a light node, not a full routing node) not just a wallet. This is one of the main distinctions between Bitcoin and Lightning: in Lightning the recipient needs to be online.

[dpad85]

There are two issues:

1. be able to generate at anytime a LN invoice from a static link (LNURL withdraw)
2. be able to receive at anytime a LN payment

The at anytime part is critical and makes this feature seemingly impossible: waking the app can be done, but you also have to start the node, and the node is locked behind the PIN. That's why you need user interaction. Still that would be a great feature so we'll have to think about it.

[KarolStrzelec]

There are two issues:

1. be able to generate **at anytime** a LN invoice from a static link (LNURL withdraw)

2. be able to receive **at anytime** a LN payment

The at anytime part is critical and makes this feature seemingly impossible: waking the app can be done, but you also have to start the node, and the node is locked behind the PIN. That's why you need user interaction. Still that would be a great feature so we'll have to think about it.

Currently, if I want someone to send me a tip on LN I send him my link to tippin.me, if I collect 10,000 sat or more, I transfer it to my wallet. (a lot of people do that) Its not big deal. I think that such a function in phoenix can be very profitable for you and if someone does not take money for 1 year, you will send them on-chain to his address.

[bitcoinuser]

What I meant is that it shouldn't be Phoenix' role to generate such invoices on-the-fly and be always online. If a user wants to receive donations, it seems to me that this is best addressed by having the user run a node (because Phoenix can't be always online to receive donations, you don't know when those donations will arrive - even with a static lightning address). So you'd need a node that generates invoices on the fly with lnurl, and donators can pay those with Phoenix.

I think this change with Phoenix version with Google FCM notification. For now is possible to receive lightning payments without need any action from user and this is great. I love this function. Zebedee Wallet implemented static lightning with LNURL-Pay as you can see here: https://medium.com/zebedee-engineering/announcing-zbd-gg-bc0c682d9bda Will be great to have this on Phoenix too and make sense now with Google FCM that open Phoenix automatically to receive the payment. Obs. Even if my phone be offline, wallets could have something like this: https://github.com/ACINQ/phoenix/issues/117

[fresheneesz]

waking the app can be done, but you also have to start the node, and the node is locked behind the PIN

Can't you simply not require a PIN in situations where someone is trying to pay you? Why require the PIN in that case? For situations where people don't want to be able to passively receive, there could be a settings option for that, right? I don't quite follow the barrier to waking up the app and receiving on the fly.

[earonesty]

this is the protocol reference:

https://github.com/fiatjaf/lnurl-rfc/blob/master/lnurl-pay.md

pretty easy to spin up some servers that answer the lnurl-pay requests with wallet responses. only downside is that those serves can route payments anywhere, so an attacker can steal future funds.

ideally it should be run on a youtuber's own hardware/node.

here's a DIY howto for anyone in this thread that wants to do it themselves: https://github.com/andrerfneves/lightning-address/blob/master/DIY.md

[NickRHill]

The gen3 update that includes splicing and active channel management would lend itself to ad-hoc payments, as you'd expect from a lightning address payment scheme.

The lack of a Lightning address results in having to recommend a custodial wallet as well as a non-custodial wallet. This complicates matters for end users, who may (sadly) just choose to use the custodial wallet.

Having a system that can receive payments to a mobile device only when the device is on or has an internet connection presents privacy issues. A potential attacker could discover information about a user's whereabouts by checking if the user can receive a payment or performing timing analysis on the handshake (possibly at the HTLC level).

I suggest that a lightning address is a very important feature, but it would need to be implemented asynchronously for privacy and to be always-on. In other words, payments would need to be custodially cached until the user is able to receive them. A user may opt out of such a system by simply not publishing their lightning address.

[earonesty]

static noninteractive lightning addresses must involve a server. But it can involve in non-Trusted server or a public server of some kind to hold on to the partially signed transactions until someone comes on to take custody of them. without covenant technology or watchtowers, a person will have to come online fairly regularly or else risk losing funds. so there's always some element of custodial risk.

[NickRHill]

Since the cost in May went to 300 sat/Vb, placing straight on-chain could cause big user losses.

We can get very close to perfect by using an opt-in third-party payment caching service. This could even be a node a user runs themselves. The API for this process would be simple and a minor extension of existing APIs. 

From the UX perspective, this could be as easy as entering the Lightning address into the Phoenix wallet. The user can even enter multiple Lightning addresses.

User enters an LN address ->

Phoenix sends a registration API call to that LN address including an API URL to fetch an invoice to pay that Phoenix user->

Payment caching server carries out it's own validation.

If the lightning address endpoint on the payment caching server accepts the registration, Phoenix client will send an "online" message to the lightning address endpoint on the payment caching server whenever the user goes on-line, or if the phoenix user nudges. For security, the caching server may limit payments to be forwarded only to a specific list of node pubkeys to limit risk of DNS poisoning attacks.

Upon the lightning address payment caching server receiving a payment, it should immediately attempt to pass the payment on by fetching an invoice from the API URL previously registered by Phoenix. If the user is off-line, the API request fails. If the fetch or HTLC fails, Caching server waits for a user-online callback from Phoenix.

Every payment should remain separate, and forwarded in the order they were received, with messages intact.

Phoenix remains completely non-custodial. User has an always-on lightning address experience.

[Jonseed]

I'd like to use Phoenix, but I'm hesitating because it lacks a persistent address to receive payments. A lightning address would be a great addition, if the technical can be worked out.