<p>You are doing it the correct way. In case you have doubts, you could check if the invoice generated is according to the way you decided by running the command <code>lightning-cli decodepay &lt;invoice&gt;</code> . Below is the result for the invoice that you generated:</p>

<pre><code>lightning-cli decodepay lntb1n1pwhz5a5pp5jcgyzt4578a9y8rk6sv5aylk8j4wqk2grnwwdggaeumfe722324sdq5fysxzmfqwe5kucm9de6qxqyjw5qcqp2fppjmc3rmhe0wngplqnl3002udz6vj3kzwqsfppjg7ddp2vfds5hgdvsvknhdut0fxpe4z6ndth02e8reukhg4lu39xefwevkknh5r7l2ljugknfutfhhumsfprpxefpqwmjq66nkh5kfsu0esx5a0lnwk7lhhvp8tgvexl9cg8meusqty4ls3
{
   "currency": "tb",
   "created_at": 1567708084,
   "expiry": 604800,
   "payee": "023dfbbc3011303a613645671defa34df29934ac19c507c6d42ec88df54a1532df",
   "msatoshi": 100,
   "amount_msat": "100msat",
   "description": "I am vincent",
   "min_final_cltv_expiry": 10,
   "fallbacks": [
      {
         "type": "P2SH",
         "addr": "2NDVm22NNuosAXFbC27Scsn1smMh1QEFZUk",
         "hex": "a914de223ddf2f74d01f827f8bdeae345a64a361381087"
      },
      {
         "type": "P2SH",
         "addr": "2MymqReM8EaYCQKzv4rhcvafGGcddZacUtV",
         "hex": "a914479ad0a9896c2974359065a776f16f49839a8b5387"
      }
   ],
   "payment_hash": "9610412eb4f1fa521c76d4194e93f63caae059481cdce6a11dcf369cf94a8aab",
   "signature": "304402206aeef564e3cf2d7457fc894d94bb2cb5a77a0fdf57e5c45a69e2d37bf3704846022013652103b7206b53b5e964c38fcc0d4ebff375bdfbdd813ad0cc9be5c20fbcf2"
}
</code></pre>

<p>However, as the docs point out, the current c-lightning implementation does not use the addresses from these arrays to fulfill the invoice in case no route to the payee is found.  So, if you show your invoice and the payer is using c-lightning, then it won't be able to make an on-chain transaction to you for that particular invoice, if its bolt11 payment fails. This might be especially pertinent in your case as the node that generated your invoice does not have any open channel that is exposed publicly which has an incoming capacity. </p>

<p>Also as a side-note, using fallbacks doesn't make sense for tiny or time-sensitive payments. Since your invoice amount is only 100 milli-satoshi, the payment to fallback addresses will not be routed/accepted on the Bitcoin network as it does not accept dust payments. In your invoice it is a sub-satoshi amount which is also below the smallest unit of Bitcoin. </p>

CC BY-SA 4.0
2019-09-05T19:17:16.623Z
I hadn't thought of decoding the whole hahaha, what a fool. Thank you
vincenzopalazzo
CC BY-SA 4.0
2019-09-05T19:18:34.253Z
@vincenzopalazzo as a sidenote, since your payment is only 100msat, that payment cannot be accepted on-chain. Fallbacks does not make sense for tiny or time-sensitive payments.
Ugam Kamat
CC BY-SA 4.0
2019-09-05T19:20:34.600Z
I was just studying the RPC module and so I wanted to understand more about this command :)
vincenzopalazzo
CC BY-SA 4.0
2019-09-05T19:14:29.320Z
2019-09-05T19:21:03.740Z
2019-09-05T19:21:03.740Z
Ugam Kamat
<p>I have a question on the command <code>invoice</code> with the optional parameter.</p>

<p>I don't understand how to create the invoice with the optional parameter. The  c-lighitning documentations do not have an example but it says:</p>

<blockquote>
  <p>The fallbacks array is one or more fallback addresses to include in the invoice (in order from most-preferred to least): note that these arrays are not currently tracked to fulfill the invoice.</p>
</blockquote>

<p>My question is <em>How do I separate the address in the command invoice?</em> As an example:</p>

<pre><code>invoice msatoshi=100 label="I want to understand the invoice command" description="I am vincent" fallbacks=[2NDVm22NNuosAXFbC27Scsn1smMh1QEFZUk,2MymqReM8EaYCQKzv4rhcvafGGcddZacUtV]
</code></pre>

<p>The command runs good, but I want to understand if this command is correct.</p>

<p>Below is the command result:</p>

<pre><code>{
   "payment_hash": "9610412eb4f1fa521c76d4194e93f63caae059481cdce6a11dcf369cf94a8aab",
   "expires_at": 1568312884,
   "bolt11": "lntb1n1pwhz5a5pp5jcgyzt4578a9y8rk6sv5aylk8j4wqk2grnwwdggaeumfe722324sdq5fysxzmfqwe5kucm9de6qxqyjw5qcqp2fppjmc3rmhe0wngplqnl3002udz6vj3kzwqsfppjg7ddp2vfds5hgdvsvknhdut0fxpe4z6ndth02e8reukhg4lu39xefwevkknh5r7l2ljugknfutfhhumsfprpxefpqwmjq66nkh5kfsu0esx5a0lnwk7lhhvp8tgvexl9cg8meusqty4ls3",
   "warning_capacity": "No channel with a peer that is not a dead end, has sufficient incoming capacity"
}
</code></pre>

