Is the Bitcoin Lightning Network ready for eCommerce?

If Bitcoin wants to become a broadly accepted payment method, it will have to overcome some of the flaws that make it unattractive for many commerce applications. One of its biggest problems is “transaction speed”, which pretty much precludes it from day-to-day use and will limit its reach as a mean of payment. Crypto developers have taken on the challenge and developed new technologies that intend to improve or fix some of Bitcoins flaws. The Lightning Network is one of them and we wanted to give it a try.

We created a new Lightning Addon for Scipio ERP. It adds  “dated currency conversion”, “historical prices”, the full integration of the LND mechanics and support of the entire order process, including invoicing, payment capturing, accounting and more. In short: it provides all the necessary steps to allow businesses to accept the new currency, while remaining in the legal framework government requires. If you already own a Lightning Wallet and a few Bitcoin, you can check out the implementation with one of our demo-products (if you want to receive order and payment confirmations, please provide a working email address).

Here is what we learned:

Lightning is a step in the right direction

I cannot overstate how essential transaction speed and reliability under load is for businesses. As a merchant, you’d want all order payments to be processed immediately and reliably so that the order process can continue. An interruption in the process can result in dissatisfaction for the customer, or a delay in your own workflow. Unfortunately, Bitcoin is too slow to process the payments and it takes an average of ~20 minutes until an order is “confirmed”. Any risk-averse merchant will wait for the confirmation before delivering digital goods or acknowledging the order of physical merchandise, therefore the process is slowed down. This is very problematic from an ergonomic point of view since customers are in the dark about the status of their order for an undetermined time span. At its worst, Bitcoin had spikes of > 11.000 minutes of confirmation time.

Lightning fixes this aspect by using its own network to collect and confirm transactions. And indeed, in our fastest tests, we managed to secure a confirmation within 5-10 seconds. That makes all the difference in terms of the payment process and one should recognize the achievement by the Lightning community.

…but not without its own flaws

However, actual transaction speed is only one piece of the equation.  As payment performance also needs to be reliable, merchants will want to also reduce dependence on single Lightning installations and therefore distribute their own traffic to multiple servers. Clustering, running several servers redundantly, is a cornerstone strategy for successful online businesses. The problem: Lightning does not really implement the means to allow for this kind of distributed setup. Lightning, or in this case the LND implementation, only allow incoming connections from a pre-configured list of IPs. In fact, the system is pretty much set up to run on the same server, i.e. allow the commerce application, bitcoin, and lightning nodes to share the same server resources. There are ways to connect from an outside system, but setting it up is tricky and dynamic IPs won’t be an option. The competitor c-lightning shares a similar design. As a result, clustering, in particular in a dynamic cloud setup, is very hard and would require a lot of workarounds and configuration management.

Of course, we should keep in mind that Lightning is still in its early stages, so I want to be less critical. But because of how Lightning currently is implemented, scaling the system will have its limits. Without the ability to scale, Lightning will remain unattractive for larger installations.

Lightning has a bad user experience

With most payment providers, the process of setting up and integrating them in your shop is rather painless: it takes a few minutes for an account to be created and a day or so for the bank account to be confirmed and off you go. Unfortunately, things are a little different in the Lightning world, or as this author summarizes his experience:

TL;DR: Sending payments using the Lightning Network is cheaper than the regular Bitcoin network, but suffers from routing errors and wallet bugs that make it impractical even for highly technical users.

Our experiences have been similar:

Interdependence of technology

Lightning is not exactly light-weight. You will require a Bitcoin node and a Lightning node and both should ideally be installed on the same server as your business application. All of which will require a lot of time to set up and configure. Bitcoin will need ~10 days to synchronize the 250GB package (the blockchain) to operate. If one of the systems fails, your business application will not be able to handle cryptocurrency transactions. This is even more problematic, as redundancy cannot be easily achieved (see above).

Incredibly difficult to use

Lightning is not easy to use, neither for merchants or customers. Don’t believe me?

Here are the steps you have to go through to enable Lightning payments:

Merchant

