Lightning Network allows users to swap pre-signed transactions as credit notes which can be cashed out in Bitcoins. We fired it up and tested a real payment at a restaurant to find out how practical it is and which business scenarios are opening up. Before trying this at home, read the important notice at the bottom!
Lightning dinner: laptop connected with remote lightning node, burrata and orecchiette.
To “exchange signed transactions” means that if you are the merchant and I am the buyer I will give you a transaction signed with my keys, now it’s up to you to decide if you want to sign it too and cash it out (i.e. putting it “on-chain”) or pass it over to someone else you have to pay, who, in turn, will decide what to do with it. This process moves as later in time as the receiver wants the moment when the on-chain bitcoin transaction happens, moreover, the Lightning Network structure allows to compact different payments and bring them “on chain” altogether: paying the bitcoin transaction fee once. It is somehow similar to debit card payment circuits, where merchants see the pending balance collected during the day but such balance becomes confirmed only after an overnight batch operation.
In our scenario we approached a typical Italian Restaurant, Il Trullo, which was already accepting Bitcoins and we set up his Lightning wallet. At the same time we created a lightning wallet for us and filled it with a few satoshis (about 60€). Now we opened a lightning channel from our wallet to Trullo’s wallet. Opening a channel is basically the creation of a multisig wallet between the two parties. In chronological sequence we sat down, ordered one large “Burrata”, a delicious type of mozzarella which core is still melting, two “Orecchiette al Ragù”, drinks and coffees. For the purpose of the experiment we immediately created a Lightning invoice and paid it from our Lightning wallet. The confirmation on Trullo’s Lightning wallet was instant and thus we proceeded to close the channel. Closing the channel means that the owner wants to take the funds out of the Litghtning Network, this operation should be batched in order to group various payments but we did it right away. Closing the channel is an on-chain operation and by default a channel is closed after 200 confirmations, Luca 0xVaccaro, operating the lightning node, changed configuration to continue within 6 confirmations. When the channel status is closed the funds can be withdrawn to a normal bitcoin address. Also this withdraw operation should be batched. We didn’t batch because we are going the be quite the lonely Lightning payers for a while and because the batching becomes very advantageous when there is an aggregator with channels open from all customers: the merchant only needs a channel from such aggregation hub. I think it’s also interesting that Lightning invoices are just payable, it means anyone can pay that invoice.
Discussion
So what does this all mean from a merchant point of view? And for crypto-entrepreneurs? And from a speculator point of view?
- Merchants wants a payment network to be fast and secure. Lightning Network is really fast and the general structure builds upon the Bitcoin protocol retaining its cryptographic properties. The proposed tradeoff is to avoid proof of works as long as possible and create a secondary market where “half signed transactions” are immediately exchanged. It’s easy to see the close and withdraw operations as nightly accounting batches, nothing new for current merchants, in fact even “normal” payment networks have their own internal balances from which merchants withdraw to their bank accounts. My personal opinion, not based on a survey yet, is that medium to small merchants will look for customer aggregators, so that they won’t need to persuade every client to open channels with them. Moreover such aggregator will offer the batching processes which makes the Lightning Network very appealing in terms of cost savings (w.r.t. both current on chain technologies and traditional payment networks). Imagine you can build PayPal without worrying about the security of its databases: there is where cost saving kicks in and then reflects onto the merchants.
- For an entrepreneur the main discussion topic of Lightning Network is that it introduces a level of centralization. I have to agree that the biggest advantages in using Lightning will come from centralized entities acting as aggregation hubs. Imagine you are a merchant: you want Bitcoins, but you don’t want to pay those fees. The best scenario for you is to have a single channel coming from an aggregation hub which has contacts with all your clients. This will allow you to collect payments from clients and close a single channel. Payments in the Lightning Network don’t need to be direct from payer to receiver but can pass through nodes. The hub will also collect some marginal fees for passing over payments, but its true value proposition will be to provide a single channel for collecting from all customers, finally, on top of that it can setup a nice accounting interface for batching operations. This will happen sooner than later and it’s going to be huge. Invoices are also interesting since anyone can pay for them, this reminded me of a scenario I saw many years ago in micro-finance where the donors would have liked to purchase the single items needed by beneficiaries’ business plans. Payable invoices can also be a cost sharing mechanism where bills are shared within a group.
- As a speculator I am worried about “faster” money. The faster the money, the lesser its value. This is because, given a fixed number of coins, the more they can change hands, the larger the market they describe. Usually the described market is a slowly increasing number (say, the overall hospitality market to continue our dinner example), if you make the coins faster and fixed in number, they must have less value. Therefore I am quite happy with Bitcoin being “slow” and having a separate layer for payments. I can’t say if this will impact Bitcoin price anyway, but having the micro-payments part technically decoupled at least gives you options.
The history books will mention the infamous 10000 BTC Pizza, nonetheless yesterday night a small step was achieved with a 0.0071 BTC Lightning Burrata! Fun fact: just look at those prices, 10000 -> 0.0071, then look at the smallest unit in the lightning network which is 0.001 satoshi.. getting ready for big numbers.
What about Steem?
Well, this technology was born to work on Bitcoin and has been easily ported to Litecoin since the code base is similar. Nonetheless it open an interesting possibility of swapping signed transactions which doesn't necessarily need to be from Bitcoin or Litecoin. If I am willing to accept signed transactions from another network, the Lightning protocol can be adapted to work with it. What is important for the blockchain to be integrated with the Lightning network is to have the concept of "multi-sig wallet". That is necessary because payment channels are exactly that, multi-sig wallets. Will it come to Steem? It could as soon as multisig wallets can be created for Steem, which I am unaware of, but please correct me in the comments below!
Experimental Dinner Setup
You will need in order of importance:
- “I am going to lose money” state of mind,
- a lightning node with a synched bitcoind,
- a Restaurant owner accepting bitcoins, in our setup he had a mycelium wallet to cash-in during the evening.
Full execution cycle:
- fund a Lightning wallet with BTC,
- open a channel from the payer lightning wallet to the receiver lightning wallet,
- emit an invoice from the receiver lightning wallet,
- pay the invoice with the payer lightning wallet,
- close the channel on the receiver’s end,
- withdraw from the receiver’s lightning wallet to the receiver’s BTC wallet.
Deposit from Bitcoin Mainnet to Lightning Wallet
Transaction from a normal BTC wallet funding the Lightning wallet, the lightning address begins with “3” since it is a pay to script hash.
Using a Channel
Sorry for the blur, on top you can see the status of lightning_merkur, our wallet, which has a channel open with lightning_trullo, totaling 80M satoshis all deployed on merkur side. Below you can see lightning_trullo creating an invoice and the last line is lightning_merkur paying it.
Checking a Lightning Invoice
Decopay displays the invoice which lightning_merkur paid
With listfund you can see the balances in lightning_trullo wallet
Closing Channels
listpeers shows the status of channels pointing at lightning_trullo wallet, from lightning_merkur there is a channel of 80M satoshis of which 79M are now deployed on Trullo’s side.
The channel status “CLOSING_COMPLETE” indicates that the funds in that channel are ready to be withdrawn and in fact are no longer in lightning_trullo balance
Withdraw to Bitcoin Mainnet
The lightning withdraw command executes an on-chain transaction, explorer link
All is well what ends well, lightning dinner paid!
IMPORTANT NOTICE
The software is as practical as a working prototype can be, so for our experiment on the 8th of Feb. 2018, we brought our laptop to the restaurant and hammered terminal commands all the way. It was very exciting but don’t try unless you know what you are doing, there is no UI and some error scenarios must be fixed by hand in the local database of the lightning node, so it’s still “sort of hardcore”. In other words: it is likely that you will see your money disappear and can’t figure out why, proceed at your own risk.
Lightning tech notes
- missing standard interfaces, w.i.p. interfaces
- don’t use while bitcoind is synching, for whatever reason this condition makes lightningd commit errors (e.g. forgetting to update the local database)
- when a lightning wallet fires up, it looks by default to the latest 200 blocks to see incoming funds, it can be tricky to see your money
- Elements Project pulls: pull944 pull940
The lightning wallet we used was called “Merkur” and it’s no longer visible in the lightning explorers because its channel with “Trullo” was closed and now it has no other open channels.
- Empiric house rule: closing a channel where only one end has funds (UNILATERAL_CLOSE) is slower and more expansive than closing a channel where both ends still have something (MUTUAL_CLOSE)
SPECIAL THANKS
0xVaccaro, for setting up waldo the lightning node and for being the man on the field.
Edmond, owner of the Trullo, for accepting Bitcoins, for having the patience to bear with us and for the perfect burrata.
SUPPORT
Would you like to see more reckless main-net activity? Well, please upvote :D
Also checkout Waldo Lightning which is the lightning node we operated for the dinner