“A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution.”
This is what is stated in the original Bitcoin whitepaper created by Satoshi Nakamoto. In other words, Bitcoin was originally designed to be a digital cash system that guarantees irreversible transactions without going through financial institutions.
However, despite the fact that part of the original abstract has been fully respected (today, BTC is censorship-resistant), it cannot be said to be a widespread, convenient, and usable payment form.
The problem with the Bitcoin protocol is that it is not scalable. The block time (the time to “mine” a block) is approximately 10 minutes, and the maximum block size is 1 megabyte. As a result, on average, the Bitcoin network can handle only 3.7 tps (transactions per second), which is significantly “poor” for a system that originally hoped to be a global payment system.
Enter the “Lightning Network,” a scalability solution that allows bitcoin to be transferred at instant speed and with virtually no commission costs – ideal for using bitcoin as a payment system.
But what is the Lightning Network in practice?
The Lightning Network is nothing more than an application of Bitcoin, a decentralized messaging system (broadcasting) where instead of sending messages, value is exchanged.
It is formed by a network of Bitcoin payment channels between nodes; the larger the network, the greater the number of transactions, so more channels and nodes mean more success in transaction events.
Unlike the Bitcoin protocol, on the Lightning Network, only two transactions are written on the blockchain: the funding transaction and the settlement transaction. All other transactions take place without touching the blockchain (commitment transaction).
With Bitcoin’s off-chain transactions (Lightning), node operators on both sides of the channel keep track of the balance with the so-called “Channel State.”
Simplifying to the extreme, it is a peer-to-peer protocol for making off-chain transactions between a private channel between us and the recipient; this channel must first be opened and effectively funded with funds from both parties (funding transaction), which will then exchange value for the desired number of transactions, at zero cost, unlimitedly and instantly (commitment transaction).
Once the operations are completed, and it is decided to close the channel, the balance is finalized on-chain and officially updated, taking into account all the transactions carried out (settlement transaction). In summary, it is a sort of accounting ledger where at the end of the operations, the balances of the two operators are counted and updated, writing the final result of their balance net of the transactions carried out.
Let’s see how it works:
Alice wants to open a 1M satoshi channel to Bob’s node (0.01 BTC).
She needs to know Bob’s node URI (The URI is a unique parameter like a web URL). URI = PubKey Node @ IP (or onion address)
Example: 02e74c09ca720c891221164424651f62176a4737a4b2fd4f75a5befee127e90b9e@170.75.160.17:9735
Alice creates a pair of private/public keys using her Bitcoin node and informs Bob’s node that she wants to open a channel via the open_channel message (message in the LN protocol).
In turn, Bob also creates a new pair of private/public keys and gives consent to the channel that Alice is creating, sending his public key to Alice via the accept_channel message.
Alice now creates a funding transaction (from her Bitcoin wallet) that sends 1M satoshi to the multisig address obtained from the two public keys (on-chain multisig transaction).
Alice does not yet transmit this transaction to the Bitcoin network but sends the transaction ID to Bob in an LN message (funding_created), along with her signature to allow Bob to create his commitment transaction.
Both create their commitment transaction. This transaction uses the funds of the Funding transaction: in Alice’s case, it will return all the funds, in Bob’s case, it will return zero satoshi.
Alice and Bob do not exchange the transactions because each of them can build them independently, using the signature of both; they, therefore, exchange only signatures.
Bob, therefore, provides a signature for Alice’s commitment transaction and sends this message using funding_signed.
Now that the signatures have been exchanged, Alice can transmit the funding transaction to the Bitcoin network. The channel between Alice and Bob is open.
Alice’s funds are now on the channel as a local balance/outbound capacity.
Alice can spend but NOT receive.
Bob can receive but NOT spend.
If Alice wants to receive on that channel, she must spend funds first.
So how does Alice send funds?
For on-chain transactions, she needs a public Bitcoin address.
For Lightning transactions, Alice needs an Invoice (Bolt 11).
Example:
lnbc1m1p0m4sj8pp5rq72jn0qjpvut36u9et2j70n0l7rdake5v052kae5skumgz6zldqdqqcqzpgxqrrsssp577msvl9cvekq8z90lcvk86mpr0ve83zzwde9srcg0kesddstjqq9qy9qsqc7lyx5pdpr9wx2rv0y3cewg8qjja40lx4l3t93y84tvuz4x6429qh6wdczm97urd5p45hx4uy8qhyel5xfqfp987cr48867fyuccvpspqpxwaq
Bitcoin’s public address is static and offline;
it can send as many funds as it wants, whenever it wants.
However, invoices are “dynamic” (as per Bolt 11 standard) and “online”;
Alice must request the invoice from the recipient at a specific time in the future (there is a deadline) and for a specific amount.
It cannot send funds if the recipient’s node is offline, and the same applies when it has to receive funds.
The real potential of the Lightning Network lies in the fact that it allows the sending of funds not only from A to B and vice versa, but also to C, D, E… without these being directly connected to the sender. This is done using a smart contract system called Hash Time-Locked Contracts (HTLC).
HTLC = hash verification (H) + time expiration verification.
H = Hash(R)
R = Secret (also known as the Preimage).
For instance, if Alice needs to pay Eric but does not have a direct channel:
- Eric creates a preimage (the secret R) and sends Alice the hash of this secret.
Only Eric knows the secret. - Alice creates an HTLC containing the hash sent by Eric plus a timelock of N Bitcoin blocks.
Within this HTLC, Alice specifies how many bitcoins should be sent:
x bitcoins for Eric, y bitcoins for the participants in the payment chain as a commission for sending it.
For example, Alice must pay 1 bitcoin to Eric, so she locks 1.0003 bitcoins in the HTLC, with 1 bitcoin for Eric and 0.0003 for the chain participants. - Alice sends this HTLC to Bob.
If Bob does not discover Eric’s secret R within N blocks set by Alice, she will regain the locked bitcoins.
Bob is incentivized to discover R to get the commissions. - Bob creates an HTLC containing the hash given by Eric to Alice and a new timelock of N-1, sending it to Carol.
If Carol does not discover Eric’s secret R within N-1 blocks set by Bob, she will regain the locked bitcoins.
Carol is incentivized to discover R to get the remaining commissions. Bob specifies how many bitcoins should be sent within this HTLC: 1 bitcoin for Eric, 0.0002 for the chain participants. If the payment is successful, Bob will pocket 0.0001 bitcoins. - Carol creates an HTLC containing the hash given by Eric to Alice and a new timelock of N-2, sending it to Diana.
If Diana does not discover Eric’s secret R within N-2 blocks set by Carol, she will regain the locked bitcoins. Diana is incentivized to discover R to get the remaining commissions. Carol specifies how many bitcoins should be sent within this HTLC: 1 bitcoin for Eric, 0.0001 for Diana.
If the payment is successful, Carol will pocket 0.0001 bitcoins sent by Bob. - Finally, Diana creates an HTLC containing the hash given by Eric to Alice and a new timelock of N-3, sending it to Eric.
Eric has the secret R used to create the initial hash.
If Eric does not unlock the HTLC within N-3 blocks, he will not receive the payment, and the other participants will regain their locked funds.
Eric is incentivized to unlock the HTLC to receive the payment. - Eric unlocks the HTLC by revealing the secret to Diana.
Diana finally cashes in on the fees by revealing the secret to Carol and unlocking her HTLC.
Carol knows R and unlocks Bob’s HTLC to collect the fees he sent.
Bob now knows R and unlocks Alice’s HTLC to collect the fees.
Alice sent 1 bitcoin to Eric and 0.0003 bitcoin to the participants, who split the fees.
Final conclusions:
The Lightning Network has the potential to be the killer app that could truly eliminate third-party payment intermediaries forever. It is a distributed, decentralized, fast, efficient, and cost-effective system with a high degree of privacy that, with the advent of CBDCs (central bank digital currencies), would be a valid libertarian and independent alternative.
Market and Data
_old_Become an author
Wallet
