Abstract

The task at hand was to find a way to use Bitcoin in an everyday setting, in our own office. As the Bitcoin Blockchain doesn’t enable instant transactions required for a vending machine, we had to find a way to implement Lightning Payments instead.

The Lightning Network is a layer over the Bitcoin Blockchain, where people are able to process transactions without any time delay. It is one of the most promising solutions to solve the scalability issue of the Bitcoin Blockchain. This project was a perfect exercise to gain and spread Blockchain and Lightning knowledge in our team – and of course to help our colleagues get their snacks in a seamless way.

The problem

On October 31st, 2008 Satoshi Nakamoto wrote a message in a cryptographic mailing list, where he invited the participants to read his paper “Bitcoin: A Peer-to-Peer Electronic Cash System”. The first answer to this post was by James A. Donald. He wrote: “We very, very much need such a system, but the way I understand your proposal, it does not seem to scale to the required size.” (Satoshi Nakamoto Institute, 2008)

It is incredible to think that the first concern ever formulated about Bitcoin is in fact it’s biggest issue. Take an event in July 2021 for  example. It took 25 minutes for the network to confirm a transaction, instead of the usual 10 minutes.  How could someone use Bitcoin as a currency with such lengthy transaction confirmation times? Waiting 10 minutes is already long, but 25? We are used to being able to pay for things in less than 30 seconds, or even quicker if by credit card. If we want to use Bitcoin as a payment method, there must be a way to process payments quickly, and with low transaction fees – especially in case of microtransactions.

The Lightning Network

These scalability problems are not new to anyone in the crypto space. Already in 2015 the first paper about a faster “second layer solution” was published. This was the paper that introduced the Lightning Network. The key element of the proposed solution was to minimize the transaction time of Bitcoin to just a few seconds by taking the transaction off the chain, which can be done with special wallets, which have to be funded with BTC. This network consists of channels designated for the cash flow between two participants.

A transaction in the Lightning Network occurs as follows:

1. Let’s say we have two users, Alice and Bob, who both own a bitcoin wallet. They both  agree to create a channel between each other. One of them  (let’s say Alice) agrees to fund the channel with a certain amount of money (e.g. 1 BTC). At that point, the technology allows only one user to fund a channel, but Lightning Network developers are working to enable both parties to do so (at the time of writing).
2. After both participants have agreed to open a channel with a certain amount of BTC, both participants exchange their public keys which they normally need for transactions on the BTC Blockchain.
3. A new BTC address is now created on the basis of these two public keys. This address is a special type, called “2-of-2 multisig address”. The unique aspect about this type of address is that both participants’ signatures are needed to validate a transaction. This address is a combination of the public keys of both participants.
4. The penultimate step in building a Lightning channel is to create a so-called refund transaction. As Alice is providing a certain amount of bitcoins for this channel, it must be ensured that it is possible to get the money back without having to trust the user called Bob. Therefore, a Refund transaction is created upfront, which has to be signed by both parties before anything further happens. The Refund transaction becomes valid as the corresponding Lightning channel is funded, which happens in the next step. Furthermore, this transaction is not written on the blockchain, but remains off-chain with the two participants in the Lightning network.
5. As soon as the Refund transaction is validated by both sides, the actual funding transaction is carried out. In this case Alice pays 1 BTC into the multisig address. Now the Lightning Channel is open and can be used for further transactions. Alice always has the possibility to get her Bitcoins back, thanks to the Refund transaction that is already signed and can be executed anytime by publishing it on the bitcoin blockchain.

At the current stage of development of the Lightning Network, there are no actual transactions in a lightning channel, but instead the Refund transaction is updated. As an example: Alice and Bob have a funded Lightning channel together. Alice owns 1 BTC and Bob owns nothing. This means that the refund transaction states a payback of 1 BTC to Alice and nothing to Bob. As Alice “transfers” 0.4 BTC to Bob, Bob will own 0.4 BTC, and Alice 0.6 BTC,as the original maximum funding is 1 BTC. The Refund transaction is updated to 0.6 for Alice, and to 0.4 for Bob. Each time the parties want to send each other BTC, there is no actual movement of the funds, only the Refund transaction is updated. Whenever the parties decide to close the channel, they can execute the Refund transaction, which will be then recorded on the actual Blockchain.

