For the longest time, the lightning network payment mechanism has revolved around BOLT 11 (BOLT stands for Basics of Lightning Technology and covers all Lightning Network specifications). This involves invoice generation, where the user can pay the invoice, and the recipient receives his funds.

Summary of the Lightning Invoice

A lightning network invoice is how you receive payments on the lightning network. It is similar to Bitcoin addresses but has some differences.

One of the differences is that unlike Bitcoin, where you (the payee) generate an address and share it with the payer to send funds, Lightning works in reverse order, where the payer requests an invoice of a specific amount from the recipients and only gets to pay the recipient when he has been provided with the invoice. With Bitcoin, the address is not associated with the amount being sent, whereas, in Lightning, the amount to be sent is included in the lightning invoice.

It is also good to point out that with the lightning invoice, payment can only be made once; this is not the case for Bitcoin, whereby an address can receive funds multiple times (although this is not recommended).

Example of a Lightning Invoice:

lntb1u1pwz5w78pp5e8w8cr5c30xzws92v36sk45znhjn098rtc4pea6ertnmvu25ng3sdpywd6hyetyvf5hgueqv3jk6meqd9h8vmmfvdjsxqrrssy29mzkzjfq27u67evzu893heqex737dhcapvcuantkztg6pnk77nrm72y7z0rs47wzc09vcnugk2ve6sr2ewvcrtqnh3yttv847qqvqpvv398x

As seen above, a lightning invoice starts with the letters 'ln,' which represents Lightning Network. This is followed by some letter codes (2-4 letters), representing the network on which the lightning invoice can work. We have:

bc => Mainnet

tb => Testnet

bs => Signet

bcrt => Regtest

Just after the network codes is the amount to be paid together with the unit of value in which the amount is in. In our case, it is '1u', 1 micro bitcoin.

The other part of the lightning invoice is the data portion which contains relevant information about the payment, such as how old the invoice is, the ID of the node that is receiving the payment, the expiration time of the invoice, invoice description, a backup bitcoin address should the payment fail over the lightning network, etc. You can read more about lightning invoices here.

Good to point out that invoices are also protected by digital signatures, just like the Bitcoin address; what that then implies is that they become invalid if someone tries to modify them. This is so since lightning invoices contain sensitive information like the recipient node Id, the payment hash, etc.

So far, this has been a significant improvement in the Bitcoin ecosystem. However, I have some questions:

• Is it possible to make payment on the lightning network without having to use a lightning invoice?

• If the above is possible, does the payer have the leverage to pay the amount he desires as against a defined amount in the case of the lightning invoice?

This is where Keysend comes in.

Keysend allows an LN node to pay other LN nodes within the lightning network using an individual's public key against lightning Invoices. Keysend removes the need for invoices when making payments. The recipient shares its node ID with the payer, then the payer can decide to pay directly to the user's node, and the payer also has the liberty to pay any amount they choose, giving him the flexibility required.

This is a bit similar to what we currently have while transacting on-chain, but offers more efficiency. Keysend is a Lightning improvement; in this scenario, one can also guarantee faster delivery of funds without waiting for six blocks (as seen in the case of Bitcoin).

Keysend has a robust usage system, especially in areas where payment management and remittance might not be all good or in regions with limitations on cross-border payments.

Enabling and working with Keysend

To begin this, I want to believe that you already have Bitcoin and Lightning set up on your local machine. If that is not the case, follow this link to guide you into setting it up.

Also, I think key send is only available in later versions of lnd (as of the time of writing this article), from version 0.14 and later. So, if you have an older version of lnd, kindly update it.

To enable keysend payments, you must update your lnd.conf file to enable accept keysend flag.

All you have to do is go to your conf file and include the following:

accept-keysend=true

PS: Ignore all other configuration files

Once that is done, stop your lnd node (if you are running it) and then go ahead and restart your node.

If you are using Polar, you can right-click on the selected node. From the pop-up, you will see 'additional option' settings, click on it and paste the above configuration code in it.

