c7ef4297c0
Taproot spends require a different sighash, so we update our HtlcScript interface to provide the appropriate sighash when sweeping. We also add distinct Timeout/Success Script functions to allow for tapleaf spends which have different locking scripts for different paths. Note that the timeout and success paths will be the same for segwit v0 htlcs, because it has a single branched script containing all spend paths. In future iterations, this differentiation of claim scripts can also be used to use musig2 to collaboratively keyspend P2TR htlcs with the server. This script can be expressed as PriorityScript (because we'll try to keyspend as a priority, and then fall back to a tap leaf spend). As we've done here, segwit v0 spends would just return their single script for PriorityScript, and the claim would be no different from our other claims. |
2 years ago | |
---|---|---|
.github | 2 years ago | |
cmd | 2 years ago | |
docs | 3 years ago | |
labels | 4 years ago | |
liquidity | 2 years ago | |
loopd | 2 years ago | |
loopdb | 2 years ago | |
looprpc | 2 years ago | |
regtest | 3 years ago | |
swap | 2 years ago | |
swapserverrpc | 3 years ago | |
sweep | 2 years ago | |
test | 2 years ago | |
tools | 2 years ago | |
.gitignore | 5 years ago | |
.golangci.yml | 2 years ago | |
.travis.yml | 3 years ago | |
DOCKER.md | 4 years ago | |
Dockerfile | 2 years ago | |
LICENSE | 3 years ago | |
Makefile | 2 years ago | |
README.md | 4 years ago | |
client.go | 2 years ago | |
client_test.go | 2 years ago | |
config.go | 3 years ago | |
executor.go | 3 years ago | |
go.mod | 2 years ago | |
go.sum | 2 years ago | |
interface.go | 2 years ago | |
log.go | ||
loopin.go | 2 years ago | |
loopin_test.go | 2 years ago | |
loopin_testcontext_test.go | 3 years ago | |
loopout.go | 2 years ago | |
loopout_test.go | 2 years ago | |
release.sh | 4 years ago | |
release_notes.md | 2 years ago | |
routing_plugin.go | 3 years ago | |
routing_plugin_test.go | 3 years ago | |
server_mock_test.go | 2 years ago | |
store_mock_test.go | 2 years ago | |
swap.go | 2 years ago | |
swap_server_client.go | 3 years ago | |
testcontext_test.go | 3 years ago | |
uncharge_state.go | ||
updates.go | 4 years ago | |
utils.go | 3 years ago | |
version.go | 2 years ago |
README.md
Lightning Loop
Lightning Loop is a non-custodial service offered by Lightning Labs that makes it easy to move bitcoin into and out of the Lightning Network.
Features
- Automated channel balancing
- Privacy-forward non-custodial swaps
- Opportunistic transaction batching to save on fees
- Progress monitoring of in-flight swaps
Use Cases
- Automate channel balancing with AutoLoop (Learn more)
- Deposit to a Bitcoin address without closing channels with Loop In
- Convert outbound liquidity into inbound liquidity with Loop Out
- Refill depleted Lightning channels with Loop In
Installation
Download the latest binaries from the releases page.
Execution
The Loop client needs its own short-lived daemon to facilitate swaps. To start loopd
:
loopd
To use Loop in testnet, simply pass the network flag:
loopd --network=testnet
By default loopd
attempts to connect to the lnd
instance running on
localhost:10009
and reads the macaroon and tls certificate from ~/.lnd
.
This can be altered using command line flags. See loopd --help
.
Usage
AutoLoop
AutoLoop makes it easy to keep your channels balanced. Checkout our autoloop documentation for details.
Loop Out
Use Loop Out to move bitcoins on Lightning into an on-chain Bitcoin address.
To execute a Loop Out:
loop out <amt_in_satoshis>
Other notable options:
- Use the
--fast
flag to swap immediately (Note: This opts-out of fee savings made possible by transaction batching) - Use the
--channel
flag to loop out on specific channels - Use the
--addr
flag to specify the address the looped out funds should be sent to (Note: By default funds are sent to the lnd wallet)
Run loop monitor
to monitor the status of a swap.
Loop In
Use Loop In to convert on-chain bitcoin into spendable Lightning funds.
To execute a Loop In:
loop in <amt_in_satoshis>
More info
For more information about using Loop checkout our Loop FAQs.
Development
Regtest
To get started with local development against a stripped down dummy Loop server
running in a local regtest
Bitcoin network, take a look at the
regtest
server environment example documentation.
Testnet
To use Loop in testnet, simply pass the network flag:
loopd --network=testnet
Submit feature requests
The GitHub issue tracker can be used to request specific improvements or report bugs.
Join us on Slack
Join us on the LND Slack and join the #loop channel to ask questions and interact with the community.
LND
Note that Loop requires lnd
to be built with all of its subservers. Download the latest official release binary or build lnd
from source by following the installation instructions. If you choose to build lnd
from source, use the following command to enable all the relevant subservers:
make install tags="signrpc walletrpc chainrpc invoicesrpc"
API
The Loop daemon exposes a gRPC API (defaults to port 11010) and a REST API (defaults to port 8081).
The gRPC and REST connections of loopd
are encrypted with TLS and secured with
macaroon authentication the same way lnd
is.
If no custom loop directory is set then the TLS certificate is stored in
~/.loop/<network>/tls.cert
and the base macaroon in
~/.loop/<network>/loop.macaroon
.
The loop
command will pick up these file automatically on mainnet if no custom
loop directory is used. For other networks it should be sufficient to add the
--network
flag to tell the CLI in what sub directory to look for the files.
For more information on macaroons, see the macaroon documentation of lnd.
NOTE: Loop's macaroons are independent from lnd
's. The same macaroon
cannot be used for both loopd
and lnd
.
Build from source
If you’d prefer to build from source:
git clone https://github.com/lightninglabs/loop.git
cd loop/cmd
go install ./...