Generating Lightning invoice with an optional parameter

Question

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"
}

Answer 1

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.