<p>When you mention &quot;Lightning address&quot; here, from the rest of the question I assume you mean a Lightning node's ID or public key. If this is the case, then you absolutely cannot create a BOLT11 invoice for an arbitrary node as invoices <a href="https://github.com/lightning/bolts/blob/master/11-payment-encoding.md#requirements-2" rel="nofollow noreferrer">need to be signed by the recipient node</a> using their private key, which you do not have.</p>
<p>One alternative is to actually require and use a non-BOLT-related <a href="https://lightningaddress.com/" rel="nofollow noreferrer">Lightning Address</a> which is an identifier like an email address and uses the &quot;Pay&quot; flow of the <a href="https://github.com/fiatjaf/lnurl-rfc" rel="nofollow noreferrer">LNURL spec</a> under the hood. The disadvantage of using an LNURL-related solution is that the recipient node needs to have some sort of HTTP server/proxy for the flow to work.</p>
<p>A native alternative that does not require the HTTP server, and only requires the recipient's node ID, is something like <a href="https://github.com/lightning/blips/blob/master/blip-0003.md" rel="nofollow noreferrer">bLIP3 Keysend</a>. Note that there is a downside: you cannot use the preimage and invoice signature as proof of payment as the preimage is generated by the sender. However, this might not be an issue for your donation platform, depending on your specific needs.</p>
<p><a href="https://github.com/lightning/bolts/pull/798" rel="nofollow noreferrer">BOLT12 Offers</a> (present in <a href="https://github.com/ElementsProject/lightning" rel="nofollow noreferrer">Core Lightning</a>) is actively been worked on and standardised by various implementations and will solve the problems above while still providing static payment identifiers.</p>

CC BY-SA 4.0
2022-08-26T13:23:47.067Z
Welcome as a contributor :)
Michael Folkson
CC BY-SA 4.0
2022-08-26T13:26:30.410Z
Thanks, Michael! Been lurking too long :)
dunxen
CC BY-SA 4.0
2022-08-26T12:57:22.897Z
2022-08-26T12:57:22.897Z
dunxen
<p>I am building a web service where User A will signup and enter a Lightning address attached to the profile.</p>
<p>Then, User B would want to send some satoshi to the Lightning address of User A as a kind of a donation.</p>
<p>So, I want User A to click a button on my site &quot;Donate this user&quot;, and a fixed/preentered amount would be sent to User B.</p>
<p>However, as Lightning network requires an invoice to be created before sending satoshis, I have a question:</p>
<p>Can I choose any existing and valid Lightning address, not being its owner, and generate a valid invoice for it in order to send a payment right after generation?</p>
<p>For the user it would be hidden and made automatically.</p>
<p>Any advice is appreciated.</p>

CC BY-SA 4.0
2022-04-04T19:05:30.057Z
Perhaps BOLT12 or keysend payments is what you're looking for. You can pay with only one's node id. However, this requires the receiving peer to have a node and be online.
Davidson Souza
CC BY-SA 4.0
2022-08-26T11:42:40.963Z
You should check the [donations plugin](https://github.com/lightningd/plugins/blob/master/donations).
Angelo
<lightning-network><invoices><donation><bolt12-offers><ln-keysend-payments>
Can I create an invoice for a Lightning address I don't own?
Sergei Basharov
# Can I create an invoice for a Lightning address I don't own?

(Asked by: username_0 on 2022-04-04)

I am building a web service where User A will signup and enter a Lightning address attached to the profile.

Then, User B would want to send some satoshi to the Lightning address of User A as a kind of a donation.

So, I want User A to click a button on my site "Donate this user", and a fixed/preentered amount would be sent to User B.

However, as Lightning network requires an invoice to be created before sending satoshis, I have a question:

Can I choose any existing and valid Lightning address, not being its owner, and generate a valid invoice for it in order to send a payment right after generation?

For the user it would be hidden and made automatically.

Any advice is appreciated.

**Tags:** lightning-network, invoices, donation, bolt12-offers, ln-keysend-payments

> **Comments:**
> **username_1**: Perhaps BOLT12 or keysend payments is what you're looking for. You can pay with only one's node id. However, this requires the receiving peer to have a node and be online.  
> **username_2**: You should check the [donations plugin](https://github.com/lightningd/plugins/blob/master/donations).  

---

## 1 answers

### Answer by username_3 on 2022-08-26. Score: 3

When you mention "Lightning address" here, from the rest of the question I assume you mean a Lightning node's ID or public key. If this is the case, then you absolutely cannot create a BOLT11 invoice for an arbitrary node as invoices [need to be signed by the recipient node](https://github.com/lightning/bolts/blob/master/11-payment-encoding.md#requirements-2) using their private key, which you do not have.

One alternative is to actually require and use a non-BOLT-related [Lightning Address](https://lightningaddress.com/) which is an identifier like an email address and uses the "Pay" flow of the [LNURL spec](https://github.com/fiatjaf/lnurl-rfc) under the hood. The disadvantage of using an LNURL-related solution is that the recipient node needs to have some sort of HTTP server/proxy for the flow to work.

A native alternative that does not require the HTTP server, and only requires the recipient's node ID, is something like [bLIP3 Keysend](https://github.com/lightning/blips/blob/master/blip-0003.md). Note that there is a downside: you cannot use the preimage and invoice signature as proof of payment as the preimage is generated by the sender. However, this might not be an issue for your donation platform, depending on your specific needs.

[BOLT12 Offers](https://github.com/lightning/bolts/pull/798) (present in [Core Lightning](https://github.com/ElementsProject/lightning)) is actively been worked on and standardised by various implementations and will solve the problems above while still providing static payment identifiers.

> **Comments:**
> **username_4**: Welcome as a contributor :)  
> **username_3**: Thanks, username_4! Been lurking too long :)  

---