Development process of the Block Explorer

Following this, we split the project into three phases (ct. Fig. “Development Phases”):

• Construction of a prototype
• Addition of advanced features to the existing prototype
• Transition of the prototype to a system ready for production 

During the prototype phase our focus lay on the infrastructure and building the architecture. We needed to consider the fact that Blockchain clients are frequently  updated by their respective developers.

These Blockchain clients, which represent the basic backbone of the application, must be updated as soon as a new release is available. This is challenging because new versions are released frequently, and often at short notice. To minimize potential sources of error, we designed the Block Explorer in such a way that it does not rely on additional external sources. It relies directly on blockchain nodes to provide blockchain data. The correct operation was ensured by monitoring all nodes permanently. For this first phase, we involved software developers and a senior technical architect. After we considered different possible base architectures, we decided to go with a microservice architecture based on the containerization of each microservice.

In the next step we focused on stable and correct data acquisition and transfer from the different blockchains. We also implemented features to process data, meaning  analytical visualizations such as charts or graphs can be shown to the stakeholders. 

After it was ensured that the data was coming in and processed correctly, our designers and UI experts came on board.

Another task was to develop a User Interface based on the stakeholders’ analysis that was specifically customized to our client’s needs.

In addition, we also made sure the product has flexible interfaces that make it possible to link it to other systems. This was accomplished, as we managed a seamless integration into the customer’s existing ERP system.

The Lightning Network in real life scenarios

Without any research or analysis, it is pretty obvious that Lightning Payments are the most useful type of payment when it comes to small purchases. Low cost products that are usually paid with by cash or card are too small to take up precious space on the relatively slow and expensive Bitcoin Blockchain.

To name a few cases in which smaller payments are usual: (Tatge, 2020)

• Tickets for public transportation
• Vending machines
• Supermarkets
• Gastronomy
• Refuel or charge the car

The requirements of these real life purchases are all fulfilled by the improvements the Lightning Network brought to Blockchain technology: 

• Transactions without delay
• Microtransactions down to 0.00000001 BTC
• Relieving the burden on the Bitcoin blockchain by outsourcing transactions

Development

One of the most practical use-cases where the Lightning Network could be used as a solution, is in the case of a vending machine (Tatge, 2020). When the Lightning Network was launched in 2019, we immediately wanted to test it within our office. The most obvious way for us to do this was to implement it in a snack machine.  

We had to reprogram and remodel the machine so it could establish connection with the Lightning Network. We added a small screen that could work with QR codes, to enable handling BTC addresses.  The process of buying a snack then was as follows: 

1. The buyer choses a snack at the vending machine.
2. The machine creates a bill (called “charge” in the Lightning Network), which is displayed as a QR code on the screen.
3. The QR code contains the 2of2 multisig wallet address to which the buyer must send the BTC.
4. The machine checks whether the amount in BTC has arrived. This normally happens within seconds.
5. As soon as the machine recognizes that the correct amount has arrived it delivers the snack.

There is an App which can be used easily to participate in the Lightning Network and to purchase snacks from a vending machine, and it’s called Eclair. (Bitcoin.org, n.d.) This is the app we used for our vending machine too.

Conclusion

We remodeled a classic vending machine to accept Lightning Payments for testing a real life use case of the Lightning Network. . Our goal was to see whether we can enable quick payments with Bitcoin in case of small items in an everyday setting. We managed to find a simple way to reach this goal, and since then, we have successfully implemented Lightning Payments in other machines and used the Lightning Network in several other business transactions worldwide.

Bibliography

Bitcoin.org. (n.d.). Eclair Mobile. Eclair Mobile. https://bitcoin.org/en/wallets/mobile/android/eclairmobile/

Satoshi Nakamoto Institute. (2008, 08 31). Cryptography Mailing List. Bitcoin P2P e-cash paper. https://satoshi.nakamotoinstitute.org/emails/cryptography/threads/1/

Tatge, L. (2020, 05 20). Analysis of use cases for the Lightning Network. Business perspective and value creation. https://medium.com/coinmonks/analysis-of-use-cases-for-the-lightning-network-bitcoin-2-0-cc8b7ac9ee5e