Before we go ahead and test a transaction using keysend, let us try and top up our lightning node. Thanks to regtest, we can easily confirm the balance.
It is good to point out at this point that if your node is not liquid enough, performing keysend payment (or any payment at all) won't go through, and lnd error messages are not descriptive enough. You might get an error response of

'Incorrect or unknown payment details'

The reason for this error can be due to insufficient balance. So it is always good to ensure that all your checks pass before making a payment, one of which would include funding your lightning node.

PS: If your lightning node is funded, skip this next section. All we want to do is to top up our wallets.

First, we would need to spin up a lightning address.

Address types supported by lnd include p2wkh, npwkh (normal P2WPKH embedded within a P2SH to make it compatible with older wallets that don't recognize native witness addresses), and p2tr. To do this, enter the following command:

lncli newaddress p2wkh

Let's mine some Bitcoin before we pay our lightning invoice. To do this, just run the command:

bitcoin-cli -generate 101

This should mine 101 blocks, therefore, increasing our Bitcoin value access. The next thing we are going to do is to pay the lightning invoice and also confirm the payment by generating some new blocks.

bitcoin-cli sendtoaddress 2NEofJBy87SNH5FWyMgMTQ1s1z53qAMcnrE 50
// bitcoin-cli sendtoaddress "the address you want the bitcoin to be sent" "the value you want to send"

bitcoin-cli -generate 6
// Generate 6 new blocks

Now that we have sent money to our lightning application and we have been able to confirm the transaction by generating six new blocks, let's try sending money to another node on the lightning network using key send.

Sending using Keysend means sending funds directly to a public key. To get the public key of the recipient node, you can run the following command:

lncli getinfo

From the response given, you can be able to retrieve the public id of that node as shown below:

Now that we have the public key, we can then send satoshis to the particular lightning node using the following commands:

lncli sendpayment -d "pubkey" -amt 10 --keysend

We use the 'send payment' method to send satoshis. This method is passed with two parameters, the destination node (denoted as -d in the above) and the amount the sender wants to send, denoted as the -amt. We also have a last flag or check. '--keysend'. This is to inform our runtime that the command we are about to run is key send based.

If we go ahead and try sending some sats to the provided node, we will get this as a result:

Viola. That's it. Quite simple. So we have been able to send money to another node on the network without the node's invoice but just by the 'pub key.'

You can go ahead and then replicate or even implement it in your applications using rpc or rest client.

Concerns around Keysend

EverythingEverything that has brought ease in the Bitcoin ecosystem, including the lightning network, has also brought about a few tradeoffs. Keysend is not an exception, so what can one count as a worry when wanting to implement key send:

• The primary concern regarding the keysend to some people is that your public key is exposed to the lightning network. Remember, a public key gives so much information about a node, some of which include total capacity, peers connected to, fee rates, etc.

• Keysend routing is randomized. That implies that the payment algorithm flow would not always use the lowest fees or the shortest routes. Regardless, these payments would never exceed the maximum fee percent and the maximum delay of the payments.

• There is no enforced consensus on Lightning. As each implementation grows and improves its features, the lightning network's complexity also increases. This would then mean that having standard definitions of all Lightning features implementations will become harder.

• The payer sends the preimage. This implies that the payer cannot prove that they paid anything even after a completed payment. This is because there is no returned information for the payer to verify.

Keysend is important. There are actual cases whereby Keysend becomes of so much importance (like in the case of crowdfunding); in such scenarios, the pros weigh heavier than the cons.

That's all from my end regarding keysend. But one more thing, if you are one like me, or you know anyone interested in a career in Bitcoin and lightning development, go ahead and introduce them to Qala

Qala is a program designed to train the next generation of African Bitcoin and lightning developers. It goes beyond surface learning and deepens your neck into the core of Bitcoin and lightning development. Qala is proof of work, a perfect mix of theory and project-based learning. As a participant, you get to work on diverse projects like open source, personal projects, etc.

Go now and apply to begin your journey in this new exciting world.

Until next time/article, Obrigado.