<lightning-network><core-lightning>
Generating Lightning invoice with an optional parameter
vincenzopalazzo
# Generating Lightning invoice with an optional parameter

(Asked by: username_0 on 2019-09-05)

I have a question on the command `invoice` with the optional parameter.

I don't understand how to create the invoice with the optional parameter. The c-lighitning documentations do not have an example but it says:

> The fallbacks array is one or more fallback addresses to include in the invoice (in order from most-preferred to least): note that these arrays are not currently tracked to fulfill the invoice.

My question is *How do I separate the address in the command invoice?* As an example:

```
invoice msatoshi=100 label="I want to understand the invoice command" description="I am vincent" fallbacks=[2NDVm22NNuosAXFbC27Scsn1smMh1QEFZUk,2MymqReM8EaYCQKzv4rhcvafGGcddZacUtV]

```

The command runs good, but I want to understand if this command is correct.

Below is the command result:

```
{
   "payment_hash": "9610412eb4f1fa521c76d4194e93f63caae059481cdce6a11dcf369cf94a8aab",
   "expires_at": 1568312884,
   "bolt11": "lntb1n1pwhz5a5pp5jcgyzt4578a9y8rk6sv5aylk8j4wqk2grnwwdggaeumfe722324sdq5fysxzmfqwe5kucm9de6qxqyjw5qcqp2fppjmc3rmhe0wngplqnl3002udz6vj3kzwqsfppjg7ddp2vfds5hgdvsvknhdut0fxpe4z6ndth02e8reukhg4lu39xefwevkknh5r7l2ljugknfutfhhumsfprpxefpqwmjq66nkh5kfsu0esx5a0lnwk7lhhvp8tgvexl9cg8meusqty4ls3",
   "warning_capacity": "No channel with a peer that is not a dead end, has sufficient incoming capacity"
}

```

**Tags:** lightning-network, core-lightning


---

## 1 answers

### Answer by username_1 on 2019-09-05. Score: 2 | Accepted answer

You are doing it the correct way. In case you have doubts, you could check if the invoice generated is according to the way you decided by running the command `lightning-cli decodepay <invoice>` . Below is the result for the invoice that you generated:

```
lightning-cli decodepay lntb1n1pwhz5a5pp5jcgyzt4578a9y8rk6sv5aylk8j4wqk2grnwwdggaeumfe722324sdq5fysxzmfqwe5kucm9de6qxqyjw5qcqp2fppjmc3rmhe0wngplqnl3002udz6vj3kzwqsfppjg7ddp2vfds5hgdvsvknhdut0fxpe4z6ndth02e8reukhg4lu39xefwevkknh5r7l2ljugknfutfhhumsfprpxefpqwmjq66nkh5kfsu0esx5a0lnwk7lhhvp8tgvexl9cg8meusqty4ls3
{
   "currency": "tb",
   "created_at": 1567708084,
   "expiry": 604800,
   "payee": "023dfbbc3011303a613645671defa34df29934ac19c507c6d42ec88df54a1532df",
   "msatoshi": 100,
   "amount_msat": "100msat",
   "description": "I am vincent",
   "min_final_cltv_expiry": 10,
   "fallbacks": [
      {
         "type": "P2SH",
         "addr": "2NDVm22NNuosAXFbC27Scsn1smMh1QEFZUk",
         "hex": "a914de223ddf2f74d01f827f8bdeae345a64a361381087"
      },
      {
         "type": "P2SH",
         "addr": "2MymqReM8EaYCQKzv4rhcvafGGcddZacUtV",
         "hex": "a914479ad0a9896c2974359065a776f16f49839a8b5387"
      }
   ],
   "payment_hash": "9610412eb4f1fa521c76d4194e93f63caae059481cdce6a11dcf369cf94a8aab",
   "signature": "304402206aeef564e3cf2d7457fc894d94bb2cb5a77a0fdf57e5c45a69e2d37bf3704846022013652103b7206b53b5e964c38fcc0d4ebff375bdfbdd813ad0cc9be5c20fbcf2"
}

```

However, as the docs point out, the current c-lightning implementation does not use the addresses from these arrays to fulfill the invoice in case no route to the payee is found. So, if you show your invoice and the payer is using c-lightning, then it won't be able to make an on-chain transaction to you for that particular invoice, if its bolt11 payment fails. This might be especially pertinent in your case as the node that generated your invoice does not have any open channel that is exposed publicly which has an incoming capacity.

Also as a side-note, using fallbacks doesn't make sense for tiny or time-sensitive payments. Since your invoice amount is only 100 milli-satoshi, the payment to fallback addresses will not be routed/accepted on the Bitcoin network as it does not accept dust payments. In your invoice it is a sub-satoshi amount which is also below the smallest unit of Bitcoin.

> **Comments:**
> **username_0**: I hadn't thought of decoding the whole hahaha, what a fool. Thank you  
> **username_1**: @username_0 as a sidenote, since your payment is only 100msat, that payment cannot be accepted on-chain. Fallbacks does not make sense for tiny or time-sensitive payments.  
> **username_0**: I was just studying the RPC module and so I wanted to understand more about this command :)  

---

