Bitcoin dev has fix for Lightning’s existential problem — offline payments
Bitcoin’s Lightning Network has a problem: how do you pay someone if their node is offline?
The Lightning Network is Bitcoin’s most popular scaling solution — a way to ensure ultra-cheap transactions.
Bitcoin’s base layer can only handle around seven transactions per second. Lightning proponents say it can one day process millions.
Lightning is a network of “payment channels,” Bitcoin contracts for which two users hold a private key.
After paying one regular Bitcoin transaction fee (currently around $4 on average) to open a Lightning channel, users can:
- Route Bitcoin payments an unlimited number of times within Lightning (off-chain), updating their contracts for pennies.
- Once they want to exit Lightning, they pay a second and final fee to settle onto Bitcoin’s base layer (on-chain).
- The end result is cheap, fast Bitcoin transactions with potential scale to handle widespread adoption.
Internet connectivity has always been the problem. Users simply cannot send Bitcoin within Lightning if they’re offline.
Bitcoin Core developer Matt Corallo is working on a solution.
Lightning is for mobile devices, which go offline
Writing to the official Lightning-Dev mailing list (a spin-off of the original Bitcoin-Dev list), Corallo explained how frequently-offline Lightning nodes could still receive payments.
His proposal does not require a custodial solution nor locking up channel liquidity for prolonged periods of time.
Mobile devices account for the majority of frequently-offline Lightning nodes. Phones, tablets, and laptops can run Lightning nodes, but they often lose internet access.
Corallo believes tech known as “Period Time Locked Contracts” (PTLCs) is a reasonably good fix that doesn’t rely on trusted third parties — once Lightning is upgraded to support them.
(Corallo’s thread also welcomes suggestions for alternative solutions that do not require PTLCs.)
Bitcoin’s Taproot allows for Lightning upgrade
PTLC is a proposed upgrade to the Lightning Network that changes the primary locking and unlocking method by the Lightning Network’s current Hash Time Lock Contract (HTLC) protocol.
What follows is somewhat technical (if readers are unfamiliar with cryptography, a sufficient summary is math).
HTLCs use hash locks — locks with a hash digest that unlock using preimages. The hash lock typically uses an SHA-256 hashing function plus a 32-byte preimage to generate a 256-bit digest.
PTLCs use point locks that are locked using a public key, also called a point on Bitcoin’s elliptical curve.
Unlocking point locks requires a corresponding signature from a signature adaptor. The key would use 32 bytes, and the signature would use 64 bytes generated by Schnorr signature constructions.
The use of multiparty ECDSA or Schnorr key aggregation and signing allows the combination of a key and its corresponding signature with other keys and signatures, requiring no additional storage space in Bitcoin blocks.
An imperfect solution
Although PTLCs include improved privacy over HTLCs, Corallo admits that the protocol’s privacy is not perfect.
Surveillance nodes may still be able to intercept information, such as the amount of time between a particular PTLC-related forward, and another forward sent shortly afterward with a lower timelock and slightly lower value.
The short interval between the two forwards may indicate the payments are related, even though a surveillance node did not intercept any linkability data.
PTLC functionality will also require a quorum of Lightning Network forwarding node operators to support it. Otherwise, Lightning Network users may not be able to use PTLCs due to sparse availability.
Read more: [Ethereum echoes the Blocksize Wars (why Bitcoin doesn’t need coffee)]
Corallo also expressed concern about Lightning recipients finding a way to steal funds by manipulating invoices on the Lightning Network. He proposed having senders add a random nonce to transactions to protect privacy.
Lightning is not Bitcoin
“Layer 1” Bitcoin users (those that transact on-chain) are spoiled. Satoshi Nakamoto designed Bitcoin to allow offline nodes to broadcast on a “best efforts” basis, simply syncing up with Bitcoin’s network whenever they care to reconnect.
Bitcoin’s whitepaper ensures it’s no big deal if any particular user is offline. All data is stored on the blockchain, ready to sync whenever.
This is particularly useful for people who prefer to keep significant amounts of Bitcoin in cold storage, or happen to find an old hard drive in their attic.
Lightning Network is different because it is “Layer 2.”
Lightning is based on multiple-signature contracts, meaning that multiple Lightning parties have to cooperate in Layer 2 to update balances and settle transactions onto Layer 1.
This explains why Lightning has historically been a slave to internet connectivity; every Lightning transaction is not globally distributed and confirmed by thousands of decentralized node operators, in contrast to Bitcoin Layer 1.
Instead, Lightning’s Layer 2 transactions can occur between as few as two people (often it’s dozens, but still far less than the thousands of Layer 1 node operators.)
Both Lightning counterparties hold a private key to a multisig contract, and both must sign to update their payment channels or settle onto Bitcoin’s Layer 1.
Read more: [What is Bitcoin?]
If both parties aren’t online today, they can’t sign, can’t update their invoices, and can’t settle.
Not to mention, if Lightning users detect a node is no longer part of the network (offline or is attempting to transmit outdated transactions), they can effect an uncooperative channel closure which results in a dispute process before funds are disbursed.
This renders Lightning Network’s internet connectivity problem an existential one.
Corallo’s PTLC pitch could be an important stepping stone to solving it.
Looking for bite-sized news? We’re on Twitter.