1. Setup Bitcoin node & wait for Bitcoin node to synchronize blockchain (~7-14 days expected wait time)
2. Create a Bitcoin wallet
3. Buy Bitcoin through Bitcoin exchange
4. Fund Bitcoin wallet
5. Setup Lightning node
6. Create a Lightning wallet. For this, you will need a cipher seed, ie. a password that has to be a 24-word string.
7. Unlock the wallet. This will generate a TLS certificate and key. If you want to access the wallet from an external system (and you managed to configure lightning to allow the access from that specific IP), you will have to make sure that your wallet is unlocked with a specific kind of certificate (x509 P-256 curve). The certificate Lightning creates is not of the right kind, so you will have to create it yourself with OpenSSLand override the original cert. Remember to restart lnd and unlock the wallet once the cert is changed and write down the cert location for later.
8. Fund the wallet
9. Open a Lightning channel
10. Fund the channel, so that it can cover the transaction costs. The channel has to be funded by both parties. Since you are only interested in sending out invoices / payment requests to your customers, this would have to be your customer, although you can also take over the funding. The funding amount has to be sufficient (the rules of what is considered sufficient are not exactly straightforward, either).
11. Wait for channel confirmation by at least 6 peers/broadcasters
12. Remember the certificate and key? Copy them. The certificate and key will be required by each of your application systems, which will use it to connect to the node via client. This hard-binds the application server to a single lightning node.
13. LND (a specific Lightning implementation) relies on “Macaroons”, a cookie-like file, which will be generated once you unlock your wallet. These have to be copied to you business application, too.

Remember: if you miss one step, you will not be able to accept payments.

Customer

1. Buy Bitcoin through Bitcoin exchange
2. Get Lightning Wallet or use the Lightning client
3. Fund wallet from another address (Bitcoin wallet or otherwise)
4. Open a new channel
5. Fund your channel
6. Go through checkout, receive Payment-Request. This is a string of ~228 characters length. Copy the string to your phone (or scan a QR-Code. Cross your fingers that the QR-Code is large enough, because 228 character strings don’t translate well to QR-code images).
7. Accept payment and pay. By default you only have 30-60 Minutes to complete, otherwise, Payment will terminate itself. (This is the default Lightning setting, although the merchant can modify this as part of his config)
8. Wait for payment to be accepted by the network
9. Wait for payment to be processed by the business application

Note: You can skip steps 1-6 on subsequent payments (unless you run out of Bitcoin).

Early-Stage technology

Lightning is fun, but very early-stage. We have been operating the system for 4 months and crashes can and will happen all the time. Transaction channels can close or may not have enough peers at any time. There are no push notifications for these events, so you won’t know until a new transaction is placed and fails. Just like with other online payment gateways – there are no offline payments to make up for this design.

Only small payments accepted

Lightning limits each channel to 0.16777216 Bitcoin. Once the limit is reached a new channel will have to be created. Likewise, 0.04194304 Bitcoin are allowed for a single transaction. To bring this into perspective: as of writing a single channel would only allow payments in total of €500 and single transactions of €125. So if you are a merchant selling products through your online store, you’d only be allowed to create invoices of €125 or less and for every €500 of income, a new channel would be required.

The €500 limit alone breaks the neck for many merchants. Meanwhile, the process of opening a channel and funding it with some Bitcoin value for the process fees will make it extremely difficult to automate for business applications.

So what’s the takeaway?

Lightning sets out to improve the overall performance of the Bitcoin-like technologies and at that, it largely succeeds. It is faster in terms of transaction time and our tests have shown that, once set up, Lightning can process single transactions at a fraction of the time Bitcoin would.

Where Lightning fails is at its usefulness for professional clustered environments. Yes, Lightning does allow multiple nodes in its network, but at the same time, it limits the number of systems that can connect to a Lightning node. And sure, payments are considerably faster than Bitcoin, but they are not “instant”. Even under best conditions, it still takes more time for transactions to be secured and processed than with your average credit card payment. In addition, Lightning is neither easy to set up, nor convenient to run.

All of which means that at the current state, Lightning payments, though interesting, are not ready to be used as the primary means for business transactions. That being said, the technology has potential and we will be updating our own components with future releases. Regardless, the demo we provided is fully functional and the component is available to Enterprise users and interested parties on request.