Closing the Lightning Loop: Announcing Loop In
In March, we at Lightning Labs
announced
Lightning Loop, which provides an
on-demand non-custodial
service
to help manage Lightning channels. Our first release, Loop Out, was designed to
make it easier to receive Lightning payments, particularly for those selling
goods and services via Lightning. Today, we’re making Lightning Loop
bi-directional with the addition of Loop
In.
Loop In is designed to make it cheaper, faster and easier to refill Lightning
wallets. For those users who have been spending their Lightning funds on things
like pizza, chicken feeding,
clock messages, mobile phone
minutes, or the latest news,
sadly, a time will come when a Lightning wallet will run out of money. At that
point, Lightning users can close the empty channel and open a new channel
(“channel churn”), or they keep their channel open and use Loop In!
With Loop In, users will be able to keep existing channels open indefinitely,
refilling from any wallet or service that supports “on-chain” bitcoin
transactions, including exchanges (i.e. funds converted from fiat) or Sats
stacked in cold-storage hardware wallets. Like our previous Loop Out release,
this early command line release of Loop In is primarily intended for
experimentation by more advanced Lightning users. However, the roadmap for Loop
In has a large number of optimizations in store, which will make Loop In a
cheaper, faster and easier way to add Lightning funds to a wallet. Not only
does Loop In provide benefits to the user, the reduction in channel churn also
helps promote network stability. If end users were to constantly close and open
channels rather than reuse them, routing nodes would also likely have to open
and close channels more frequently to manage their capital and channel balance.
Additional routing channel churn would increase routing costs and would also
make the channel graph more difficult to synchronize, resulting in less
reliable routing for end users.
Future Directions in Lightning Loop
So far, the focus of Lightning Loop has been to complete both sides of the Loop
and to ensure that we could release a production liquidity service that was
secure, non-custodial, designed to help make the Lightning Network more
distributed, and that could solve immediate problems people encounter when they
join the network. What’s next for the service is to continue improving Loop by
lowering the on-chain costs involved, improving the privacy aspects of the
service, and evolving the future swap protocol to use the chain in a way that
is maximally scalable for a limited, global shared resource.
The technologies we’re evaluating in this effort are at the cutting edge of
both Lightning and the Bitcoin protocol. With
Schnorr/Taproot
we can collapse script executions to save input costs. With
MuSig we can aggregate signatures in such a
way that many Loop transactions require only as much blockchain data as a
single Loop transaction. With a two-phase swap we can improve privacy by
eliminating on-chain scripts. With
AMP,
we can aggregate Loops from many channels into single on-chain transactions.
Further in the future, we also anticipate additional innovations that can
continue to reduce the on-chain footprint of Loop.
Another improvement we’re working on is adding the option to execute Loop In
transactions without having to wait for block confirmations. This ability to
make funds available almost instantly (including from fiat exchanges) will be a
significant improvement to the Lightning user experience. Of course, there are
a number of safety concerns involved with “zero-conf” transactions, so there
will be limits on transactions sizes and other safety measures. In addition,
the risk of losing funds to a double-spend will be borne only by the Loop In
service operator (Lightning Labs), not the Loop user.
Finally, we’re working to add support for both Loop In and Loop Out to our
Lightning App, which was
recently released for mainnet
alpha
on Android and iOS, and which is available for the major desktop
platforms.
Integrate Loop Today
In addition to providing benefits for end users and our Lightning App users as described above, Lightning Loop is designed to empower Lightning developers to build their own apps and services without worrying about practical liquidity issues. Loop In is particularly useful for extending the lifetime of channels and reducing the capital burden for routing nodes. Now that both Loop Out and Loop In are part of the production Loop API, we hope that Lightning developers will consider integrating the complete solution for their users.
In addition to the Loop command line interface, Loop can also be run in daemon
mode to handle multiple simultaneous swaps, and we welcome forks of the Loop
client as well as contributions of features, fixes, or suggestions for the Loop
client. This library serves as a reference implementation for the Loop gRPC
API which can be integrated directly into your
application or service backend.
Try out Loop In
Over the last couple months, we’ve been excited about the uptake of the Loop
Out service, which was set to a safety-minded limit of 0.01 BTC for the initial
launch. As we expand the service with Loop In, we’ll be raising the limit for
Loop Out and Loop In transactions to 0.02 BTC. We’ll also be moving fees to a
model that uses a base fee plus a proportional fee rate. The fees for a Loop
transaction can be observed using loop terms
.
Lightning Labs is committed to growing
adoption of Bitcoin with Lightning and we see Loop as an important component of
that effort. To get involved with lnd, our App, Lightning Loop and the broader
Lightning community, please visit our GitHub repositories for
lnd, Lightning
App, and Lightning
Loop. Also, please join our developer
Slack
for LND which also features channels and IRC integration for more real-time
discussion of our projects. For general feedback, you can also reach us via
Twitter @lightning. For support-related
questions, please contact us
@lightning_help or via email at
[email protected], or by
opening an issue on GitHub.