├── .gitattributes ├── lapps ├── guides │ ├── README.md │ ├── add-features │ │ └── README.md │ └── polar-lapps │ │ └── README.md └── next-steps.md ├── lightning-network-tools ├── pool │ ├── faqs.md │ ├── installation.md │ ├── channel-leases.md │ ├── account-recovery.md │ ├── batch-execution.md │ ├── sidecar-channels.md │ ├── channel_leases.md │ └── account_recovery.md ├── lnd │ ├── clustering.md │ ├── configuring-tor.md │ ├── nat-traversal.md │ ├── wallet-management.md │ ├── configuring-watchtowers.md │ ├── nat_traversal.md │ ├── enable-neutrino-mode-in-bitcoin-core.md │ ├── fuzz.md │ ├── inbound-channel-fees.md │ └── watchtower.md ├── faraday │ ├── README.md │ └── get-started.md ├── aperture │ ├── README.md │ ├── lnc-backend.md │ ├── get-aperture.md │ └── pricing.md ├── loop │ ├── README.md │ └── get-started.md ├── taproot-assets │ ├── README.md │ ├── debugging-tapd.md │ ├── collectibles.md │ ├── tips-and-tricks.md │ ├── asset-loop.md │ ├── become-an-edge-node.md │ ├── multisignature.md │ └── minting-assets-with-an-external-signer.md └── lightning-terminal │ ├── recommended-channels.md │ ├── connect.md │ ├── autoopen.md │ ├── command-line-interface.md │ └── liquidity-report.md ├── docs ├── pool │ ├── lightning_pool.md │ ├── SUMMARY.md │ ├── channel_leases.md │ └── account_recovery.md ├── taproot-assets │ ├── examples │ │ └── Makefile │ ├── taproot-asset-channels │ │ ├── litd-hooks.png │ │ ├── tap-channel-funding.png │ │ ├── tap-channel-payment.png │ │ ├── taproot-asset-channels.png │ │ └── taproot-chans-to-local.png │ ├── docker.md │ └── release-notes │ │ ├── release-notes-template.md │ │ └── release-notes-0.6.1.md ├── lit │ ├── images │ │ ├── loop.png │ │ ├── swap1.png │ │ ├── swap2.png │ │ ├── swap3.png │ │ ├── swap4.png │ │ ├── swap5.png │ │ ├── swap6.png │ │ ├── swap7.png │ │ ├── swap8.png │ │ ├── history.png │ │ ├── loop (1).png │ │ ├── loop (2).png │ │ ├── loop (3).png │ │ ├── loop (4).png │ │ ├── routing.png │ │ ├── sending.png │ │ ├── settings.png │ │ ├── receiving.png │ │ ├── routing (1).png │ │ ├── sending (1).png │ │ ├── swap1 (1).png │ │ ├── swap2 (1).png │ │ ├── swap3 (1).png │ │ ├── swap4 (1).png │ │ ├── swap5 (1).png │ │ ├── swap6 (1).png │ │ ├── swap7 (1).png │ │ ├── swap8 (1).png │ │ ├── loop (1) (1).png │ │ ├── loop (1) (2).png │ │ ├── loop (1) (3).png │ │ ├── receiving (1).png │ │ ├── settings (1).png │ │ ├── settings (2).png │ │ ├── settings (3).png │ │ ├── settings (4).png │ │ ├── swap1 (1) (1).png │ │ ├── swap2 (1) (1).png │ │ ├── swap3 (1) (1).png │ │ ├── swap4 (1) (1).png │ │ ├── swap5 (1) (1).png │ │ ├── swap6 (1) (1).png │ │ ├── swap7 (1) (1).png │ │ ├── swap8 (1) (1).png │ │ ├── loop (1) (1) (1).png │ │ ├── loop (1) (1) (2).png │ │ ├── loop (1) (1) (3).png │ │ ├── loop (1) (1) (4).png │ │ ├── routing (1) (1).png │ │ ├── sending (1) (1).png │ │ ├── settings (1) (1).png │ │ ├── settings (1) (2).png │ │ ├── settings (1) (3).png │ │ ├── receiving (1) (1).png │ │ ├── swap1 (1) (1) (1).png │ │ ├── swap2 (1) (1) (1).png │ │ ├── swap3 (1) (1) (1).png │ │ ├── swap4 (1) (1) (1).png │ │ ├── swap5 (1) (1) (1).png │ │ ├── swap6 (1) (1) (1).png │ │ ├── swap7 (1) (1) (1).png │ │ ├── swap8 (1) (1) (1).png │ │ ├── loop (1) (1) (1) (1).png │ │ ├── loop (1) (1) (1) (2).png │ │ ├── loop (1) (1) (1) (3).png │ │ ├── loop (1) (1) (1) (4).png │ │ ├── loop (1) (1) (2) (1).png │ │ ├── loop (1) (1) (2) (2).png │ │ ├── loop (1) (1) (2) (3).png │ │ ├── loop (1) (1) (2) (4).png │ │ ├── receiving (1) (1) (1).png │ │ ├── routing (1) (1) (1).png │ │ ├── sending (1) (1) (1).png │ │ ├── settings (1) (1) (1).png │ │ ├── settings (1) (1) (2).png │ │ ├── settings (1) (1) (3).png │ │ ├── settings (1) (1) (4).png │ │ ├── swap1 (1) (1) (1) (1).png │ │ ├── swap2 (1) (1) (1) (1).png │ │ ├── swap3 (1) (1) (1) (1).png │ │ ├── swap4 (1) (1) (1) (1).png │ │ ├── swap5 (1) (1) (1) (1).png │ │ ├── swap6 (1) (1) (1) (1).png │ │ ├── swap7 (1) (1) (1) (1).png │ │ ├── swap8 (1) (1) (1) (1).png │ │ ├── routing (1) (1) (1) (1).png │ │ ├── sending (1) (1) (1) (1).png │ │ ├── receiving (1) (1) (1) (1).png │ │ ├── settings (1) (1) (1) (1).png │ │ ├── settings (1) (1) (1) (2).png │ │ ├── settings (1) (1) (1) (3).png │ │ ├── settings (1) (1) (1) (4).png │ │ ├── settings (1) (1) (2) (1).png │ │ ├── settings (1) (1) (2) (2).png │ │ ├── settings (1) (1) (2) (3).png │ │ └── settings (1) (1) (2) (4).png │ ├── remote.md │ ├── custom-path.md │ ├── example-nginx.conf │ └── troubleshooting.md ├── lnd │ ├── alloy-models │ │ ├── linear-fee-function │ │ │ ├── fixed-model.png │ │ │ ├── counter-example.png │ │ │ ├── counter-example-show.png │ │ │ └── READM.md │ │ └── README.md │ ├── release-notes │ │ ├── release-notes-0.15.2.md │ │ ├── release-notes-0.15.4.md │ │ ├── release-notes-0.16.2.md │ │ ├── release-notes-0.13.2.md │ │ ├── release-notes-0.15.5.md │ │ ├── release-notes-0.13.3.md │ │ ├── release-notes-0.14.3.md │ │ ├── release-notes-0.16.3.md │ │ ├── release-notes-0.14.1.md │ │ ├── release-notes-template.md │ │ ├── release-notes-0.18.2.md │ │ ├── release-notes-0.18.1.md │ │ ├── release-notes-0.15.3.md │ │ ├── release-notes-0.17.3.md │ │ ├── release-notes-0.17.4.md │ │ ├── release-notes-0.18.5.md │ │ └── release-notes-0.17.1.md │ ├── ruby-thing.rb │ ├── README.md │ ├── nat_traversal.md │ ├── fuzz.md │ ├── sqlite.md │ ├── zero_conf_channels.md │ └── etcd.md └── loop │ └── faqs.md ├── .gitbook └── assets │ ├── image.png │ ├── history.png │ ├── htlc_01.png │ ├── htlc_02.png │ ├── htlc_03.png │ ├── preLND03.png │ ├── preLND04.png │ ├── preLND05.png │ ├── preLND06.png │ ├── 1_welcome.png │ ├── 5_generate.png │ ├── OpenChannel.png │ ├── TAP Trees.png │ ├── allSuccess.png │ ├── bobConnect.png │ ├── display01.png │ ├── image (1).png │ ├── Group 3881(1).png │ ├── Group 3881(2).png │ ├── Group 3882(2).png │ ├── PoolLiteFull.jpg │ ├── aliceDeposit.png │ ├── buildersGuide.png │ ├── commitment_1.png │ ├── commitment_2.png │ ├── completedApp.png │ ├── createNetwork.png │ ├── importScreen.png │ ├── polarWebsite.png │ ├── polarWelcome.png │ ├── preLND02 (1).png │ ├── preLND03 (1).png │ ├── preLND04 (1).png │ ├── preLND05 (1).png │ ├── preLND06 (1).png │ ├── taproot-asset.png │ ├── NodeHealthCheck.png │ ├── actual_loop_in.png │ ├── actual_loop_out.png │ ├── appArchitecture.png │ ├── channelDetails.png │ ├── connectToLnd01.png │ ├── connectToLnd02.png │ ├── connectToLnd03.png │ ├── connectToLnd04.png │ ├── connectToLnd05.png │ ├── invoiceSuccess.png │ ├── modifyUpvote01.png │ ├── modifyUpvote02.png │ ├── modifyUpvote03.png │ ├── modifyUpvote04.png │ ├── networkPostBoot.png │ ├── networkPreBoot.png │ ├── preLND02 (1) (1).png │ ├── review_loop_in.png │ ├── review_loop_out.png │ ├── signAndVerify01.png │ ├── signAndVerify02.png │ ├── signAndVerify03.png │ ├── signAndVerify04.png │ ├── taro.drawio(1).png │ ├── Inbound.drawio(1).png │ ├── taproot-asset tree.png │ ├── RecommendedChannels.png │ ├── appArchitecture (1).png │ ├── buildersGuideStarted.png │ ├── preLND01 (1) (1) (1).png │ ├── psbt_auction_complete.png │ ├── Untitled presentation(1).png │ ├── Untitled presentation(2).png │ ├── Untitled presentation(3).png │ ├── Untitled presentation(4).png │ ├── preLND01 (1) (1) (1) (1).png │ ├── Merkle tree introduction B1.png │ ├── Merkle tree introduction B3.png │ ├── Merkle tree introduction B5.png │ ├── Merkle tree introduction B6.png │ ├── Merkle tree introduction C5.png │ ├── psbt_auction_complete.drawio.png │ ├── psbt_auction_complete.drawio (1).png │ ├── Screenshot from 2022-06-14 12-59-06.png │ ├── Screenshot from 2023-05-24 11-14-57.png │ ├── Screenshot from 2023-05-24 15-18-03.png │ ├── Screenshot from 2023-05-24 15-24-17.png │ ├── Screenshot from 2023-11-17 21-28-57.png │ ├── Screenshot from 2023-11-20 13-18-24.png │ ├── Screenshot from 2024-03-28 10-49-07.png │ ├── Screenshot from 2024-08-22 17-17-37.png │ ├── Screenshot from 2024-08-29 16-34-54.png │ ├── Screenshot from 2024-11-15 11-52-35.png │ ├── Screenshot from 2025-01-17 17-45-19.png │ ├── Screenshot 2022-10-12 at 11-27-59 Lightning Terminal.png │ ├── Screenshot 2022-12-06 at 16-05-51 Lightning Terminal.png │ └── Screenshot 2023-02-16 at 13-09-47 Lightning Terminal.png ├── .github ├── CODEOWNERS ├── pull_request_template.md └── workflows │ └── doc-sync.yaml ├── the-lightning-network ├── payment-channels │ └── README.md ├── payment-lifecycle │ └── README.md ├── pathfinding │ ├── finding-routes-in-the-lightning-network.md │ ├── README.md │ ├── multipath-payments-mpp.md │ └── channel-fees.md ├── liquidity │ ├── README.md │ └── lightning-service-provider.md ├── l402 │ └── implementations-and-links.md ├── taproot-assets │ └── trustless-swap.md ├── multihop-payments │ └── instant-submarine-swaps.md └── overview.md └── scripts └── diff.sh /.gitattributes: -------------------------------------------------------------------------------- 1 | *.md linguist-detectable 2 | -------------------------------------------------------------------------------- /lapps/guides/README.md: -------------------------------------------------------------------------------- 1 | # Guides 2 | 3 | -------------------------------------------------------------------------------- /lightning-network-tools/pool/faqs.md: -------------------------------------------------------------------------------- 1 | # FAQs 2 | 3 | -------------------------------------------------------------------------------- /lightning-network-tools/lnd/clustering.md: -------------------------------------------------------------------------------- 1 | # Clustering 2 | 3 | -------------------------------------------------------------------------------- /lightning-network-tools/pool/installation.md: -------------------------------------------------------------------------------- 1 | # Installation 2 | 3 | -------------------------------------------------------------------------------- /lightning-network-tools/lnd/configuring-tor.md: -------------------------------------------------------------------------------- 1 | # Configuring Tor 2 | 3 | -------------------------------------------------------------------------------- /lightning-network-tools/lnd/nat-traversal.md: -------------------------------------------------------------------------------- 1 | # NAT Traversal 2 | 3 | -------------------------------------------------------------------------------- /lightning-network-tools/pool/channel-leases.md: -------------------------------------------------------------------------------- 1 | # Channel Leases 2 | 3 | -------------------------------------------------------------------------------- /lightning-network-tools/lnd/wallet-management.md: -------------------------------------------------------------------------------- 1 | # Wallet Management 2 | 3 | -------------------------------------------------------------------------------- /lightning-network-tools/pool/account-recovery.md: -------------------------------------------------------------------------------- 1 | # Account Recovery 2 | 3 | -------------------------------------------------------------------------------- /lightning-network-tools/pool/batch-execution.md: -------------------------------------------------------------------------------- 1 | # Batch Execution 2 | 3 | -------------------------------------------------------------------------------- /lightning-network-tools/pool/sidecar-channels.md: -------------------------------------------------------------------------------- 1 | # Sidecar Channels 2 | 3 | -------------------------------------------------------------------------------- /lightning-network-tools/lnd/configuring-watchtowers.md: -------------------------------------------------------------------------------- 1 | # Configuring Watchtowers 2 | 3 | -------------------------------------------------------------------------------- /docs/pool/lightning_pool.md: -------------------------------------------------------------------------------- 1 | # Lightning Pool: A Non-Custodial Channel Lease Marketplace 2 | 3 | -------------------------------------------------------------------------------- /docs/taproot-assets/examples/Makefile: -------------------------------------------------------------------------------- 1 | GOBUILD := go build -v 2 | 3 | build: 4 | cd ./basic-price-oracle && $(GOBUILD) -------------------------------------------------------------------------------- /.gitbook/assets/image.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/image.png -------------------------------------------------------------------------------- /docs/lit/images/loop.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/loop.png -------------------------------------------------------------------------------- /docs/lit/images/swap1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap1.png -------------------------------------------------------------------------------- /docs/lit/images/swap2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap2.png -------------------------------------------------------------------------------- /docs/lit/images/swap3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap3.png -------------------------------------------------------------------------------- /docs/lit/images/swap4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap4.png -------------------------------------------------------------------------------- /docs/lit/images/swap5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap5.png -------------------------------------------------------------------------------- /docs/lit/images/swap6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap6.png -------------------------------------------------------------------------------- /docs/lit/images/swap7.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap7.png -------------------------------------------------------------------------------- /docs/lit/images/swap8.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap8.png -------------------------------------------------------------------------------- /.gitbook/assets/history.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/history.png -------------------------------------------------------------------------------- /.gitbook/assets/htlc_01.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/htlc_01.png -------------------------------------------------------------------------------- /.gitbook/assets/htlc_02.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/htlc_02.png -------------------------------------------------------------------------------- /.gitbook/assets/htlc_03.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/htlc_03.png -------------------------------------------------------------------------------- /.gitbook/assets/preLND03.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/preLND03.png -------------------------------------------------------------------------------- /.gitbook/assets/preLND04.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/preLND04.png -------------------------------------------------------------------------------- /.gitbook/assets/preLND05.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/preLND05.png -------------------------------------------------------------------------------- /.gitbook/assets/preLND06.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/preLND06.png -------------------------------------------------------------------------------- /docs/lit/images/history.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/history.png -------------------------------------------------------------------------------- /docs/lit/images/loop (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/loop (1).png -------------------------------------------------------------------------------- /docs/lit/images/loop (2).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/loop (2).png -------------------------------------------------------------------------------- /docs/lit/images/loop (3).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/loop (3).png -------------------------------------------------------------------------------- /docs/lit/images/loop (4).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/loop (4).png -------------------------------------------------------------------------------- /docs/lit/images/routing.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/routing.png -------------------------------------------------------------------------------- /docs/lit/images/sending.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/sending.png -------------------------------------------------------------------------------- /docs/lit/images/settings.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/settings.png -------------------------------------------------------------------------------- /.gitbook/assets/1_welcome.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/1_welcome.png -------------------------------------------------------------------------------- /.gitbook/assets/5_generate.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/5_generate.png -------------------------------------------------------------------------------- /.gitbook/assets/OpenChannel.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/OpenChannel.png -------------------------------------------------------------------------------- /.gitbook/assets/TAP Trees.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/TAP Trees.png -------------------------------------------------------------------------------- /.gitbook/assets/allSuccess.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/allSuccess.png -------------------------------------------------------------------------------- /.gitbook/assets/bobConnect.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/bobConnect.png -------------------------------------------------------------------------------- /.gitbook/assets/display01.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/display01.png -------------------------------------------------------------------------------- /.gitbook/assets/image (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/image (1).png -------------------------------------------------------------------------------- /docs/lit/images/receiving.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/receiving.png -------------------------------------------------------------------------------- /docs/lit/images/routing (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/routing (1).png -------------------------------------------------------------------------------- /docs/lit/images/sending (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/sending (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap1 (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap1 (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap2 (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap2 (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap3 (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap3 (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap4 (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap4 (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap5 (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap5 (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap6 (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap6 (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap7 (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap7 (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap8 (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap8 (1).png -------------------------------------------------------------------------------- /.gitbook/assets/Group 3881(1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/Group 3881(1).png -------------------------------------------------------------------------------- /.gitbook/assets/Group 3881(2).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/Group 3881(2).png -------------------------------------------------------------------------------- /.gitbook/assets/Group 3882(2).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/Group 3882(2).png -------------------------------------------------------------------------------- /.gitbook/assets/PoolLiteFull.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/PoolLiteFull.jpg -------------------------------------------------------------------------------- /.gitbook/assets/aliceDeposit.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/aliceDeposit.png -------------------------------------------------------------------------------- /.gitbook/assets/buildersGuide.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/buildersGuide.png -------------------------------------------------------------------------------- /.gitbook/assets/commitment_1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/commitment_1.png -------------------------------------------------------------------------------- /.gitbook/assets/commitment_2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/commitment_2.png -------------------------------------------------------------------------------- /.gitbook/assets/completedApp.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/completedApp.png -------------------------------------------------------------------------------- /.gitbook/assets/createNetwork.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/createNetwork.png -------------------------------------------------------------------------------- /.gitbook/assets/importScreen.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/importScreen.png -------------------------------------------------------------------------------- /.gitbook/assets/polarWebsite.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/polarWebsite.png -------------------------------------------------------------------------------- /.gitbook/assets/polarWelcome.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/polarWelcome.png -------------------------------------------------------------------------------- /.gitbook/assets/preLND02 (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/preLND02 (1).png -------------------------------------------------------------------------------- /.gitbook/assets/preLND03 (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/preLND03 (1).png -------------------------------------------------------------------------------- /.gitbook/assets/preLND04 (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/preLND04 (1).png -------------------------------------------------------------------------------- /.gitbook/assets/preLND05 (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/preLND05 (1).png -------------------------------------------------------------------------------- /.gitbook/assets/preLND06 (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/preLND06 (1).png -------------------------------------------------------------------------------- /.gitbook/assets/taproot-asset.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/taproot-asset.png -------------------------------------------------------------------------------- /docs/lit/images/loop (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/loop (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/loop (1) (2).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/loop (1) (2).png -------------------------------------------------------------------------------- /docs/lit/images/loop (1) (3).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/loop (1) (3).png -------------------------------------------------------------------------------- /docs/lit/images/receiving (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/receiving (1).png -------------------------------------------------------------------------------- /docs/lit/images/settings (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/settings (1).png -------------------------------------------------------------------------------- /docs/lit/images/settings (2).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/settings (2).png -------------------------------------------------------------------------------- /docs/lit/images/settings (3).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/settings (3).png -------------------------------------------------------------------------------- /docs/lit/images/settings (4).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/settings (4).png -------------------------------------------------------------------------------- /docs/lit/images/swap1 (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap1 (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap2 (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap2 (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap3 (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap3 (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap4 (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap4 (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap5 (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap5 (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap6 (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap6 (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap7 (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap7 (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap8 (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap8 (1) (1).png -------------------------------------------------------------------------------- /.gitbook/assets/NodeHealthCheck.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/NodeHealthCheck.png -------------------------------------------------------------------------------- /.gitbook/assets/actual_loop_in.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/actual_loop_in.png -------------------------------------------------------------------------------- /.gitbook/assets/actual_loop_out.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/actual_loop_out.png -------------------------------------------------------------------------------- /.gitbook/assets/appArchitecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/appArchitecture.png -------------------------------------------------------------------------------- /.gitbook/assets/channelDetails.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/channelDetails.png -------------------------------------------------------------------------------- /.gitbook/assets/connectToLnd01.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/connectToLnd01.png -------------------------------------------------------------------------------- /.gitbook/assets/connectToLnd02.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/connectToLnd02.png -------------------------------------------------------------------------------- /.gitbook/assets/connectToLnd03.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/connectToLnd03.png -------------------------------------------------------------------------------- /.gitbook/assets/connectToLnd04.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/connectToLnd04.png -------------------------------------------------------------------------------- /.gitbook/assets/connectToLnd05.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/connectToLnd05.png -------------------------------------------------------------------------------- /.gitbook/assets/invoiceSuccess.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/invoiceSuccess.png -------------------------------------------------------------------------------- /.gitbook/assets/modifyUpvote01.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/modifyUpvote01.png -------------------------------------------------------------------------------- /.gitbook/assets/modifyUpvote02.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/modifyUpvote02.png -------------------------------------------------------------------------------- /.gitbook/assets/modifyUpvote03.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/modifyUpvote03.png -------------------------------------------------------------------------------- /.gitbook/assets/modifyUpvote04.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/modifyUpvote04.png -------------------------------------------------------------------------------- /.gitbook/assets/networkPostBoot.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/networkPostBoot.png -------------------------------------------------------------------------------- /.gitbook/assets/networkPreBoot.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/networkPreBoot.png -------------------------------------------------------------------------------- /.gitbook/assets/preLND02 (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/preLND02 (1) (1).png -------------------------------------------------------------------------------- /.gitbook/assets/review_loop_in.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/review_loop_in.png -------------------------------------------------------------------------------- /.gitbook/assets/review_loop_out.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/review_loop_out.png -------------------------------------------------------------------------------- /.gitbook/assets/signAndVerify01.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/signAndVerify01.png -------------------------------------------------------------------------------- /.gitbook/assets/signAndVerify02.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/signAndVerify02.png -------------------------------------------------------------------------------- /.gitbook/assets/signAndVerify03.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/signAndVerify03.png -------------------------------------------------------------------------------- /.gitbook/assets/signAndVerify04.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/signAndVerify04.png -------------------------------------------------------------------------------- /.gitbook/assets/taro.drawio(1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/taro.drawio(1).png -------------------------------------------------------------------------------- /docs/lit/images/loop (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/loop (1) (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/loop (1) (1) (2).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/loop (1) (1) (2).png -------------------------------------------------------------------------------- /docs/lit/images/loop (1) (1) (3).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/loop (1) (1) (3).png -------------------------------------------------------------------------------- /docs/lit/images/loop (1) (1) (4).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/loop (1) (1) (4).png -------------------------------------------------------------------------------- /docs/lit/images/routing (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/routing (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/sending (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/sending (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/settings (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/settings (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/settings (1) (2).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/settings (1) (2).png -------------------------------------------------------------------------------- /docs/lit/images/settings (1) (3).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/settings (1) (3).png -------------------------------------------------------------------------------- /.gitbook/assets/Inbound.drawio(1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/Inbound.drawio(1).png -------------------------------------------------------------------------------- /.gitbook/assets/taproot-asset tree.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/taproot-asset tree.png -------------------------------------------------------------------------------- /docs/lit/images/receiving (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/receiving (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap1 (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap1 (1) (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap2 (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap2 (1) (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap3 (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap3 (1) (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap4 (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap4 (1) (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap5 (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap5 (1) (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap6 (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap6 (1) (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap7 (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap7 (1) (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap8 (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap8 (1) (1) (1).png -------------------------------------------------------------------------------- /.gitbook/assets/RecommendedChannels.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/RecommendedChannels.png -------------------------------------------------------------------------------- /.gitbook/assets/appArchitecture (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/appArchitecture (1).png -------------------------------------------------------------------------------- /.gitbook/assets/buildersGuideStarted.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/buildersGuideStarted.png -------------------------------------------------------------------------------- /.gitbook/assets/preLND01 (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/preLND01 (1) (1) (1).png -------------------------------------------------------------------------------- /.gitbook/assets/psbt_auction_complete.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/psbt_auction_complete.png -------------------------------------------------------------------------------- /docs/lit/images/loop (1) (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/loop (1) (1) (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/loop (1) (1) (1) (2).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/loop (1) (1) (1) (2).png -------------------------------------------------------------------------------- /docs/lit/images/loop (1) (1) (1) (3).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/loop (1) (1) (1) (3).png -------------------------------------------------------------------------------- /docs/lit/images/loop (1) (1) (1) (4).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/loop (1) (1) (1) (4).png -------------------------------------------------------------------------------- /docs/lit/images/loop (1) (1) (2) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/loop (1) (1) (2) (1).png -------------------------------------------------------------------------------- /docs/lit/images/loop (1) (1) (2) (2).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/loop (1) (1) (2) (2).png -------------------------------------------------------------------------------- /docs/lit/images/loop (1) (1) (2) (3).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/loop (1) (1) (2) (3).png -------------------------------------------------------------------------------- /docs/lit/images/loop (1) (1) (2) (4).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/loop (1) (1) (2) (4).png -------------------------------------------------------------------------------- /docs/lit/images/receiving (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/receiving (1) (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/routing (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/routing (1) (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/sending (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/sending (1) (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/settings (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/settings (1) (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/settings (1) (1) (2).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/settings (1) (1) (2).png -------------------------------------------------------------------------------- /docs/lit/images/settings (1) (1) (3).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/settings (1) (1) (3).png -------------------------------------------------------------------------------- /docs/lit/images/settings (1) (1) (4).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/settings (1) (1) (4).png -------------------------------------------------------------------------------- /docs/lit/images/swap1 (1) (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap1 (1) (1) (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap2 (1) (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap2 (1) (1) (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap3 (1) (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap3 (1) (1) (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap4 (1) (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap4 (1) (1) (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap5 (1) (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap5 (1) (1) (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap6 (1) (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap6 (1) (1) (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap7 (1) (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap7 (1) (1) (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/swap8 (1) (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/swap8 (1) (1) (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/routing (1) (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/routing (1) (1) (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/sending (1) (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/sending (1) (1) (1) (1).png -------------------------------------------------------------------------------- /.gitbook/assets/Untitled presentation(1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/Untitled presentation(1).png -------------------------------------------------------------------------------- /.gitbook/assets/Untitled presentation(2).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/Untitled presentation(2).png -------------------------------------------------------------------------------- /.gitbook/assets/Untitled presentation(3).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/Untitled presentation(3).png -------------------------------------------------------------------------------- /.gitbook/assets/Untitled presentation(4).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/Untitled presentation(4).png -------------------------------------------------------------------------------- /.gitbook/assets/preLND01 (1) (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/preLND01 (1) (1) (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/receiving (1) (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/receiving (1) (1) (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/settings (1) (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/settings (1) (1) (1) (1).png -------------------------------------------------------------------------------- /docs/lit/images/settings (1) (1) (1) (2).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/settings (1) (1) (1) (2).png -------------------------------------------------------------------------------- /docs/lit/images/settings (1) (1) (1) (3).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/settings (1) (1) (1) (3).png -------------------------------------------------------------------------------- /docs/lit/images/settings (1) (1) (1) (4).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/settings (1) (1) (1) (4).png -------------------------------------------------------------------------------- /docs/lit/images/settings (1) (1) (2) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/settings (1) (1) (2) (1).png -------------------------------------------------------------------------------- /docs/lit/images/settings (1) (1) (2) (2).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/settings (1) (1) (2) (2).png -------------------------------------------------------------------------------- /docs/lit/images/settings (1) (1) (2) (3).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/settings (1) (1) (2) (3).png -------------------------------------------------------------------------------- /docs/lit/images/settings (1) (1) (2) (4).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lit/images/settings (1) (1) (2) (4).png -------------------------------------------------------------------------------- /.gitbook/assets/Merkle tree introduction B1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/Merkle tree introduction B1.png -------------------------------------------------------------------------------- /.gitbook/assets/Merkle tree introduction B3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/Merkle tree introduction B3.png -------------------------------------------------------------------------------- /.gitbook/assets/Merkle tree introduction B5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/Merkle tree introduction B5.png -------------------------------------------------------------------------------- /.gitbook/assets/Merkle tree introduction B6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/Merkle tree introduction B6.png -------------------------------------------------------------------------------- /.gitbook/assets/Merkle tree introduction C5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/Merkle tree introduction C5.png -------------------------------------------------------------------------------- /.gitbook/assets/psbt_auction_complete.drawio.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/psbt_auction_complete.drawio.png -------------------------------------------------------------------------------- /.gitbook/assets/psbt_auction_complete.drawio (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/psbt_auction_complete.drawio (1).png -------------------------------------------------------------------------------- /.gitbook/assets/Screenshot from 2022-06-14 12-59-06.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/Screenshot from 2022-06-14 12-59-06.png -------------------------------------------------------------------------------- /.gitbook/assets/Screenshot from 2023-05-24 11-14-57.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/Screenshot from 2023-05-24 11-14-57.png -------------------------------------------------------------------------------- /.gitbook/assets/Screenshot from 2023-05-24 15-18-03.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/Screenshot from 2023-05-24 15-18-03.png -------------------------------------------------------------------------------- /.gitbook/assets/Screenshot from 2023-05-24 15-24-17.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/Screenshot from 2023-05-24 15-24-17.png -------------------------------------------------------------------------------- /.gitbook/assets/Screenshot from 2023-11-17 21-28-57.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/Screenshot from 2023-11-17 21-28-57.png -------------------------------------------------------------------------------- /.gitbook/assets/Screenshot from 2023-11-20 13-18-24.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/Screenshot from 2023-11-20 13-18-24.png -------------------------------------------------------------------------------- /.gitbook/assets/Screenshot from 2024-03-28 10-49-07.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/Screenshot from 2024-03-28 10-49-07.png -------------------------------------------------------------------------------- /.gitbook/assets/Screenshot from 2024-08-22 17-17-37.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/Screenshot from 2024-08-22 17-17-37.png -------------------------------------------------------------------------------- /.gitbook/assets/Screenshot from 2024-08-29 16-34-54.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/Screenshot from 2024-08-29 16-34-54.png -------------------------------------------------------------------------------- /.gitbook/assets/Screenshot from 2024-11-15 11-52-35.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/Screenshot from 2024-11-15 11-52-35.png -------------------------------------------------------------------------------- /.gitbook/assets/Screenshot from 2025-01-17 17-45-19.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/Screenshot from 2025-01-17 17-45-19.png -------------------------------------------------------------------------------- /docs/lnd/alloy-models/linear-fee-function/fixed-model.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lnd/alloy-models/linear-fee-function/fixed-model.png -------------------------------------------------------------------------------- /docs/taproot-assets/taproot-asset-channels/litd-hooks.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/taproot-assets/taproot-asset-channels/litd-hooks.png -------------------------------------------------------------------------------- /docs/lnd/alloy-models/linear-fee-function/counter-example.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lnd/alloy-models/linear-fee-function/counter-example.png -------------------------------------------------------------------------------- /docs/lnd/alloy-models/linear-fee-function/counter-example-show.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/lnd/alloy-models/linear-fee-function/counter-example-show.png -------------------------------------------------------------------------------- /docs/taproot-assets/taproot-asset-channels/tap-channel-funding.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/taproot-assets/taproot-asset-channels/tap-channel-funding.png -------------------------------------------------------------------------------- /docs/taproot-assets/taproot-asset-channels/tap-channel-payment.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/taproot-assets/taproot-asset-channels/tap-channel-payment.png -------------------------------------------------------------------------------- /docs/taproot-assets/taproot-asset-channels/taproot-asset-channels.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/taproot-assets/taproot-asset-channels/taproot-asset-channels.png -------------------------------------------------------------------------------- /docs/taproot-assets/taproot-asset-channels/taproot-chans-to-local.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/docs/taproot-assets/taproot-asset-channels/taproot-chans-to-local.png -------------------------------------------------------------------------------- /.gitbook/assets/Screenshot 2022-10-12 at 11-27-59 Lightning Terminal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/Screenshot 2022-10-12 at 11-27-59 Lightning Terminal.png -------------------------------------------------------------------------------- /.gitbook/assets/Screenshot 2022-12-06 at 16-05-51 Lightning Terminal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/Screenshot 2022-12-06 at 16-05-51 Lightning Terminal.png -------------------------------------------------------------------------------- /.gitbook/assets/Screenshot 2023-02-16 at 13-09-47 Lightning Terminal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/HEAD/.gitbook/assets/Screenshot 2023-02-16 at 13-09-47 Lightning Terminal.png -------------------------------------------------------------------------------- /docs/lnd/release-notes/release-notes-0.15.2.md: -------------------------------------------------------------------------------- 1 | # Release Notes 2 | 3 | ## Bug Fixes 4 | 5 | * [A wire parsing bug has been fixed that would cause lnd to be unable _decode_ 6 | certain large blocks](https://github.com/lightningnetwork/lnd/pull/7004) 7 | 8 | # Contributors (Alphabetical Order) 9 | 10 | * Olaoluwa Osuntokun 11 | -------------------------------------------------------------------------------- /docs/lnd/release-notes/release-notes-0.15.4.md: -------------------------------------------------------------------------------- 1 | # Release Notes 2 | 3 | ## Bug Fixes 4 | 5 | * [A wire parsing bug has been fixed that would cause lnd to be unable _decode_ 6 | certain large transactions](https://github.com/lightningnetwork/lnd/pull/7098). 7 | 8 | # Contributors (Alphabetical Order) 9 | 10 | * Oliver Gugger 11 | -------------------------------------------------------------------------------- /docs/pool/SUMMARY.md: -------------------------------------------------------------------------------- 1 | # Table of contents 2 | 3 | * [Introduction](README.md) 4 | * [Overview](overview.md) 5 | * [Installation](install.md) 6 | * [Quickstart](quickstart.md) 7 | * [Accounts](accounts.md) 8 | * [Orders](orders.md) 9 | * [Channel Leases](channel_leases.md) 10 | * [Batch Execution](batch_execution.md) 11 | * [Sidecar Channels](sidecar_channels.md) 12 | * [FAQs](faq.md) 13 | 14 | -------------------------------------------------------------------------------- /.github/CODEOWNERS: -------------------------------------------------------------------------------- 1 | # Add codeowners for specific dirs in the repo based on who's written the 2 | # majority of the content. The docs dir is intentionally excluded because we 3 | # make automated PRs to it for the sync workflow. 4 | build-a-lapp/* @jamaljsr 5 | advanced-best-practices/* @carlaKC 6 | scripts/* @carlaKC 7 | community-resources/* @alexbosworth 8 | intermediate-get-lit/* @ryanthegentry 9 | 10 | -------------------------------------------------------------------------------- /docs/lnd/release-notes/release-notes-0.16.2.md: -------------------------------------------------------------------------------- 1 | # Release Notes 2 | 3 | ## Wallet 4 | 5 | [The mempool scanning logic no longer blocks start 6 | up](https://github.com/lightningnetwork/lnd/pull/7641). The default polling 7 | interval has also been increased to 60 seconds. 8 | 9 | ## Bug Fixes 10 | 11 | [A panic has been fixed](https://github.com/lightningnetwork/lnd/pull/7637) for 12 | neutrino nodes related to sweeper transaction replacement. 13 | -------------------------------------------------------------------------------- /docs/lnd/ruby-thing.rb: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env ruby 2 | 3 | File.open("INSTALL.md", 'r') do |f| 4 | f.each_line do |line| 5 | forbidden_words = ['Table of contents', 'define', 'pragma'] 6 | next if !line.start_with?("#") || forbidden_words.any? { |w| line =~ /#{w}/ } 7 | 8 | title = line.gsub("#", "").strip 9 | href = title.gsub(" ", "-").downcase 10 | puts " " * (line.count("#")-1) + "* [#{title}](\##{href})" 11 | end 12 | end 13 | -------------------------------------------------------------------------------- /lapps/guides/add-features/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: >- 3 | This section will connect your sample app to lnd, and then add new features to 4 | the app based on lnd's APIs. 5 | --- 6 | 7 | # Add Features 8 | 9 | {% page-ref page="connect-to-lnd.md" %} 10 | 11 | {% page-ref page="display-node-alias-and-balance.md" %} 12 | 13 | {% page-ref page="sign-and-verify-posts.md" %} 14 | 15 | {% page-ref page="modify-upvote-action.md" %} 16 | 17 | 18 | 19 | -------------------------------------------------------------------------------- /.github/pull_request_template.md: -------------------------------------------------------------------------------- 1 | Pull Request Checklist 2 | - [ ] The documents updated are not in the `docs/` directory. These files are 3 | synced from upstream repositories ([lnd](https://github.com/lightningnetwork/lnd), [lit](https://github.com/lightninglabs/lightning-terminal), [loop](https://github.com/lightninglabs/loop), [pool](https://github.com/lightninglabs/pool) and [faraday](https://github.com/lightninglabs/faraday)), and 4 | should be updated in their parent repo. 5 | -------------------------------------------------------------------------------- /docs/lnd/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: >- 3 | The guides in this section will walk you through various advanced concepts 4 | within lnd. 5 | --- 6 | 7 | # Additional Guides 8 | 9 | {% page-ref page="configuring\_tor.md" %} 10 | 11 | {% page-ref page="debugging\_lnd.md" %} 12 | 13 | {% page-ref page="fuzz.md" %} 14 | 15 | {% page-ref page="etcd.md" %} 16 | 17 | {% page-ref page="macaroons.md" %} 18 | 19 | {% page-ref page="safety.md" %} 20 | 21 | {% page-ref page="nat\_traversal.md" %} 22 | 23 | {% page-ref page="psbt.md" %} 24 | 25 | {% page-ref page="recovery.md" %} 26 | 27 | {% page-ref page="watchtower.md" %} 28 | 29 | -------------------------------------------------------------------------------- /docs/lnd/release-notes/release-notes-0.13.2.md: -------------------------------------------------------------------------------- 1 | # Release Notes 2 | 3 | ## AMP 4 | 5 | A new command line option (`--amp-reuse`) has been added to make it easier for 6 | users to re-use AMP invoice on the command line using either the `payinvoice` 7 | or `sendpayment` command. 8 | 9 | ## Bug Fixes 10 | 11 | [A bug has been fixed in the command line argument parsing for the 12 | `sendpayment` command that previously prevented users from being able to re-use 13 | a fully 14 | specified AMP](https://github.com/lightningnetwork/lnd/pull/5554) invoice by 15 | generating a new `pay_addr` and including it as a CLI arg. 16 | 17 | # Contributors (Alphabetical Order) 18 | * Olaoluwa Osuntokun 19 | -------------------------------------------------------------------------------- /docs/taproot-assets/docker.md: -------------------------------------------------------------------------------- 1 | # Taproot Assets in Docker 2 | 3 | ## Requirements 4 | - Docker 5 | - git 6 | - a running lnd node 7 | 8 | ## Building from Source 9 | ``` 10 | git clone https://github.com/lightninglabs/taproot-assets 11 | cd taproot-assets 12 | docker build -f dev.Dockerfile -t taproot-assets . 13 | ``` 14 | 15 | ## Starting Docker Container 16 | ### Quick Startup 17 | ``` 18 | docker run --name taproot-assets --rm -v /PATH/TO_YOUR/LND/:/root/.lnd/:ro -v /PATH/TO:YOUR/TAPD/:/root/.tapd/ --net=host tapd --network=testnet --debuglevel=debug --lnd.host=localhost:10009 --lnd.macaroonpath=/root/.lnd/data/chain/bitcoin/testnet/admin.macaroon --lnd.tlspath=/root/.lnd/tls.cert 19 | ``` 20 | 21 | -------------------------------------------------------------------------------- /docs/lnd/release-notes/release-notes-0.15.5.md: -------------------------------------------------------------------------------- 1 | # Release Notes 2 | 3 | ## Bug Fixes 4 | 5 | * [A Taproot related key tweak issue was fixed in `btcd` that affected remote 6 | signing setups](https://github.com/lightningnetwork/lnd/pull/7130). 7 | 8 | * [Taproot changes addresses are now used by default for the `SendCoins` 9 | RPC](https://github.com/lightningnetwork/lnd/pull/7193). 10 | 11 | * [A 1 second interval has been added between `FundingLocked` receipt 12 | checks](https://github.com/lightningnetwork/lnd/pull/7095). This reduces idle 13 | CPU usage for pending/dangling funding attempts. 14 | 15 | # Contributors (Alphabetical Order) 16 | 17 | * Olaoluwa Osuntokun 18 | * Oliver Gugger 19 | * Yong Yu 20 | -------------------------------------------------------------------------------- /lightning-network-tools/faraday/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: >- 3 | Faraday is a suite of tools built to help node operators and businesses run 4 | lnd. Faraday’s tools decrease the operational overhead of running a Lightning 5 | Node. 6 | --- 7 | 8 | # Faraday 9 | 10 | [Faraday](https://lightning.engineering/posts/2020-04-02-faraday/) is a tool developed by Lightning Labs to help you extract valuable analytics and insights from your LND node. 11 | 12 | It primarily helps users understand how capital is flowing through their node, which is useful to help identify underperforming or drained channels and where to deploy capital most efficiently. 13 | 14 | [get-started.md](get-started.md "mention") 15 | 16 | [the-faraday-cli.md](the-faraday-cli.md "mention") 17 | -------------------------------------------------------------------------------- /the-lightning-network/payment-channels/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: >- 3 | Payment channels are multisignature contracts between peers. Payments are made 4 | inside these payment channels and can be settled on the Blockchain. 5 | --- 6 | 7 | # Payment Channels 8 | 9 | The Lightning Network is made up of payment channels. Each channel represents an UTXO on the Bitcoin Blockchain and is cooperatively controlled by two peers, who can transact through that channel as frequently as they want. 10 | 11 | {% content-ref url="lifecycle-of-a-payment-channel.md" %} 12 | [lifecycle-of-a-payment-channel.md](lifecycle-of-a-payment-channel.md) 13 | {% endcontent-ref %} 14 | 15 | {% content-ref url="etymology.md" %} 16 | [etymology.md](etymology.md) 17 | {% endcontent-ref %} 18 | -------------------------------------------------------------------------------- /docs/lnd/release-notes/release-notes-0.13.3.md: -------------------------------------------------------------------------------- 1 | # Release Notes 2 | 3 | ## Wallet 4 | 5 | * [The `DefaultDustLimit` method has been removed in favor of `DustLimitForSize` which calculates the proper network dust limit for a given output size. This also fixes certain APIs like SendCoins to be able to send 294 sats to a P2WPKH script.](https://github.com/lightningnetwork/lnd/pull/5781) 6 | 7 | ## Safety 8 | 9 | * [The `htlcswitch.Switch` has been modified to take into account the total dust sum on the incoming and outgoing channels before forwarding. After the defined threshold is reached, dust HTLC's will start to be failed. The default threshold is 500K satoshis and can be modified by setting `--dust-threshold=` when running `lnd`.](https://github.com/lightningnetwork/lnd/pull/5770) 10 | 11 | # Contributors (Alphabetical Order) 12 | 13 | * Eugene Siegel -------------------------------------------------------------------------------- /scripts/diff.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | if [ $# -ne 3 ]; 4 | then echo "args required: source repo, source dir, target dir" 5 | exit 1 6 | fi 7 | 8 | # We will get our files from the source repo/dir. 9 | sourceDir="$1"/"$2" 10 | 11 | # We will copy these files to destination dir. 12 | destDir="$3" 13 | 14 | # Create our destination dir in case it does not yet exist, because we cannot 15 | # diff a directory that does not exist. 16 | mkdir -p "$destDir" 17 | 18 | # Copy everything from source to destination, replacing what's there. 19 | cp -rf "$sourceDir"/* "$destDir" 20 | 21 | # Remove the source repo that we cloned. 22 | rm -rf "$1" 23 | 24 | # If our sync has resulted in any changes, set an output for the rest of our 25 | # workflow. 26 | if [ -n "$(git status --porcelain)" ]; 27 | then echo ::set-output name=have_diff::"true" 28 | fi 29 | -------------------------------------------------------------------------------- /the-lightning-network/payment-lifecycle/README.md: -------------------------------------------------------------------------------- 1 | # Lightning Network Invoices 2 | 3 | The Lightning Network uses a system of invoices instead of addresses, reflecting the network’s primary function of a payment network. Invoices are generated by the recipient of a payment, and the validity can be limited to a certain amount of time. 4 | 5 | Each invoice is signed by the recipient and contains an amount, expiration time, destination pubkey, supported features and others. Invoices can be canceled by the recipient, too. 6 | 7 | These mechanisms help eliminate overpayments, underpayments, late payments and duplicate payments and can be configured to handle tips and partial payments. 8 | 9 | {% content-ref url="understanding-lightning-invoices.md" %} 10 | [understanding-lightning-invoices.md](understanding-lightning-invoices.md) 11 | {% endcontent-ref %} 12 | -------------------------------------------------------------------------------- /docs/lnd/release-notes/release-notes-0.14.3.md: -------------------------------------------------------------------------------- 1 | # Release Notes 2 | 3 | ## Bug fixes 4 | 5 | * The REST proxy (`grpc-gateway` library) had a fallback that redirected `POST` 6 | requests to another endpoint _with the same URI_ if no endpoint for `POST` was 7 | registered. [This default behavior was turned 8 | off](https://github.com/lightningnetwork/lnd/pull/6359), enabling strict 9 | HTTP method matching. 10 | 11 | * The [`SignOutputRaw` RPC now works properly in remote signing 12 | mode](https://github.com/lightningnetwork/lnd/pull/6341), even when 13 | only a public key or only a key locator is specified. This allows a Loop or 14 | Pool node to be connected to a remote signing node pair. 15 | A bug in the remote signer health check was also fixed that lead to too many 16 | open connections. 17 | 18 | # Contributors (Alphabetical Order) 19 | 20 | * Oliver Gugger 21 | -------------------------------------------------------------------------------- /lapps/guides/polar-lapps/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: >- 3 | This section will familiarize you with the Polar tool, and what the finished 4 | tutorial sample app will look like. It will end with the sample app 5 | disconnected from lnd, which you will then fix. 6 | --- 7 | 8 | # Use Polar to Build Your First LAPP 9 | 10 | {% content-ref url="local-cluster-setup-with-polar.md" %} 11 | [local-cluster-setup-with-polar.md](local-cluster-setup-with-polar.md) 12 | {% endcontent-ref %} 13 | 14 | {% content-ref url="run-the-completed-app.md" %} 15 | [run-the-completed-app.md](run-the-completed-app.md) 16 | {% endcontent-ref %} 17 | 18 | {% content-ref url="run-the-app-without-lnd.md" %} 19 | [run-the-app-without-lnd.md](run-the-app-without-lnd.md) 20 | {% endcontent-ref %} 21 | 22 | {% embed url="https://www.youtube.com/watch?v=6P0DZ74DmFA" %} 23 | Video: Build Bitcoin into Your App: Getting Started with the Lightning Network 24 | {% endembed %} 25 | -------------------------------------------------------------------------------- /lightning-network-tools/lnd/nat_traversal.md: -------------------------------------------------------------------------------- 1 | # NAT Traversal 2 | 3 | `lnd` has support for NAT traversal using a number of different techniques. At the time of writing this documentation, UPnP and NAT-PMP are supported. NAT traversal can be enabled through `lnd`'s `--nat` flag. 4 | 5 | ```text 6 | ⛰ lnd ... --nat 7 | ``` 8 | 9 | On startup, `lnd` will try the different techniques until one is found that's supported by your hardware. The underlying dependencies used for these techniques rely on using system-specific binaries in order to detect your gateway device's address. This is needed because we need to be able to reach the gateway device to determine if it supports the specific NAT traversal technique currently being tried. Because of this, due to uncommon setups, it is possible that these binaries are not found in your system. If this is case, `lnd` will exit stating such error. 10 | 11 | As a bonus, `lnd` spawns a background thread that automatically detects IP address changes and propagates the new address update to the rest of the network. This is especially beneficial for users who were provided dynamic IP addresses from their internet service provider. 12 | 13 | -------------------------------------------------------------------------------- /the-lightning-network/pathfinding/finding-routes-in-the-lightning-network.md: -------------------------------------------------------------------------------- 1 | # Finding routes in the Lightning Network 2 | 3 | In the Lightning Network, the sender decides on the payment route to the recipient. To do this, they need to know about all public nodes and channels, known as the graph. 4 | 5 | To compute the most efficient path through a network of nodes is a well studied problem in mathematics known as graph theory, or knot theory. 6 | 7 | Pathfinding algorithms typically treat the graph like a map, with each route between nodes having a unique cost, instead of a distance. 8 | 9 | In addition to two separate fee structures for each channel (base fee and fee rate), pathfinding in the Lightning Network is further complicated by the channels’ capacity and their liquidity. 10 | 11 | In practice, this means your Lightning node will create multiple possible paths to its destination, and try them successively. 12 | 13 | LND’s routing algorithm is largely based on Dijkstra's algorithm. LND also ranks nodes it has successfully sent payments through to improve its pathfinding. 14 | 15 | [Read more: Configure pathfinding in LND](../../lightning-network-tools/lnd/pathfinding.md) 16 | -------------------------------------------------------------------------------- /docs/lnd/nat_traversal.md: -------------------------------------------------------------------------------- 1 | # NAT Traversal 2 | 3 | `lnd` has support for NAT traversal using a number of different techniques. At 4 | the time of writing this documentation, UPnP and NAT-PMP are supported. NAT 5 | traversal can be enabled through `lnd`'s `--nat` flag. 6 | 7 | ```shell 8 | $ lnd ... --nat 9 | ``` 10 | 11 | On startup, `lnd` will try the different techniques until one is found that's 12 | supported by your hardware. The underlying dependencies used for these 13 | techniques rely on using system-specific binaries in order to detect your 14 | gateway device's address. This is needed because we need to be able to reach the 15 | gateway device to determine if it supports the specific NAT traversal technique 16 | currently being tried. Because of this, due to uncommon setups, it is possible 17 | that these binaries are not found in your system. If this is case, `lnd` will 18 | exit stating such error. 19 | 20 | As a bonus, `lnd` spawns a background thread that automatically detects IP 21 | address changes and propagates the new address update to the rest of the 22 | network. This is especially beneficial for users who were provided dynamic IP 23 | addresses from their internet service provider. 24 | -------------------------------------------------------------------------------- /the-lightning-network/pathfinding/README.md: -------------------------------------------------------------------------------- 1 | # Pathfinding 2 | 3 | In the Lightning Network, a payer decides on the route they want their payment to take. Ideally they find a direct and cheap path quickly, but, in some cases, they might have to attempt multiple available routes with varying fees. 4 | 5 | Nodes may employ different strategies for how to most efficiently find the most economical route to their destination quickly. In some implementations, nodes may outsource pathfinding to an external party. 6 | 7 | Routes are onion encrypted, meaning only the sender sees the full route. All nodes along the route will only see what channel a payment is coming from and going to. The recipient does not learn the origin of the payment, only of its final hop. 8 | 9 | {% content-ref url="finding-routes-in-the-lightning-network.md" %} 10 | [finding-routes-in-the-lightning-network.md](finding-routes-in-the-lightning-network.md) 11 | {% endcontent-ref %} 12 | 13 | {% content-ref url="channel-fees.md" %} 14 | [channel-fees.md](channel-fees.md) 15 | {% endcontent-ref %} 16 | 17 | {% content-ref url="multipath-payments-mpp.md" %} 18 | [multipath-payments-mpp.md](multipath-payments-mpp.md) 19 | {% endcontent-ref %} 20 | -------------------------------------------------------------------------------- /lightning-network-tools/aperture/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Aperture is an implementation of L402s as a reverse HTTP proxy. 3 | --- 4 | 5 | # Aperture 6 | 7 | Aperture is a reverse proxy that acts as a payment and authentication gateway for Lightning Network powered APIs. It can handle gRPC requests over HTTP/2 as well as REST over HTTP/1 and 2. 8 | 9 | Aperture receives incoming connections, verifies the validity of the [L402](../../the-lightning-network/l402/) and either forwards the request to the appropriate end point, or obtains a [Macaroon](../../the-lightning-network/l402/macaroons.md) and sends it together with a Lightning invoice and the HTTP status code 402 Payment Required. 10 | 11 | Aperture is currently used in production in Lightning [Loop](../loop/) and [Pool](../pool/). 12 | 13 | {% content-ref url="get-aperture.md" %} 14 | [get-aperture.md](get-aperture.md) 15 | {% endcontent-ref %} 16 | 17 | {% content-ref url="lnc-backend.md" %} 18 | [lnc-backend.md](lnc-backend.md) 19 | {% endcontent-ref %} 20 | 21 | {% content-ref url="mailbox.md" %} 22 | [mailbox.md](mailbox.md) 23 | {% endcontent-ref %} 24 | 25 | {% content-ref url="pricing.md" %} 26 | [pricing.md](pricing.md) 27 | {% endcontent-ref %} 28 | -------------------------------------------------------------------------------- /docs/lnd/release-notes/release-notes-0.16.3.md: -------------------------------------------------------------------------------- 1 | # Release Notes 2 | 3 | ## Mempool Optimizations 4 | 5 | * Optimized [mempool 6 | management](https://github.com/lightningnetwork/lnd/pull/7681) to lower the 7 | CPU usage. 8 | 9 | ## Misc 10 | 11 | * [Re-encrypt/regenerate](https://github.com/lightningnetwork/lnd/pull/7705) 12 | all macaroon DB root keys on `ChangePassword`/`GenerateNewRootKey` 13 | respectively. 14 | 15 | ## Channel Link Bug Fix 16 | 17 | * If we detect the remote link is inactive, [we'll now tear down the 18 | connection](https://github.com/lightningnetwork/lnd/pull/7711) in addition to 19 | stopping the link's statemachine. If we're persistently connected with the 20 | peer, then this'll force a reconnect, which may restart things and help avoid 21 | certain force close scenarios. 22 | 23 | 24 | ## Consistent Contract Resolution 25 | 26 | * If lnd decides to go to chain for an HTLC, it will now _always_ ensure the 27 | HTLC is fully swept on the outgoing link. Prior logic would avoid sweeping 28 | due to negative yield, but combined with other inputs, the HTLC will usually 29 | be positive yield. 30 | 31 | # Contributors (Alphabetical Order) 32 | 33 | * Elle Mouton 34 | * Olaoluwa Osuntokun 35 | * Yong Yu 36 | -------------------------------------------------------------------------------- /lapps/next-steps.md: -------------------------------------------------------------------------------- 1 | # Next Steps 2 | 3 | Hopefully, this tutorial has taught you the basics of how to integrate Lightning features into an existing application. You’ve only scratched the surface on what’s possible. 4 | 5 | To take the next step, you should familiarize yourself with [Lightning Service Authentication Tokens \(LSATs\)](https://lsat.tech). Future additions to the guide will focus heavily on these. Additional resources include our [Developer Slack](https://lightning.engineering/slack.html), [Github organization](https://github.com/lightninglabs), and API documentation for [`lnd`](https://api.lightning.community/), [`loop`](https://lightning.engineering/loopapi/), and [`pool`](https://lightning.engineering/poolapi/). 6 | 7 | If you’d like to extend this example app to add more features, here are some ideas to explore: 8 | 9 | * Use a hodl invoice to ensure that the payment isn’t settled until the upvote is completed on the backend successfully. 10 | * Use keysend to make the payment instead of creating an invoice first. 11 | * Add support for webln + Joule to avoid showing the payment request modal. 12 | * Only notify the sender and receiver of paid invoices, instead of all connected browsers 13 | * Prevent multiple upvotes being submitted for a single payment hash 14 | 15 | -------------------------------------------------------------------------------- /docs/lnd/release-notes/release-notes-0.14.1.md: -------------------------------------------------------------------------------- 1 | # Release Notes 2 | 3 | ## Bug Fixes 4 | 5 | * [Fixed an inaccurate log message during a compaction 6 | failure](https://github.com/lightningnetwork/lnd/pull/5961). 7 | 8 | * [Fixed a bug in the Tor controller that would cause the health check to fail 9 | if there was more than one hidden service 10 | configured](https://github.com/lightningnetwork/lnd/pull/6016). 11 | 12 | * [A bug has been fixed in channeldb that uses the return value without checking 13 | the returned error first](https://github.com/lightningnetwork/lnd/pull/6012). 14 | 15 | * [Fixes a bug that would cause lnd to be unable to start if anchors was 16 | disabled](https://github.com/lightningnetwork/lnd/pull/6007). 17 | 18 | * [Fixed a bug that would cause nodes with older channels to be unable to start 19 | up](https://github.com/lightningnetwork/lnd/pull/6003). 20 | 21 | * [Addresses an issue with explicit channel type negotiation that caused 22 | incompatibilities when opening channels with the latest versions of 23 | c-lightning and eclair](https://github.com/lightningnetwork/lnd/pull/6026). 24 | 25 | * [Ensure that if a user specifies explicit channel funding on the API level, 26 | then it can't be 27 | downgraded](https://github.com/lightningnetwork/lnd/pull/6027). 28 | 29 | # Contributors (Alphabetical Order) 30 | 31 | * Jamie Turley 32 | * nayuta-ueno 33 | * Olaoluwa Osuntokun 34 | * Oliver Gugger 35 | -------------------------------------------------------------------------------- /docs/lnd/release-notes/release-notes-template.md: -------------------------------------------------------------------------------- 1 | # Release Notes 2 | - [Bug Fixes](#bug-fixes) 3 | - [New Features](#new-features) 4 | - [Functional Enhancements](#functional-enhancements) 5 | - [RPC Additions](#rpc-additions) 6 | - [lncli Additions](#lncli-additions) 7 | - [Improvements](#improvements) 8 | - [Functional Updates](#functional-updates) 9 | - [RPC Updates](#rpc-updates) 10 | - [lncli Updates](#lncli-updates) 11 | - [Breaking Changes](#breaking-changes) 12 | - [Performance Improvements](#performance-improvements) 13 | - [Deprecations](#deprecations) 14 | - [Technical and Architectural Updates](#technical-and-architectural-updates) 15 | - [BOLT Spec Updates](#bolt-spec-updates) 16 | - [Testing](#testing) 17 | - [Database](#database) 18 | - [Code Health](#code-health) 19 | - [Tooling and Documentation](#tooling-and-documentation) 20 | 21 | # Bug Fixes 22 | 23 | # New Features 24 | 25 | ## Functional Enhancements 26 | 27 | ## RPC Additions 28 | 29 | ## lncli Additions 30 | 31 | # Improvements 32 | 33 | ## Functional Updates 34 | 35 | ## RPC Updates 36 | 37 | ## lncli Updates 38 | 39 | ## Code Health 40 | 41 | ## Breaking Changes 42 | 43 | ## Performance Improvements 44 | 45 | ## Deprecations 46 | 47 | # Technical and Architectural Updates 48 | 49 | ## BOLT Spec Updates 50 | 51 | ## Testing 52 | 53 | ## Database 54 | 55 | ## Code Health 56 | 57 | ## Tooling and Documentation 58 | 59 | # Contributors (Alphabetical Order) 60 | -------------------------------------------------------------------------------- /docs/lit/remote.md: -------------------------------------------------------------------------------- 1 | ## Run Lightning Terminal with a remote LND instance 2 | To connect Lightning Terminal to a remote LND instance first make sure your `lnd.conf` file contains the following additional configuration settings: 3 | ```text 4 | tlsextraip= 5 | rpclisten=0.0.0.0:10009 6 | rpcmiddleware.enable=true 7 | ``` 8 | 9 | Copy the following files that are located in your `~/.lnd/data/chain/bitcoin/mainnet` directory on your remote machine to `/some/folder/with/lnd/data/` on your local machine (where you’ll be running LiT): 10 | - tls.cert 11 | - admin.macaroon 12 | 13 | Create a `lit.conf` file. The default location LiT will look for the configuration file depends on your operating system: 14 | - MacOS: `~/Library/Application Support/Lit/lit.conf` 15 | - Linux: `~/.lit/lit.conf` 16 | - Windows: `~/AppData/Roaming/Lit/lit.conf` 17 | 18 | Alternatively you can specify a different location by passing `--lit-dir=~/.lit`. After creating `lit.conf` populate it with the following configuration settings: 19 | ```text 20 | remote.lnd.rpcserver=:10009 21 | remote.lnd.macaroonpath=/some/folder/with/lnd/data/admin.macaroon 22 | remote.lnd.tlscertpath=/some/folder/with/lnd/data/tls.cert 23 | ``` 24 | 25 | Run LiT: 26 | ```shell 27 | ⛰ ./litd --uipassword=UP48lm4VjqxmOxB9X9stry6VTKBRQI 28 | ``` 29 | 30 | Visit https://localhost:8443 to access LiT. 31 | 32 | For further information on configuring LiT in remote mode see [these instructions](config-lnd-remote.md). 33 | -------------------------------------------------------------------------------- /docs/taproot-assets/release-notes/release-notes-template.md: -------------------------------------------------------------------------------- 1 | # Release Notes 2 | - [Bug Fixes](#bug-fixes) 3 | - [New Features](#new-features) 4 | - [Functional Enhancements](#functional-enhancements) 5 | - [RPC Additions](#rpc-additions) 6 | - [tapcli Additions](#tapcli-additions) 7 | - [Improvements](#improvements) 8 | - [Functional Updates](#functional-updates) 9 | - [RPC Updates](#rpc-updates) 10 | - [tapcli Updates](#tapcli-updates) 11 | - [Config Changes](#config-changes) 12 | - [Breaking Changes](#breaking-changes) 13 | - [Performance Improvements](#performance-improvements) 14 | - [Deprecations](#deprecations) 15 | - [Technical and Architectural Updates](#technical-and-architectural-updates) 16 | - [BIP/bLIP Spec Updates](#bipblip-spec-updates) 17 | - [Testing](#testing) 18 | - [Database](#database) 19 | - [Code Health](#code-health) 20 | - [Tooling and Documentation](#tooling-and-documentation) 21 | 22 | # Bug Fixes 23 | 24 | # New Features 25 | 26 | ## Functional Enhancements 27 | 28 | ## RPC Additions 29 | 30 | ## tapcli Additions 31 | 32 | # Improvements 33 | 34 | ## Functional Updates 35 | 36 | ## RPC Updates 37 | 38 | ## tapcli Updates 39 | 40 | ## Config Changes 41 | 42 | ## Code Health 43 | 44 | ## Breaking Changes 45 | 46 | ## Performance Improvements 47 | 48 | ## Deprecations 49 | 50 | # Technical and Architectural Updates 51 | 52 | ## BIP/bLIP Spec Updates 53 | 54 | ## Testing 55 | 56 | ## Database 57 | 58 | ## Code Health 59 | 60 | ## Tooling and Documentation 61 | 62 | # Contributors (Alphabetical Order) 63 | -------------------------------------------------------------------------------- /docs/lnd/release-notes/release-notes-0.18.2.md: -------------------------------------------------------------------------------- 1 | # Release Notes 2 | - [Bug Fixes](#bug-fixes) 3 | - [New Features](#new-features) 4 | - [Functional Enhancements](#functional-enhancements) 5 | - [RPC Additions](#rpc-additions) 6 | - [lncli Additions](#lncli-additions) 7 | - [Improvements](#improvements) 8 | - [Functional Updates](#functional-updates) 9 | - [RPC Updates](#rpc-updates) 10 | - [lncli Updates](#lncli-updates) 11 | - [Breaking Changes](#breaking-changes) 12 | - [Performance Improvements](#performance-improvements) 13 | - [Technical and Architectural Updates](#technical-and-architectural-updates) 14 | - [BOLT Spec Updates](#bolt-spec-updates) 15 | - [Testing](#testing) 16 | - [Database](#database) 17 | - [Code Health](#code-health) 18 | - [Tooling and Documentation](#tooling-and-documentation) 19 | 20 | # Bug Fixes 21 | 22 | * [Fixed a bug](https://github.com/lightningnetwork/lnd/pull/8887) in error 23 | matching from publishing already confirmed transactions that can cause lnd 24 | fail to startup if `btcd` with an older version (pre-`v0.24.2`) is used. 25 | 26 | # New Features 27 | ## Functional Enhancements 28 | ## RPC Additions 29 | ## lncli Additions 30 | 31 | # Improvements 32 | ## Functional Updates 33 | ## RPC Updates 34 | ## lncli Updates 35 | ## Code Health 36 | ## Breaking Changes 37 | ## Performance Improvements 38 | 39 | # Technical and Architectural Updates 40 | ## BOLT Spec Updates 41 | ## Testing 42 | ## Database 43 | ## Code Health 44 | ## Tooling and Documentation 45 | 46 | # Contributors (Alphabetical Order) 47 | 48 | * Yong Yu 49 | -------------------------------------------------------------------------------- /docs/lnd/release-notes/release-notes-0.18.1.md: -------------------------------------------------------------------------------- 1 | # Release Notes 2 | - [Bug Fixes](#bug-fixes) 3 | - [New Features](#new-features) 4 | - [Functional Enhancements](#functional-enhancements) 5 | - [RPC Additions](#rpc-additions) 6 | - [lncli Additions](#lncli-additions) 7 | - [Improvements](#improvements) 8 | - [Functional Updates](#functional-updates) 9 | - [RPC Updates](#rpc-updates) 10 | - [lncli Updates](#lncli-updates) 11 | - [Breaking Changes](#breaking-changes) 12 | - [Performance Improvements](#performance-improvements) 13 | - [Technical and Architectural Updates](#technical-and-architectural-updates) 14 | - [BOLT Spec Updates](#bolt-spec-updates) 15 | - [Testing](#testing) 16 | - [Database](#database) 17 | - [Code Health](#code-health) 18 | - [Tooling and Documentation](#tooling-and-documentation) 19 | 20 | # Bug Fixes 21 | 22 | * [Fixed a bug](https://github.com/lightningnetwork/lnd/pull/8862) in error 23 | matching from publishing transactions that can cause the broadcast process to 24 | fail if `btcd` with an older version (pre-`v0.24.2`) is used. 25 | 26 | # New Features 27 | ## Functional Enhancements 28 | ## RPC Additions 29 | ## lncli Additions 30 | 31 | # Improvements 32 | ## Functional Updates 33 | ## RPC Updates 34 | ## lncli Updates 35 | ## Code Health 36 | ## Breaking Changes 37 | ## Performance Improvements 38 | 39 | # Technical and Architectural Updates 40 | ## BOLT Spec Updates 41 | 42 | ## Testing 43 | ## Database 44 | ## Code Health 45 | ## Tooling and Documentation 46 | 47 | # Contributors (Alphabetical Order) 48 | 49 | * Yyforyongyu 50 | -------------------------------------------------------------------------------- /docs/taproot-assets/release-notes/release-notes-0.6.1.md: -------------------------------------------------------------------------------- 1 | # Release Notes 2 | - [Bug Fixes](#bug-fixes) 3 | - [Improvements](#improvements) 4 | - [Performance Improvements](#performance-improvements) 5 | - [Technical and Architectural Updates](#technical-and-architectural-updates) 6 | - [Code Health](#code-health) 7 | 8 | # Bug Fixes 9 | 10 | - Database errors are now [sanitized before being 11 | returned](https://github.com/lightninglabs/taproot-assets/pull/1630). 12 | 13 | - [A potential deadlock in combination with `lnd`'s code hooks was fixed by 14 | making the message router 15 | non-blocking](https://github.com/lightninglabs/taproot-assets/pull/1652). 16 | 17 | - [A bug in the multi-RFQ send logic was fixed that could previously lead to 18 | a panic](https://github.com/lightninglabs/taproot-assets/pull/1627). 19 | 20 | - [An extra asset unit of tolerance was added to the invoice acceptor to fix 21 | MPP sharding 22 | issues](https://github.com/lightninglabs/taproot-assets/pull/1639). 23 | 24 | # Improvements 25 | 26 | ## Performance Improvements 27 | 28 | - A new cache for [asset meta information was 29 | added](https://github.com/lightninglabs/taproot-assets/pull/1650) that greatly 30 | improves the performance of the universe asset statistics call. 31 | 32 | # Technical and Architectural Updates 33 | 34 | ## Code Health 35 | 36 | - The compile time dependency version of `lnd` was bumped to `v0.19.2-beta` in 37 | [#1644](https://github.com/lightninglabs/taproot-assets/pull/1644). 38 | 39 | # Contributors (Alphabetical Order) 40 | 41 | - George Tsagkarelis 42 | - Oliver Gugger 43 | -------------------------------------------------------------------------------- /docs/lit/custom-path.md: -------------------------------------------------------------------------------- 1 | # Using a custom path for LiT 2 | 3 | If required LiT can be built to be accessed through a custom path (e.g. `/lit/`) 4 | in the browser instead of the default root path (`/`). 5 | 6 | To build LiT with a custom path, run the following command: 7 | 8 | ```shell 9 | ⛰ make PUBLIC_URL=/my-custom-path 10 | ``` 11 | 12 | **Make sure to not include a `/` at the end of the path.** To revert to the 13 | original, root path, set the variable to empty (`make PUBLIC_URL=`) or leave 14 | it out completely. 15 | 16 | ## Docker image built with a path prefix 17 | 18 | There is a docker image that's automatically built with the prefix `/lit` 19 | available on Docker Hub. Just append `-path-prefix` to any version tag (after 20 | `v0.5.2-alpha`). For example: 21 | 22 | ```shell 23 | # Default image. 24 | ⛰ docker pull lightninglabs/lightning-terminal:v0.5.3-alpha 25 | 26 | # Image with /lit path prefix. 27 | ⛰ docker pull lightninglabs/lightning-terminal:v0.5.3-alpha-path-prefix 28 | ``` 29 | 30 | ## Use with nginx reverse proxy 31 | 32 | There is [an example nginx](example-nginx.conf) config file that demonstrates 33 | how rewrite rules can be set up to run LiT under the `/lit` path prefix (and 34 | internally forward all `grpc-web` requests to the LiT proxy while still 35 | forwarding "native" gRPC requests to the `lnd` instance that's also running 36 | behind the nginx reverse proxy). 37 | 38 | The example reverse proxy can be run with: 39 | 40 | ```shell 41 | ⛰ cd docs 42 | ⛰ docker run --name lit-nginx \ 43 | -v $(pwd)/example-nginx.conf:/etc/nginx/nginx.conf:ro -p 8081:80 -d nginx 44 | ``` 45 | -------------------------------------------------------------------------------- /the-lightning-network/liquidity/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: >- 3 | Learn about liquidity, capacity and how to manage the capital in your 4 | Lightning node. 5 | --- 6 | 7 | # Liquidity 8 | 9 | In business, liquidity usually refers to the ability to meet short-term obligations. In markets, liquidity refers to the ability to trade assets at a given price. For instance, we might refer to Bitcoin as a liquid asset if we are able to buy and sell large quantities of it without significantly moving the market price. 10 | 11 | In the context of this guide, liquidity refers to the ability to move funds, which is an important concept for routing payments in the Lightning Network. To be able to route payments, and collect routing fees, you will want your funds to be as liquid as possible, or otherwise be compensated for the illiquidity. 12 | 13 | In these articles, we explore the concept of liquidity in the Lightning Network and describe ways to better manage it. 14 | 15 | {% content-ref url="understanding-liquidity.md" %} 16 | [understanding-liquidity.md](understanding-liquidity.md) 17 | {% endcontent-ref %} 18 | 19 | {% content-ref url="manage-liquidity.md" %} 20 | [manage-liquidity.md](manage-liquidity.md) 21 | {% endcontent-ref %} 22 | 23 | {% content-ref url="how-to-get-inbound-capacity-on-the-lightning-network.md" %} 24 | [how-to-get-inbound-capacity-on-the-lightning-network.md](how-to-get-inbound-capacity-on-the-lightning-network.md) 25 | {% endcontent-ref %} 26 | 27 | {% content-ref url="lightning-service-provider.md" %} 28 | [lightning-service-provider.md](lightning-service-provider.md) 29 | {% endcontent-ref %} 30 | -------------------------------------------------------------------------------- /lightning-network-tools/loop/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: The guide to Lightning Loop 3 | --- 4 | 5 | # Loop 6 | 7 | [Lightning Loop](https://lightning.engineering/posts/2020-02-05-loop-beta/) is a service that allows users to make a Lightning transaction to an onchain Bitcoin address (Loop Out), or send on-chain Bitcoin directly into a Lightning channel (Loop In). Loop can help manage channel liquidity, for example, by emptying out a channel and [acquiring inbound capacity](../../the-lightning-network/liquidity/how-to-get-inbound-capacity-on-the-lightning-network.md) (or refilling a depleted channel). 8 | 9 | Lightning Loop uses submarine swaps to transact non-custodially, meaning that Loop is trustless. Loop Out transactions are batched to save on transaction fees. 10 | 11 | Loop uses [L402s](../../the-lightning-network/l402/l402.md) for authentication. 12 | 13 | {% content-ref url="get-started.md" %} 14 | [get-started.md](get-started.md) 15 | {% endcontent-ref %} 16 | 17 | {% content-ref url="the-loop-cli.md" %} 18 | [the-loop-cli.md](the-loop-cli.md) 19 | {% endcontent-ref %} 20 | 21 | {% content-ref url="autoloop.md" %} 22 | [autoloop.md](autoloop.md) 23 | {% endcontent-ref %} 24 | 25 | {% content-ref url="static-loop-in-addresses.md" %} 26 | [static-loop-in-addresses.md](static-loop-in-addresses.md) 27 | {% endcontent-ref %} 28 | 29 | {% content-ref url="instant-loop-outs.md" %} 30 | [instant-loop-outs.md](instant-loop-outs.md) 31 | {% endcontent-ref %} 32 | 33 | {% content-ref url="peer-with-loop.md" %} 34 | [peer-with-loop.md](peer-with-loop.md) 35 | {% endcontent-ref %} 36 | 37 | {% embed url="https://lightning.engineering/api-docs/api/loop/" %} 38 | -------------------------------------------------------------------------------- /the-lightning-network/l402/implementations-and-links.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Projects using L402 today, code examples and further reading 3 | --- 4 | 5 | # Implementations and Links 6 | 7 | Not listed? [Fill out this form!](https://docs.google.com/forms/d/e/1FAIpQLSdT6kP3oUzd6xWytkDcflU9byHcp8nP9IyYntm\_6wa9Cw6qqg/viewform) 8 | 9 | ## L402 implementations and libraries 10 | 11 | * [​Aperture: A gRPC/HTTP authentication reverse proxy using L402​](https://github.com/lightninglabs/aperture) 12 | * [​lsat-js: A utility library for working with L402​](https://github.com/Tierion/lsat-js) 13 | * [​boltwall: Nodejs middleware-based authentication using L402](https://github.com/tierion/boltwall) 14 | * [now-boltwall: The Boltwall deployment toolkit](https://github.com/tierion/now-boltwall) 15 | * [Aperture Dynamic Pricing Demo](https://github.com/ellemouton/aperture-demo) 16 | 17 | ## Projects using L402 18 | 19 | * [​Lightning Pool](../../lightning-network-tools/pool/) 20 | * [Lightning Loop](../../lightning-network-tools/loop/) 21 | * [​L402 Playground​](https://lsat-playground.bucko.now.sh/) 22 | 23 | ## Further reading 24 | 25 | * [Tierion: Pseudonymous Authentication using Bitcoin Lightning Payments](https://medium.com/tierion/lsats-pseudonymous-authentication-using-bitcoin-lightning-payments-459e209b4b36) 26 | * ​[Macaroons: Cookies with Contextual Caveats](https://research.google/pubs/pub41892/)​\ 27 | the 2014 paper published on Google Scholar. 28 | * ​[HTTP/1.1 RFC, Section 6.5.2: 402 Payment Required](https://tools.ietf.org/html/rfc7231#section-6.5.2)​ 29 | -------------------------------------------------------------------------------- /the-lightning-network/taproot-assets/trustless-swap.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: >- 3 | Taproot Assets can be swapped for Bitcoin or other assets through swaps that 4 | do not require the two parties to trust each other. The swap completes 5 | atomically. 6 | --- 7 | 8 | # Taproot Assets Trustless Swap 9 | 10 | Atomic swaps are swaps that either complete in full, or reverse back to their initial stage. This removes the need for two swap parties to trust each other, also known as the “first mover problem.” 11 | 12 | Using Partially Signed Bitcoin Transactions (PSBTs), this swap can be performed in a single onchain transaction using minimal interaction between the swap partners without an external coordinator. 13 | 14 | 15 | 16 |

Diagram of trustless Taproot Assets swap

17 | 18 | The seller of the Taproot Asset creates a PSBT that proves their ownership over the asset while also allowing anybody who fulfills the PSBT to claim ownership over it (OP\_TRUE). 19 | 20 | The PSBT defines the Taproot Asset as an input, and the desired BTC amount as an output (22 million sats in the above example). To make the PSBT valid, somebody will need to add an input with at least 22 million sats. 21 | 22 | To effectively “buy” the Taproot Asset, they will also include an anchor output for the Taproot Asset and if needed, a change output for their BTC. 23 | 24 | As the anchor input cannot be double-spent on the Bitcoin blockchain, only the winner of this auction can claim the Taproot Asset as theirs, while all competing transactions become invalid once a bid is confirmed on the blockchain. 25 | -------------------------------------------------------------------------------- /docs/lit/example-nginx.conf: -------------------------------------------------------------------------------- 1 | events { 2 | worker_connections 1024; 3 | } 4 | 5 | http { 6 | # Redirect all incoming grpc-web requests to the LiT proxy. Everything else 7 | # goes directly to the internal lnd container. We use a temporary variable 8 | # here so we can rewrite it to the actual host again in the next map 9 | # directive. 10 | map $content_type $tmp_backend { 11 | "application/grpc-web+proto" "172.17.0.1:8443"; # LiT proxy. 12 | default "localhost:10009"; # main LND 13 | } 14 | 15 | # Streaming grpc-web requests can be identified by the 16 | # "Sec-WebSocket-Protocol: grpc-websockets" header field. So those requests 17 | # also need to go to the LiT proxy. 18 | map $http_sec_websocket_protocol $lnd_backend { 19 | "grpc-websockets" "172.17.0.1:8443"; # LiT proxy. 20 | default $tmp_backend; # Fall back to the value from the above map result. 21 | } 22 | 23 | # Make sure WebSockets are properly upgraded. 24 | map $http_sec_websocket_protocol $lnd_connection { 25 | "grpc-websockets" "upgrade"; 26 | default $http_connection; 27 | } 28 | 29 | server { 30 | listen 80; 31 | server_name localhost; 32 | 33 | proxy_set_header Upgrade $http_upgrade; 34 | proxy_set_header Origin https://$lnd_backend; 35 | proxy_set_header Connection $lnd_connection; 36 | 37 | location /lit { 38 | # This needs a slash at the end! 39 | proxy_pass https://172.17.0.1:8443/; 40 | } 41 | 42 | location ~* ^/(ln|loop|pool|lit)rpc\. { 43 | # This cannot have a slash at the end! 44 | proxy_pass https://$lnd_backend; 45 | } 46 | } 47 | } 48 | -------------------------------------------------------------------------------- /docs/lnd/release-notes/release-notes-0.15.3.md: -------------------------------------------------------------------------------- 1 | # Release Notes 2 | 3 | ## RPC/REST Server 4 | 5 | - A `POST` URL mapping [was added to the REST version of the `QueryRoutes` call 6 | (`POST /v1/graph/routes`)](https://github.com/lightningnetwork/lnd/pull/6926) 7 | to make it possible to specify `route_hints` over REST. 8 | 9 | ## Bug Fixes 10 | 11 | * [A bug has been fixed where the responder of a zero-conf channel could forget 12 | about the channel after a hard-coded 2016 blocks.](https://github.com/lightningnetwork/lnd/pull/6998) 13 | 14 | * [A bug where LND wouldn't send a ChannelUpdate during a channel open has 15 | been fixed.](https://github.com/lightningnetwork/lnd/pull/6892) 16 | 17 | * [A bug has been fixed that caused fee estimation to be incorrect for taproot 18 | inputs when using the `SendOutputs` call.](https://github.com/lightningnetwork/lnd/pull/6941) 19 | 20 | 21 | * [A bug has been fixed that could cause lnd to underpay for co-op close 22 | transaction when or both of the outputs used a P2TR 23 | addresss.](https://github.com/lightningnetwork/lnd/pull/6957) 24 | 25 | 26 | ## Taproot 27 | 28 | * [Add `p2tr` address type to account 29 | import](https://github.com/lightningnetwork/lnd/pull/6966). 30 | 31 | **NOTE** for users running a remote signing setup: A manual account import is 32 | necessary when upgrading from `lnd v0.14.x-beta` to `lnd v0.15.x-beta`, see [the 33 | remote signing documentation for more 34 | details](../remote-signing.md#migrating-a-remote-signing-setup-from-014x-to-015x). 35 | 36 | ## Performance improvements 37 | 38 | * [Refactor hop hint selection 39 | algorithm](https://github.com/lightningnetwork/lnd/pull/6914) 40 | 41 | # Contributors (Alphabetical Order) 42 | 43 | * Eugene Siegel 44 | * Jordi Montes 45 | * Oliver Gugger 46 | -------------------------------------------------------------------------------- /the-lightning-network/pathfinding/multipath-payments-mpp.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Splitting a payment into smaller parts and route each part separately. 3 | --- 4 | 5 | # Multipath Payments \(MPP\) 6 | 7 | `lnd` v0.10 introduced multi-path payments to the Lightning Network. The payments in prior examples succeeded with exactly one successful HTLC. However, if a sender has enough liquidity in total to fulfill a payment, but split across multiple channels such that no single channel has the required liquidity, no single HTLC can succeed. 8 | 9 | ![Example multi-path payment](https://lightning.engineering/static/d02b076fcf61c80bef6b0be8a60f47ba/4fc58/2020-05-06-mpp-outbound.png) 10 | 11 | A multi-path payment \(MPP\) can solve this problem by sending the payment in two parts. The first payment part consumes 20k sats in one channel and the second part uses 10k sats in the other channel. The highest payment amount is now defined by the sum of all channel balances rather than the maximum. 12 | 13 | When the recipient receives the first part, they won’t immediately settle the HTLC. Instead the HTLC is accepted and held, similar to how [hodl invoice](https://lightningwiki.net/index.php/HODL_Invoice) payments are accepted. They could settle because the preimage is known, but that wouldn’t be a rational thing to do. Settling right away would return the proof of payment to the sender while the full amount may never arrive. With the proof of payment, the sender could claim that the payment was made in full. Because all parts use the same payment hash, another possibility that may be even worse is that an intermediate node uses the now public preimage to settle the second HTLC without forwarding at all. So the recipient waits for the second HTLC to arrive. They then conclude that the full amount has arrived and will at that point settle both HTLCs. 14 | 15 | -------------------------------------------------------------------------------- /lightning-network-tools/taproot-assets/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Learn how to install Taproot Assets, mint and transfer assets. 3 | --- 4 | 5 | # Taproot Assets 6 | 7 | The Taproot Assets Daemon `tapd` implements the [Taproot Assets protocol](../../the-lightning-network/taproot-assets/taproot-assets-protocol.md) (formerly Taro) for issuing assets on the Bitcoin blockchain. Taproot Assets leverages Taproot transactions to commit to newly created assets and their transfers in an efficient and scalable manner. Multiple assets can be created and transferred in a single bitcoin UTXO, while witness data is transacted and kept off-chain. 8 | 9 | {% content-ref url="get-tapd.md" %} 10 | [get-tapd.md](get-tapd.md) 11 | {% endcontent-ref %} 12 | 13 | {% content-ref url="first-steps.md" %} 14 | [first-steps.md](first-steps.md) 15 | {% endcontent-ref %} 16 | 17 | {% content-ref url="taproot-assets-channels.md" %} 18 | [taproot-assets-channels.md](taproot-assets-channels.md) 19 | {% endcontent-ref %} 20 | 21 | {% content-ref url="decimal-display.md" %} 22 | [decimal-display.md](decimal-display.md) 23 | {% endcontent-ref %} 24 | 25 | {% content-ref url="rfq.md" %} 26 | [rfq.md](rfq.md) 27 | {% endcontent-ref %} 28 | 29 | {% content-ref url="collectibles.md" %} 30 | [collectibles.md](collectibles.md) 31 | {% endcontent-ref %} 32 | 33 | {% content-ref url="universes.md" %} 34 | [universes.md](universes.md) 35 | {% endcontent-ref %} 36 | 37 | {% content-ref url="asset-loop.md" %} 38 | [asset-loop.md](asset-loop.md) 39 | {% endcontent-ref %} 40 | 41 | {% content-ref url="debugging-tapd.md" %} 42 | [debugging-tapd.md](debugging-tapd.md) 43 | {% endcontent-ref %} 44 | 45 | {% content-ref url="polar.md" %} 46 | [polar.md](polar.md) 47 | {% endcontent-ref %} 48 | 49 | {% content-ref url="operational-safety-guidelines.md" %} 50 | [operational-safety-guidelines.md](operational-safety-guidelines.md) 51 | {% endcontent-ref %} 52 | -------------------------------------------------------------------------------- /lightning-network-tools/aperture/lnc-backend.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: >- 3 | Lightning Node Connect (LNC) lets you connect applications to your node by 4 | only passing on an eight word connection phrase, even if your node is behind a 5 | NAT or Tor. 6 | --- 7 | 8 | # LNC Backend 9 | 10 | From version 0.2 aperture supports connecting to its LND backend over LNC, allowing you to connect to your personal node without the need to open ports or configuring Tor or NAT. 11 | 12 | This configuration is different than configuring the [LNC Mailbox](mailbox.md), though both may be configured at the same time. 13 | 14 | ## Create an LNC pairing phrase 15 | 16 | [You can create a pairing phrase using the Lightning Terminal UI or the command line.](../lightning-terminal/connect.md) 17 | 18 | ## Configure Aperture 19 | 20 | To configure Aperture, you will need to edit or create the configuration file in `~/.aperture/aperture.yaml` 21 | 22 | The relevant section should look like this: 23 | 24 | ```yaml 25 | # The address which the proxy can be reached at. 26 | listenaddr: "localhost:8080" 27 | 28 | # Settings for the lnd node used to generate payment requests. All of these 29 | # options are required. 30 | authenticator: 31 | passphrase: "your pairing phrase" 32 | mailboxaddress: "mailbox.terminal.lightning.today:443" 33 | network: "mainnet" 34 | devserver: false 35 | 36 | # The selected database backend. The current default backend is "sqlite". 37 | # Aperture also has support for postgres and etcd. 38 | dbbackend: "sqlite" 39 | ``` 40 | 41 | At the time of writing, Aperture over LNC only works with the default database backend sqlite. 42 | 43 | ## Run Aperture 44 | 45 | You should be able to run aperture with `aperture`. 46 | -------------------------------------------------------------------------------- /docs/lit/troubleshooting.md: -------------------------------------------------------------------------------- 1 | ## Troubleshooting 2 | 3 | If you have trouble running your node, please first check the logs for warnings or errors. 4 | If there are errors relating to one of the embedded servers, then you should open an issue 5 | in their respective GitHub repos ([lnd](https://github.com/lightningnetwork/lnd/issues), 6 | [loop](https://github.com/lightninglabs/loop/issues), 7 | [pool](https://github.com/lightninglabs/pool/issues), 8 | [faraday](https://github.com/lightninglabs/faraday/issues). If the issue is related to the 9 | web app, then you should open an 10 | [issue](https://github.com/lightninglabs/lightning-terminal/issues) here in this repo. 11 | 12 | ### Server 13 | 14 | Server-side logs are stored in the directory specified by `lnd.lnddir` in your 15 | configuration. Inside, there is a `logs` dir containing the log files in subdirectories. 16 | Be sure to set `lnd.debuglevel=debug` in your configuration to see the most verbose 17 | logging information. 18 | 19 | ### Browser 20 | 21 | Client-side logs are disabled by default in production builds. Logging can be turned on by 22 | adding a couple keys to your browser's `localStorage`. Simply run these two JS statements 23 | in you browser's DevTools console then refresh the page: 24 | 25 | ```javascript 26 | localStorage.setItem('debug', '*'); localStorage.setItem('debug-level', 'debug'); 27 | ``` 28 | 29 | The value for `debug` is a namespace filter which determines which portions of the app to 30 | display logs for. The namespaces currently used by the app are as follows: 31 | 32 | - `main`: logs general application messages 33 | - `action`: logs all actions that modify the internal application state 34 | - `grpc`: logs all GRPC API requests and responses 35 | 36 | Example filters: `main,action` will only log main and action messages. `*,-action` will 37 | log everything except action messages. 38 | 39 | The value for `debug-level` determines the verbosity of the logs. The value can be one of 40 | `debug`, `info`, `warn`, or `error`. 41 | -------------------------------------------------------------------------------- /lightning-network-tools/taproot-assets/debugging-tapd.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Help improve the Taproot Assets Daemon by submitting your logs and issues. 3 | --- 4 | 5 | # Debugging Tapd 6 | 7 | Taproot Assets is alpha software. You can help improve the software by providing feedback, submitting issues and making pull requests. 8 | 9 | This guide aims to help you debug issues you might encounter when running `litd` with `tapd` in integrated mode. 10 | 11 | ## Is Taproot Assets running? 12 | 13 | Taproot Assets runs as part of `litd`, and it may not be apparent when `tapd` fails to start as part of the wider bundle. You can always check which subsystems are enabled and running by calling: 14 | 15 | `litcli status` 16 | 17 | ## Logging 18 | 19 | The logs provide invaluable clues as to why a system might not be starting, or why a command fails to execute. In integrated mode, all logs are written to `lnd.log`, typically located in `~/.lnd/logs/bitcoin/mainnet/lnd.log` 20 | 21 | To adjust the debug level, you may run: 22 | 23 | `lncli debuglevel --level trace,SRVR=debug,PEER=info,BTCN=warn,GRPC=error` 24 | 25 | Alternatively, you can also add the following to your `lit.conf` to set the debugging level permanently: 26 | 27 | `lnd.debuglevel=trace,SRVR=debug,PEER=info,BTCN=warn,GRPC=error` 28 | 29 | You can use the following to increase the number of log files and their maximum size, allowing you to look further into the past in search for clues: 30 | 31 | `lnd.maxlogfilesize=100`\ 32 | `lnd.maxlogfiles=100` 33 | 34 | ## Profiling 35 | 36 | A go profile helps determine the state of a go program. You can enable profiling with at any port: 37 | 38 | `lnd.profile=9736` 39 | 40 | You can then call the profile with: 41 | 42 | `curl http://localhost:9736/debug/pprof/goroutine?debug=2 > goprofile.txt` 43 | 44 | ## Filing issues 45 | 46 | All issues may be filed on the project’s Github repository. Please be as clear as possible, and include logs and go profile. 47 | 48 | {% embed url="https://github.com/lightninglabs/taproot-assets/issues" %} 49 | -------------------------------------------------------------------------------- /docs/lnd/release-notes/release-notes-0.17.3.md: -------------------------------------------------------------------------------- 1 | # Release Notes 2 | - [Bug Fixes](#bug-fixes) 3 | - [New Features](#new-features) 4 | - [Functional Enhancements](#functional-enhancements) 5 | - [RPC Additions](#rpc-additions) 6 | - [lncli Additions](#lncli-additions) 7 | - [Improvements](#improvements) 8 | - [Functional Updates](#functional-updates) 9 | - [RPC Updates](#rpc-updates) 10 | - [lncli Updates](#lncli-updates) 11 | - [Breaking Changes](#breaking-changes) 12 | - [Performance Improvements](#performance-improvements) 13 | - [Technical and Architectural Updates](#technical-and-architectural-updates) 14 | - [BOLT Spec Updates](#bolt-spec-updates) 15 | - [Testing](#testing) 16 | - [Database](#database) 17 | - [Code Health](#code-health) 18 | - [Tooling and Documentation](#tooling-and-documentation) 19 | 20 | # Bug Fixes 21 | 22 | * [Replaced](https://github.com/lightningnetwork/lnd/pull/8224) 23 | `musig2Sessions` with a `SyncMap` used in `input` package to avoid concurrent 24 | write to this map. 25 | 26 | * [Fixed](https://github.com/lightningnetwork/lnd/pull/8220) a loop variable 27 | issue which may affect programs built using go `v1.20` and below. 28 | 29 | * [An issue where LND would hang on shutdown has been fixed.](https://github.com/lightningnetwork/lnd/pull/8151) 30 | 31 | # New Features 32 | ## Functional Enhancements 33 | ## RPC Additions 34 | ## lncli Additions 35 | 36 | # Improvements 37 | ## Functional Updates 38 | ## RPC Updates 39 | ## lncli Updates 40 | ## Code Health 41 | ## Breaking Changes 42 | ## Performance Improvements 43 | 44 | * [Optimized](https://github.com/lightningnetwork/lnd/pull/8232) the memoray 45 | usage of `btcwallet`'s mempool. Users would need to use `bitcoind v25.0.0` 46 | and above to take the advantage of this optimization. 47 | 48 | # Technical and Architectural Updates 49 | ## BOLT Spec Updates 50 | ## Testing 51 | ## Database 52 | ## Code Health 53 | ## Tooling and Documentation 54 | 55 | # Contributors (Alphabetical Order) 56 | * Eugene Siegel 57 | * Yong Yu 58 | -------------------------------------------------------------------------------- /docs/lnd/fuzz.md: -------------------------------------------------------------------------------- 1 | # Fuzzing LND # 2 | 3 | The following runs all fuzz tests on default settings: 4 | ```shell 5 | $ make fuzz 6 | ``` 7 | The following runs all fuzz tests inside the lnwire package, each for a total of 1 minute, using 4 procs. 8 | It is recommended that processes be set to the number of processor cores in the system: 9 | ```shell 10 | $ make fuzz pkg=lnwire fuzztime=1m parallel=4 11 | ``` 12 | Alternatively, individual fuzz tests can be run manually by setting the working directory to the location of the .go file holding the fuzz tests. 13 | The go test command can only test one fuzz test at a time: 14 | ```shell 15 | $ cd lnwire 16 | $ go test -fuzz=FuzzAcceptChannel -fuzztime=1m -parallel=4 17 | ``` 18 | The following can be used to show all fuzz tests in the working directory: 19 | ```shell 20 | $ cd lnwire 21 | $ go test -list=Fuzz.* 22 | ``` 23 | 24 | Fuzz tests can be run as normal tests, which only runs the seed corpus: 25 | ```shell 26 | $ cd lnwire 27 | $ go test -run=FuzzAcceptChannel -parallel=4 28 | ``` 29 | The generated corpus values can be found in the $(go env GOCACHE)/fuzz directory. 30 | ## Options ## 31 | Several parameters can be appended to the end of the make commands to tune the build process or the way the fuzzer runs. 32 | - `fuzztime` specifies how long each fuzz test runs for, corresponding to the `go test -fuzztime` option. The default is 30s. 33 | - `parallel` specifies the number of parallel processes to use while running the harnesses, corresponding to the `go test -parallel` option. 34 | - `pkg` specifies the `lnd` packages to build or fuzz. The default is to build and run all available packages (`brontide lnwire watchtower/wtwire zpay32`). This can be changed to build/run against individual packages. 35 | 36 | ## Corpus ## 37 | Fuzzing generally works best with a corpus that is of minimal size while achieving the maximum coverage. 38 | 39 | ## Disclosure ## 40 | If you find any crashers that affect LND security, please disclose with the information found [here](https://github.com/lightningnetwork/lnd/#security). 41 | -------------------------------------------------------------------------------- /lightning-network-tools/taproot-assets/collectibles.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: >- 3 | Learn how to mint your own collectibles, as well as collections of 4 | collectibles. 5 | --- 6 | 7 | # Collectibles 8 | 9 | In addition to fungible, "normal" assets, Taproot Assets supports the creation and transfer of collectible, non-fungible assets. 10 | 11 | A digital collectible can take on any form. The collectible itself may be referenced in the form of a hash or text, or may be directly embedded in the meta data itself. When minting a collectible, you have the option to pass any kind of data via `--meta_bytes`, such as text, images encoded data of any form or even a binary blob. Alternatively, any file can be passed to tapd with the `--meta_file_path` flag. 12 | 13 | Meta data is limited to 1MB per asset. 14 | 15 | Example: 16 | 17 | `tapcli assets mint --type collectible --name theone --meta_bytes "One of a kind" --supply 1` 18 | 19 | `tapcli assets mint finalize` 20 | 21 | ## Collections 22 | 23 | Multiple collectibles can be grouped together into a collection. Each asset has its own asset ID, while the collection itself can be identified by its group key. To create such a collection, the `--new_group_emission` flag has to be set, and each subsequent collectible has to set the `--grouped_asset` flag as well as reference the first collectible by its name. Multiple collectibles can be minted in a batch. 24 | 25 | `tapcli assets mint --type collectible --name member001 --meta_bytes 546170726f6f742041737365747320436c7562204d656d62657220303031 --supply 1 --new_group_emission` 26 | 27 | `tapcli assets mint --type collectible --name member002 --meta_bytes 546170726f6f742041737365747320436c7562204d656d62657220303032 --grouped_asset --supply 1 --group_anchor member001` 28 | 29 | `tapcli assets mint --type collectible --name member003 --meta_bytes 546170726f6f742041737365747320436c7562204d656d62657220303033 --grouped_asset --supply 1 --group_anchor member001` 30 | 31 | `tapcli assets mint finalize` 32 | 33 | At this point there is no option to "close" a batch or limit future emissions of that group. 34 | -------------------------------------------------------------------------------- /lightning-network-tools/aperture/get-aperture.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Aperture is an implementation of L402s as a reverse HTTP proxy. 3 | --- 4 | 5 | # Get Aperture 6 | 7 | Aperture is a reverse proxy that acts as a payment and authentication gateway for Lightning Network powered APIs. It can handle gRPC requests over HTTP/2 as well as REST over HTTP/1 and 2. 8 | 9 | Aperture receives incoming connections, verifies the validity of the [L402](../../the-lightning-network/l402/) and either forwards the request to the appropriate end point, or obtains a [Macaroon](../../the-lightning-network/l402/macaroons.md) and sends it together with a Lightning invoice and the HTTP status code 402 Payment Required. 10 | 11 | Aperture is currently used in production in Lightning [Loop](../loop/) and [Pool](../pool/). 12 | 13 | ## Install Aperture 14 | 15 | Requirements: go 1.19 or later 16 | 17 | `git clone https://github.com/lightninglabs/aperture.git`\ 18 | `cd aperture`\ 19 | `make install` 20 | 21 | ## Configure Aperture 22 | 23 | `mkdir ~/.aperture`\ 24 | `cp sample-conf.yaml ~/.aperture/aperture.yaml` 25 | 26 | By default Aperture uses port 8081. This port needs to be reachable from the outside. 27 | 28 | Aperture will create a TLS key and self-signed certificate. To run Aperture in production, it will need a valid TLS certificate for the domain it is running on. 29 | 30 | ## Run Aperture 31 | 32 | To run Aperture, simply run the following command. 33 | 34 | `aperture` 35 | 36 | ## L402 demo 37 | 38 | A demonstration of L402 can be found at [https://lsat-playground-bucko.vercel.app/](https://lsat-playground-bucko.vercel.app/) ([Testnet version here](https://testnet-lsat-playground.vercel.app/)) 39 | 40 | Here you can go through the process of minting a Macaroon, turning it into an L402, restricting and validating it as well as see code snippets. 41 | 42 | [See how the client interceptor is coded in Aperture](https://github.com/lightninglabs/aperture/blob/master/l402/client_interceptor.go) 43 | 44 | {% embed url="https://www.youtube.com/watch?t=22815s&v=LlTCipHKTCs" %} 45 | Watch: Using Aperture 46 | {% endembed %} 47 | -------------------------------------------------------------------------------- /lightning-network-tools/lightning-terminal/recommended-channels.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Learn what Recommended Channels are and how you can make best use of them. 3 | --- 4 | 5 | # Recommended Channels 6 | 7 | In order to get started with a Lightning Node, node operators first need to open channels to peers. To decide what peers to open towards, node operators often do [a lot of research](../../the-lightning-network/liquidity/understanding-liquidity.md) and diligence on the other node. Within the Terminal experience, there is also the option to open “recommended channels.” What are recommended channels? 8 | 9 | ![An example of Recommended Channels](../../.gitbook/assets/RecommendedChannels.png) 10 | 11 | Let’s start with peers. A stable peer is one that passes five of six health checks, lacking only the health check around the number of good peers to be considered a “6/6 health check” routing node. It is these stable peers that are included as Recommended Channel options within the Terminal experience. With additional channel opens in their direction, these peers can improve their health check status thus improving the health of the network overall. Therefore, recommended channels give you a list of stable peers that if you open a channel towards them will become stronger routing nodes within the network graph. 12 | 13 | This list of recommended channels will be visible in Terminal either: if you have no channels, as the whole channels card or underneath your existing channels. If you are presented with this list and also pass five of six health checks, your node is likely included in the list of peers suggested to other Terminal users. 14 | 15 | Opening a channel to such a peer is not only of benefit to your node and the new peer, but to the network as a whole, as it connects nodes on the outer edges, decentralizes routing and allocates capital where it is more likely needed. 16 | 17 | As with other peers, opening a recommended channel does not guarantee to pass the additional health check. It is also important to capitalize the channel sufficiently and to maintain sufficient incoming and outgoing capacity. 18 | -------------------------------------------------------------------------------- /docs/pool/channel_leases.md: -------------------------------------------------------------------------------- 1 | # Channel Leases 2 | 3 | ## Overview 4 | 5 | Once an order has been matched in an auction, the `pool auction leases` command can be used to examine your current set of purchased/sold channel leases. An example output looks something like the following: 6 | 7 | ```text 8 | 🏔 pool auction leases 9 | { 10 | "leases": [ 11 | { 12 | "channel_point": "78cc6879c1dc1c00f22b29a06458f1335ed0fdb7d05c01b9077e3155e697bbb9:2", 13 | "channel_amt_sat": 5000000, 14 | "channel_duration_blocks": 144, 15 | "premium_sat": 40000, 16 | "execution_fee_sat": 5001, 17 | "chain_fee_sat": 165, 18 | "order_nonce": "eb972cd21cf1651e251c8b07d69e89c47294bae104fbdc9da26edf9aee335c9a", 19 | "purchased": false 20 | } 21 | ], 22 | "total_amt_earned_sat": 40000, 23 | "total_amt_paid_sat": 5166 24 | } 25 | ``` 26 | 27 | Here we can see I sold a channel for 40k satoshis, and ended up paying 5k satoshis in chain and execution fees, netting a cool 35k satoshi yield. Within the actual auction, these numbers will vary based on the chain fee rate, the market prices, and also the execution fees. Users can constraint how much chain fees they'll pay by setting the `--max_batch_fee_rate` argument when submitting orders. 28 | 29 | ## Service Level Lifetime Enforcement 30 | 31 | In the alpha version of Pool, _script level enforcement_ isn't yet implemented. Script level enforcement would lock the maker's funds in the channel for the lease period. This ensures that they can't just collect the premium \(before coupon channels\) and close out the channel instantly. With script enforcement, they would be able to close the channel \(force close it\), but their funds would be unavailable until the maturity period has passed. 32 | 33 | Instead, we've implemented a feature in `lnd` to prevent channels from being _cooperatively closed_ by the maker until the expiry height \(what we call the `thaw_height`\). 34 | 35 | -------------------------------------------------------------------------------- /the-lightning-network/liquidity/lightning-service-provider.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: >- 3 | A Lightning Service Provider (LSP) deploys liquidity in the Lightning Network 4 | on behalf of others. 5 | --- 6 | 7 | # Lightning Service Provider 8 | 9 | A Lightning Service Provider (LSP) is an entity providing liquidity services on the Lightning Network on behalf of others. Channels in the Lightning Network are naturally constrained by their size, and capacity is further limited by local and remote balances. 10 | 11 | Lightning Service Providers typically help manage a user’s liquidity by performing one of two tasks 12 | 13 | * Swapping on-chain funds for off-chain funds or vice versa 14 | * Opening channels to increase a user’s [inbound capacity](how-to-get-inbound-capacity-on-the-lightning-network.md) or improve their [position in the graph](../pathfinding/finding-routes-in-the-lightning-network.md) 15 | 16 | Ideally, a Lightning Service Provider interacts with their clients in a purely non-custodial way. Swaps can be constructed as [Submarine Swaps](../multihop-payments/understanding-submarine-swaps.md) to guarantee that the service provider cannot abscond with funds at any time. When opening channels to peers, the LSP retains custody over their side of the channel and earns routing fees as they forward payments. 17 | 18 | Today, LSPs are most commonly known for providing liquidity to users of non-custodial wallets in the form of channels. This lets users immediately receive Lightning payments to their wallets without requiring active channel management or ownership over a UTXO. The LSP typically charges an upfront payment to compensate for mining fees and capital costs. 19 | 20 | These fees are often deducted directly from an incoming payment, but could also be charged upfront. It may be difficult for the LSP to assess how large a new channel to a user should be. 21 | 22 | An LSP may borrow bitcoin for this task, or deploy their own funds. It is also possible for an LSP to buy such channels on the open market, such as [Lightning Pool](../../lightning-network-tools/pool/) using sidecar channels, instead of opening them themselves. 23 | -------------------------------------------------------------------------------- /the-lightning-network/multihop-payments/instant-submarine-swaps.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: >- 3 | Instant submarine swaps are a form of atomic swap that makes onchain funds 4 | immediately available without needing to wait for block confirmations. 5 | --- 6 | 7 | # Instant Submarine Swaps 8 | 9 | A submarine swap is a type of atomic swap that describes the trustless interchange of onchain and offchain funds. The swap either completes in full, or fails. 10 | 11 | [Read more: Understanding submarine swaps](understanding-submarine-swaps.md) 12 | 13 | Traditional submarine swaps, such as those used by Loop, require the recipient of the onchain funds to wait for block confirmations before they can take control over their funds. 14 | 15 | Instant submarine swaps are more chain efficient and make funds available immediately once the Lightning payment has been completed and the preimage obtained. This can be still be accomplished without introducing trust into the procedure. 16 | 17 | This is done by making a reservation ahead of time of the desired amount to be swapped. This gives the submarine swap provider more time to batch reservations and get the transaction confirmed at a lower fee. Each reservation is an output similar to an ordinary submarine HTLC. 18 | 19 | The provider is able to retrieve their funds after a certain timeout has been reached, limiting their risk to the costs of the onchain transaction and the opportunity costs of funds locked. 20 | 21 | The user is able to retrieve their funds using the preimage, which they can obtain through an invoice created at the time of the Instant Loop Out. 22 | 23 | To make the process more efficient, the output of the reservation can be made spendable with a two-of-two MuSig2 schnorr signature. Both the provider and the user originally hold their own unique keys. Upon successful completion of the swap, the provider can co-sign transactions initiated by the user, allowing the user to spend their funds without publicly revealing the preimage or paying more than the minimal onchain fees. 24 | 25 | [Learn: How to make Instant Loop Outs](../../lightning-network-tools/loop/instant-loop-outs.md) 26 | -------------------------------------------------------------------------------- /lightning-network-tools/lnd/enable-neutrino-mode-in-bitcoin-core.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: >- 3 | Prepare one or multiple existing Bitcoin Core nodes to work with LND's 4 | Neutrino mode. 5 | --- 6 | 7 | # Enable ‘Neutrino mode’ in Bitcoin Core 8 | 9 | With the inclusion of [BIP157](https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki), starting from [Bitcoin Core 0.21.0](https://bitcoincore.org/en/releases/0.21.0/), we are able to enable our Bitcoin node to serve block data to remote LND nodes. 10 | 11 | This can be useful if we are already running a fully synced Bitcoin node somewhere and want to use it for one or multiple remote instances of LND. If we have the additional bandwidth and storage available, we might also want to make our existing Bitcoin node available to the public as a free service. 12 | 13 | Easily available public Neutrino instances help the network grow more robust and remove bottlenecks. Such services are a prerequisite to light clients, which do not have a copy of the Bitcoin Blockchain available locally. 14 | 15 | ## Amend your bitcoin.conf 16 | 17 | In your `bitcoin.conf` file, add the following paramenters: 18 | 19 | `blockfilterindex=1`\ 20 | `peerblockfilters=1` 21 | 22 | Once you restart your node, it will resync the Blockchain and build the `blockfilterindex`. This may take a while depending on your node’s available memory and computing power. 23 | 24 | As soon as Bitcoin Core is running, it will now advertise itself to the network if you have set this in your configuration. To disable discovery, you may set `discover=0` in your `bitcoin.conf`. 25 | 26 | ## Connect from your LND 27 | 28 | When starting lnd with neutrino, you will need to set the following settings in your `lnd.conf`, or use the corresponding flags at startup: 29 | 30 | `bitcoin.node=neutrino`\ 31 | `neutrino.addpeer=:`\ 32 | \ 33 | You may also use multiple options of `neutrino.addpeer=` to ensure maximum uptime. If you instead prefer to connect exclusively to a single node, you may make use of the `neutrino.connect` instead. 34 | 35 | `bitcoin.node=neutrino`\ 36 | `neutrino.connect=:` 37 | -------------------------------------------------------------------------------- /lightning-network-tools/lightning-terminal/connect.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Run litd either in integrated mode or on a separate machine. 3 | --- 4 | 5 | # Connect to Terminal 6 | 7 | If `litd` is already running on your machine, follow this guide. For installation instructions, [follow our guide](get-lit.md). If you are running a bundle such as Umbrel or Start9, Terminal may already be installed on your machine. 8 | 9 | Once you have navigated to your local installation of Terminal, click on "Connect to Terminal" to be taken directly to Terminal on the web. Alternatively you may scan the QR code with a smart phone or tablet to open a new session on another device. 10 | 11 | You can inspect and revoke all existing sessions under "Lightning Node Connect." 12 | 13 |

Lightning Terminal, as seen when navigating to https://127.0.0.1:8443

14 | 15 | ## Run litd locally 16 | 17 | Once you are running `litd` on your machine, navigate to `http://127.0.0.1:8443` in your browser on the same machine to open Lightning Terminal. Not that your wallet needs to be unlocked with `lncli unlock` before you can access the user interface. If you are running `litd` on another machine, you may access it from there or continue with the CLI option below. 18 | 19 | ## Create a session using the command line 20 | 21 | If you cannot access the machine on which you are running `litd` via the browser or prefer to keep port `8443` closed, you may generate a new pairing phrase with `litcli`. 22 | 23 | `litcli sessions add --label="default" --type=admin` 24 | 25 | Now navigate to [https://terminal.lightning.engineering](https://terminal.lightning.engineering/) and click on 'Connect your Node.' 26 | 27 | You will be asked for your 10-word pairing phrase. Enter it and confirm. 28 | 29 | You need to choose a secure and unique password. We recommend to use a password manager. 30 | 31 | You're now connected to Lightning Terminal! Read more about [Recommended Channels](recommended-channels.md), [Health Checks](health-checks.md), and [how to open channels to the Lightning Network](opening-channels.md). 32 | -------------------------------------------------------------------------------- /lightning-network-tools/taproot-assets/tips-and-tricks.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: >- 3 | Taproot Assets on the Lightning Network allow you to pay any Lightning 4 | invoice, and get paid from any Lightning wallet. Consult this document when 5 | running into issues. 6 | --- 7 | 8 | # Tips and Tricks 9 | 10 | ## Incorrect payment details 11 | 12 | `FAILURE_REASON_INCORRECT_PAYMENT_DETAILS` 13 | 14 | When generating an invoice for Taproot Assets, the receiving node expects the payment to come through a channel that holds this specific asset. Such channels are not announced and cannot be found in the graph. 15 | 16 | Instead, they are added as hop hints to the invoice. Not every sender might honor these hop hints, and they may try to pay through any existing public channel instead, if they exist. When paying to the wrong channel, the sender will see the “incorrect payment details” error. 17 | 18 | They can instead try again or force the payment to go through the hop hint by passing the `--last_hop` when paying the invoice. 19 | 20 | ## No route found 21 | 22 | `FAILURE_REASON_NO_ROUTE` 23 | 24 | When a channel along the route is disabled or doesn’t have liquidity, the sender might see the “no route” error. It might make sense to check if your local channels are active and have enough capacity. It is important to check not only for sufficient Taproot Assets capacity, but also satoshi capacity, as every HTLC that passes through a Taproot Asset channel still requires some satoshis. 25 | 26 | A typical Taproot Asset channel has a capacity of 100,000 satoshis, of which 1,000 are unspendable on each side as the channel reserve. Each open HTLC requires a balance of 345 satoshis, so at least 2035 satoshis are required as inbound capacity to have three pending incoming HTLCs. The 345 satoshis do not change owners once the HTLC settles. 27 | 28 | ## Satoshi denomination 29 | 30 | At the LND level, all transactions remain denominated in satoshis. At this point, the output of many RPC commands such as `lncli listinvoices` or `lncli fwdinghistory` shows only satoshi amounts for Taproot Asset events. 31 | -------------------------------------------------------------------------------- /lightning-network-tools/pool/channel_leases.md: -------------------------------------------------------------------------------- 1 | # Channel Leases 2 | 3 | ## Overview 4 | 5 | Once an order has been matched in an auction, the `pool auction leases` command can be used to examine your current set of purchased/sold channel leases. An example output looks something like the following: 6 | 7 | ``` 8 | pool auction leases 9 | { 10 | "leases": [ 11 | { 12 | "channel_point": "78cc6879c1dc1c00f22b29a06458f1335ed0fdb7d05c01b9077e3155e697bbb9:2", 13 | "channel_amt_sat": 5000000, 14 | "channel_duration_blocks": 144, 15 | "premium_sat": 40000, 16 | "execution_fee_sat": 5001, 17 | "chain_fee_sat": 165, 18 | "order_nonce": "eb972cd21cf1651e251c8b07d69e89c47294bae104fbdc9da26edf9aee335c9a", 19 | "purchased": false 20 | } 21 | ], 22 | "total_amt_earned_sat": 40000, 23 | "total_amt_paid_sat": 5166 24 | } 25 | ``` 26 | 27 | Here we can see I sold a channel for 40k satoshis, and ended up paying 5k satoshis in chain and execution fees, netting a cool 35k satoshi yield. Within the actual auction, these numbers will vary based on the chain fee rate, the market prices, and also the execution fees. Users can constraint how much chain fees they'll pay by setting the `--max_batch_fee_rate` argument when submitting orders. 28 | 29 | ## Service Level Lifetime Enforcement 30 | 31 | In the alpha version of Pool, _script level enforcement_ isn't yet implemented. Script level enforcement would lock the maker's funds in the channel for the lease period. This ensures that they can't just collect the premium (before coupon channels) and close out the channel instantly. With script enforcement, they would be able to close the channel (force close it), but their funds would be unavailable until the maturity period has passed. 32 | 33 | Instead, we've implemented a feature in `lnd` to prevent channels from being _cooperatively closed_ by the maker until the expiry height (what we call the `thaw_height`). Additionally, if we detect a force close by the maker of that channel, then we'll ban them from the market for a set period of time. 34 | -------------------------------------------------------------------------------- /lightning-network-tools/loop/get-started.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Install Loopd from source or the binaries 3 | --- 4 | 5 | # Get Started 6 | 7 | ## Install Loop 8 | 9 | Loop comes bundled with [Lightning Terminal](../lightning-terminal/) (`litd`). If you are already running `litd`, you can access Loop through the command line or the [Lightning Terminal UI](../lightning-terminal/connect.md) and may skip the steps below. 10 | 11 | [Follow this guide to install Lightning Terminal](../lightning-terminal/get-lit.md) 12 | 13 | ## Installation 14 | 15 | To run Loop you need to be running LND from the[ binary releases](https://github.com/lightningnetwork/lnd/releases), or compile from source with the command make install `tags="signrpc walletrpc chainrpc invoicesrpc"` 16 | 17 | ### Run the Binary 18 | 19 | You can run Loop directly from the binary releases, [which you can find here](https://github.com/lightninglabs/loop/releases). 20 | 21 | ### Compile from source 22 | 23 | You can compile Loop from source. This requires Golang. Instructions for how to install Go can be found in the [LND installation guide](../lnd/run-lnd.md). 24 | 25 | `git clone https://github.com/lightninglabs/loop.git`\ 26 | `cd loop`\ 27 | `make && make install` 28 | 29 | ## Configuration 30 | 31 | By default, the `loopd.conf` is placed in `~/.loop/mainnet/` If you are starting `loopd` on another network (e.g. `loopd --network=signet`), the configuration file is expected in the relevant directory (e.g. `~/.loop/signet`). You may also pass a custom directory with the `--configfile=` flag. 32 | 33 | #### External Loopd 34 | 35 | You may run `loopd` on a separate machine and network as LND. You may have to first configure LND to listen on external IPs with `lnd.rpclisten=0.0.0.0:10009`, add your LND machine's IP address(es) to the TLS certificate with `tlsextraip=`, delete your existing `tls.key` and `tls.cert` and restart LND to regenerate the certificates. 36 | 37 | In your `loopd.conf`, define the LND host (`lnd.host=:10009`), copy the LND admin macaroon and TLS certificate over and specify their path with `lnd.macaroonpath=/path/to/admin.macaroon` and `lnd.tlspath=/path/to/tls.cert` 38 | -------------------------------------------------------------------------------- /docs/lnd/sqlite.md: -------------------------------------------------------------------------------- 1 | # SQLite support in LND 2 | 3 | With the introduction of the `kvdb` interface, LND can support multiple database 4 | backends. One of the supported backends is 5 | [sqlite](https://www.sqlite.org/index.html). This document describes how use 6 | LND with a sqlite backend. 7 | 8 | Note that for the time being, the sqlite backend option can only be set for 9 | _new_ nodes. Setting the option for an existing node will not migrate the data. 10 | 11 | ## Supported platforms and architectures 12 | 13 | Note that the sqlite backend is _not_ supported for Windows (386/ARM) or for 14 | Linux (PPC/MIPS) due to these platforms [not being supported by the sqlite 15 | driver library.]( 16 | https://pkg.go.dev/modernc.org/sqlite#hdr-Supported_platforms_and_architectures) 17 | 18 | ## Configuring LND for SQLite 19 | 20 | LND is configured for SQLite through the following configuration options: 21 | 22 | * `db.backend=sqlite` to select the SQLite backend. 23 | * `db.sqlite.timeout=...` to set the connection timeout. If not set, no 24 | timeout applies. 25 | * `db.sqlite.busytimeout=...` to set the maximum amount of time that a db call 26 | should wait if the db is currently locked. 27 | * `db.sqlite.pragmaoptions=...` to set a list of pragma options to be applied 28 | to the db connection. See the 29 | [sqlite documentation](https://www.sqlite.org/pragma.html) for more 30 | information on the available pragma options. 31 | 32 | ## Default pragma options 33 | 34 | Currently, the following pragma options are always set: 35 | 36 | ``` 37 | foreign_keys=on 38 | journal_mode=wal 39 | busy_timeout=5000 // Overried with the db.sqlite.busytimeout option. 40 | ``` 41 | 42 | The following pragma options are set by default but can be overridden using the 43 | `db.sqlite.pragmaoptions` option: 44 | 45 | ``` 46 | synchronous=full 47 | auto_vacuum=incremental 48 | fullfsync=true // Only meaningful on a Mac. 49 | ``` 50 | 51 | ## Auto-compaction 52 | 53 | To activate auto-compaction on startup, the `incremental_vacuum` pragma option 54 | should be used: 55 | ``` 56 | // Use N to restrict the maximum number of pages to be removed from the 57 | // freelist. 58 | db.sqlite.pragmaoptions=incremental_vacuum(N) 59 | 60 | // Omit N if the entire freelist should be cleared. 61 | db.sqlite.pragmaoptions=incremental_vacuum 62 | ``` 63 | 64 | Example as follows: 65 | ``` 66 | [db] 67 | db.backend=sqlite 68 | db.sqlite.timeout=0 69 | db.sqlite.busytimeout=10s 70 | db.sqlite.pragmaoptions=temp_store=memory 71 | db.sqlite.pragmaoptions=incremental_vacuum 72 | ``` 73 | -------------------------------------------------------------------------------- /lightning-network-tools/lnd/fuzz.md: -------------------------------------------------------------------------------- 1 | # Fuzzing LND 2 | 3 | The `fuzz` package is organized into subpackages which are named after the `lnd` package they test. Each subpackage has its own set of fuzz targets. 4 | 5 | ## Setup and Installation \#\# 6 | 7 | This section will cover setup and installation of the fuzzing binaries. 8 | 9 | * The following is a command to build all fuzzing harnesses: 10 | 11 | ```text 12 | ⛰ make fuzz-build 13 | ``` 14 | 15 | * This may take a while since this will create zip files associated with each fuzzing target. 16 | * The following is a command to run all fuzzing harnesses for 30 seconds: 17 | 18 | ```text 19 | ⛰ make fuzz-run 20 | ``` 21 | 22 | `go-fuzz` will print out log lines every couple of seconds. Example output: 23 | 24 | ```text 25 | 2017/09/19 17:44:23 workers: 8, corpus: 23 (3s ago), crashers: 1, restarts: 1/748, execs: 400690 (16694/sec), cover: 394, uptime: 24s 26 | ``` 27 | 28 | Corpus is the number of items in the corpus. `go-fuzz` may add valid inputs to the corpus in an attempt to gain more coverage. Crashers is the number of inputs resulting in a crash. The inputs, and their outputs are logged by default in: `fuzz///crashers`. `go-fuzz` also creates a `suppressions` directory of stacktraces to ignore so that it doesn't create duplicate stacktraces. Cover is a number representing edge coverage of the program being fuzzed. 29 | 30 | ## Options \#\# 31 | 32 | Several parameters can be appended to the end of the make commands to tune the build process or the way the fuzzer runs. 33 | 34 | * `run_time` specifies how long each fuzz harness runs for. The default is 30 seconds. 35 | * `timeout` specifies how long an individual testcase can run before raising an error. The default is 20 seconds. 36 | * `processes` specifies the number of parallel processes to use while running the harnesses. 37 | * `pkg` specifies the `lnd` packages to build or fuzz. The default is to build and run all available packages \(`brontide lnwire wtwire zpay32`\). This can be changed to build/run against individual packages. 38 | * `base_workdir` specifies the workspace of the fuzzer. This folder will contain the corpus, crashers, and suppressions. 39 | 40 | ## Corpus \#\# 41 | 42 | Fuzzing generally works best with a corpus that is of minimal size while achieving the maximum coverage. `go-fuzz` automatically minimizes the corpus in-memory before fuzzing so a large corpus shouldn't make a difference. 43 | 44 | ## Disclosure \#\# 45 | 46 | If you find any crashers that affect LND security, please disclose with the information found [here](https://github.com/lightningnetwork/lnd/#security). 47 | 48 | -------------------------------------------------------------------------------- /docs/lnd/alloy-models/linear-fee-function/READM.md: -------------------------------------------------------------------------------- 1 | # Linear Fee Function 2 | 3 | This is a model of the default [Linear Fee 4 | Function](https://github.com/lightningnetwork/lnd/blob/b7c59b36a74975c4e710a02ea42959053735402e/sweep/fee_function.go#L66-L109) 5 | fee bumping mechanism in lnd. 6 | 7 | This model was inspired by a bug fix, due to an off-by-one error in the 8 | original code: https://github.com/lightningnetwork/lnd/issues/8741. 9 | 10 | The bug in the original code was fixed in this PR: 11 | https://github.com/lightningnetwork/lnd/pull/8751. 12 | 13 | 14 | ## Model & Bug Fix Walk-through 15 | 16 | The model includes an assertion that captures the essence of the bug: 17 | `max_fee_rate_before_deadline`: 18 | ```alloy 19 | // max_fee_rate_before_deadline is the main assertion in this model. This 20 | // captures a model violation for our fee function, but only if the line in 21 | // fee_rate_at_position is uncommented. 22 | // 23 | // In this assertion, we declare that if we have a fee function that has a conf 24 | // target of 4 (we want a few fee bumps), and we bump to the final block, then 25 | // at that point our current fee rate is the ending fee rate. In the original 26 | // code, assertion isn't upheld, due to an off by one error. 27 | assert max_fee_rate_before_deadline { 28 | always req_num_blocks_to_conf[4] => bump_to_final_block => eventually ( 29 | all f: LinearFeeFunction | f.position = f.width.sub[1] && 30 | f.currentFeeRate = f.endingFeeRate 31 | ) 32 | } 33 | ``` 34 | 35 | We can modify the model to find the bug described in the original issue. 36 | 1. First, we modify the model by forcing a `check` on the 37 | `max_fee_rate_before_deadline` assertion: 38 | ```alloy 39 | check max_fee_rate_before_deadline 40 | ``` 41 | 42 | 2. Next, we'll modify the `fee_rate_at_position` predicate to re-introduce 43 | the off by one error: 44 | ```alloy 45 | p >= f.width => f.endingFeeRate // -- NOTE: Uncomment this to re-introduce the original bug. 46 | ``` 47 | 48 | If we hit `Execute` in the Alloy Analyzer, then we get a counter example: 49 | ![Counter Example](counter-example.png) 50 | 51 | 52 | We can hit `Show` in the analyzer to visualize it: 53 | ![Counter Example Show](counter-example-show.png) 54 | 55 | We can see that even though we're one block (`position`) before the deadline 56 | (`width`), our fee rate isn't at the ending fee rate yet. 57 | 58 | If we modify the `fee_rate_at_position` to have the correct logic: 59 | ```alloy 60 | p >= f.width.sub[1] => f.endingFeeRate 61 | ``` 62 | 63 | Then Alloy is unable to find any counterexamples: 64 | ![Correct Model](fixed-model.png) 65 | -------------------------------------------------------------------------------- /lightning-network-tools/taproot-assets/asset-loop.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: >- 3 | Loop Out your Taproot Asset channel balances into your onchain Bitcoin wallet 4 | to free up inbound liquidity. 5 | --- 6 | 7 | # Asset Loop 8 | 9 | Starting from Loop v0.30-beta it is possible to perform a Loop Out directly using a Taproot Asset channel balance. Loop will perform an offchain payment to the Loop service via your Edge node. Loop will send BTC onchain to you. 10 | 11 | To perform such a Loop Out, you need Taproot Assets in a channel with a peer performing edge node services. This peer needs outbound liquidity to the wider Lightning Network. It is not necessary to run `loopd` as part of `litd` for easy Autoloop to work. 12 | 13 | The command `loop out` needs to specify the amount you expect to receive onchain in satoshis, the asset ID of the asset to be dispensed and the public key of the edge node. At this point it is only possible to Loop Out assets from a single channel. 14 | 15 | `loop out --amt 250000 --asset_id c5dc35d9ffa03abcbd22d2d2801d10813970875029843039bf4f99d543d15fef --asset_edge_node 0312bddcf146394bf0805feef967e8485b8648c66065fe7345c4bc97eac8312df7` 16 | 17 | Loop will display the quote received from your edge node to provide you with an estimate of how many Taproot Asset units you are expected to pay. 18 | 19 | ``` 20 | Send off-chain: 250000000 Stablesigs 21 | Exchange rate: 1000.0000 Stablesigs/SAT 22 | Limit Send off-chain: 266995000 Stablesigs 23 | Receive on-chain: 247351 sat 24 | Estimated total fee: 2649 sat 25 | 26 | Fast swap requested. 27 | 28 | CONTINUE SWAP? (y/n): y 29 | Swap initiated 30 | ID: 4783f095351f2e7fb6d8eaf3c5bca66064349090d2b7795fca42ae2b144b02d7 31 | HTLC address: tb1ps4jl2l5rs44t6lsp3fkp73396pjsn0syxx9yjqqxktjmtmjtk52sc45drr 32 | 33 | Run `loop monitor` to monitor progress. 34 | ``` 35 | 36 | This feature is available on mainnet, testnet and signet. The usual Loop Out minimums and maximums apply. At this point the Loop node itself does not accept Taproot Asset channels. 37 | 38 | ## Easy Autoloop 39 | 40 | Autoloop can also be configured with Taproot Assets. You can configure the `loop setparams` command for multiple Asset IDs. The settings will apply to all channels with these assets. 41 | 42 | `loop setparams --asset_easyautoloop --asset_id c5dc35d9ffa03abcbd22d2d2801d10813970875029843039bf4f99d543d15fef --asset_localbalance 100000000` 43 | 44 | [Read more: Configure Easy Autoloop](../loop/autoloop.md) 45 | -------------------------------------------------------------------------------- /lightning-network-tools/aperture/pricing.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Use Aperture to dynamically price resources using L402s. 3 | --- 4 | 5 | # Pricing 6 | 7 | Aperture can be easily configured to price resources, such as files or API access. There are two pricing configurations: Fixed and dynamic pricing. 8 | 9 | ## User flow 10 | 11 | In both fixed and dynamic pricing, the Aperture server acts as a proxy between the user and the content server. The user requests the resource and, without the requisite L402, is served the HTTP error response “402 Payment Required,” together with a Macaroon and a Lightning Network invoice. 12 | 13 | By paying the Lightning Network invoice, the user obtains the preimage, which together with the Macaroon forms the valid L402, which the user can present to Aperture in order to obtain the desired resource. 14 | 15 | [Read more: How the L402 is constructed and passed as part of the header](../../the-lightning-network/l402/protocol-specification.md#http-specification) 16 | 17 | ## Fixed Pricing 18 | 19 | In fixed pricing, a resource is offered for a fixed price, expressed in satoshis. Multiple resources can be configured, each with their own price. 20 | 21 | ``` 22 | - name: "service2" 23 | hostregexp: "service2.com:8083" 24 | pathregexp: '^/.*$' 25 | address: "123.456.789:8082" 26 | protocol: https 27 | constraints: 28 | "valid_until": "2020-01-01" 29 | price: 1 30 | ``` 31 | 32 | For each service, a valid L402 will allow its holder to access unlimited resources on this service. To price for each resource individually, we will have to make use of dynamic pricing. 33 | 34 | ## Dynamic pricing 35 | 36 | For dynamic pricing, you will need to configure Aperture to connect to a separate service over gRPC. This for example allows for resources to be priced in fiat currency, sell a large repository of items, each with their own pricing, or adjust prices based on demand. 37 | 38 | ``` 39 | - name: "service3" 40 | hostregexp: "service3.com:8083" 41 | pathregexp: '^/.*$' 42 | address: "123.456.789:8082" 43 | protocol: https 44 | constraints: 45 | "valid_until": "2020-01-01" 46 | dynamicprice: 47 | enabled: true 48 | grpcaddress: 123.456.789:8083 49 | insecure: false 50 | tlscertpath: "path-to-pricer-server-tls-cert/tls.cert" 51 | ``` 52 | 53 | {% embed url="https://www.youtube.com/watch?v=Y2ZG-qcw7Sw" %} 54 | Also watch: Aperture Dynamic Pricing Demo 55 | {% endembed %} 56 | 57 | [https://github.com/ellemouton/aperture-demo](https://github.com/ellemouton/aperture-demo) 58 | -------------------------------------------------------------------------------- /docs/lnd/release-notes/release-notes-0.17.4.md: -------------------------------------------------------------------------------- 1 | # Release Notes 2 | - [Bug Fixes](#bug-fixes) 3 | - [New Features](#new-features) 4 | - [Functional Enhancements](#functional-enhancements) 5 | - [RPC Additions](#rpc-additions) 6 | - [lncli Additions](#lncli-additions) 7 | - [Improvements](#improvements) 8 | - [Functional Updates](#functional-updates) 9 | - [RPC Updates](#rpc-updates) 10 | - [lncli Updates](#lncli-updates) 11 | - [Breaking Changes](#breaking-changes) 12 | - [Performance Improvements](#performance-improvements) 13 | - [Technical and Architectural Updates](#technical-and-architectural-updates) 14 | - [BOLT Spec Updates](#bolt-spec-updates) 15 | - [Testing](#testing) 16 | - [Database](#database) 17 | - [Code Health](#code-health) 18 | - [Tooling and Documentation](#tooling-and-documentation) 19 | 20 | # Bug Fixes 21 | 22 | * [Fix the removal of failed 23 | channels](https://github.com/lightningnetwork/lnd/pull/8406). When a pending 24 | channel opening was pruned from memory no more channels were able to be 25 | created nor accepted. This PR fixes this issue and enhances the test suite 26 | for this behavior. 27 | 28 | * [Fix deadlock possibility in 29 | FilterKnownChanIDs](https://github.com/lightningnetwork/lnd/pull/8400) by 30 | ensuring the `cacheMu` mutex is acquired before the main database lock. 31 | 32 | * [Prevent](https://github.com/lightningnetwork/lnd/pull/8385) ping failures 33 | from [deadlocking](https://github.com/lightningnetwork/lnd/issues/8379) 34 | the peer connection. 35 | 36 | * [Fix](https://github.com/lightningnetwork/lnd/pull/8401) an issue that 37 | caused memory leak for users running `lnd` with `bitcoind.rpcpolling=1` 38 | mode. 39 | 40 | * [Fix](https://github.com/lightningnetwork/lnd/pull/8428) an issue for pruned 41 | nodes where the chain sync got lost because fetching of already pruned blocks 42 | from our peers was not garbage collected when the request failed. 43 | 44 | * Let the REST proxy [skip TLS 45 | verification](https://github.com/lightningnetwork/lnd/pull/8437) when 46 | connecting to the gRPC server to prevent invalid cert use when the ephemeral 47 | cert (used with the `--tlsencryptkey` flag) expires. 48 | 49 | # New Features 50 | ## Functional Enhancements 51 | ## RPC Additions 52 | ## lncli Additions 53 | 54 | # Improvements 55 | ## Functional Updates 56 | ## RPC Updates 57 | ## lncli Updates 58 | ## Code Health 59 | ## Breaking Changes 60 | ## Performance Improvements 61 | 62 | # Technical and Architectural Updates 63 | ## BOLT Spec Updates 64 | ## Testing 65 | ## Database 66 | ## Code Health 67 | ## Tooling and Documentation 68 | 69 | # Contributors (Alphabetical Order) 70 | 71 | * Elle Mouton 72 | * Keagan McClelland 73 | * Olaoluwa Osuntokun 74 | * Yong Yu 75 | * ziggie1984 76 | -------------------------------------------------------------------------------- /the-lightning-network/pathfinding/channel-fees.md: -------------------------------------------------------------------------------- 1 | # Channel Fees 2 | 3 | In the Lightning Network, routing nodes are able to charge a fee for forwarding payments, so-called Hash-Time-Locked-Contracts (HTLCs). This compensation is necessary to incentivize the efficient allocation of capital in the network to be able to receive and send fees inside of the network. 4 | 5 | On the HTLC level, channel fees are the difference between the HTLC sent to the routing node, and the HTLC sent from the routing node onwards. As an example, if you are presented a 1000 satoshis invoice from a node one hop away that charges 1 satoshi, you will send an HTLC over 1001 satoshis to the routing node, which sends a 1000 satoshis HTLC to the final recipient. 6 | 7 | [Read more: Hash Time-lock Contracts](https://docs.lightning.engineering/the-lightning-network/multihop-payments/hash-time-lock-contract-htlc) 8 | 9 | As fees are included in the payment, and all HTLCs contingent on the same preimage, you can only charge fees for successful payments. 10 | 11 | Fees are applied only once per peer and per channel. Each peer can independently set their fee policies for all their channels, which are applied to the capital in the outoing channel in the event of a forward. Meaning, as you push a payment to your neighbor node, you are able to charge a fee, and as payments are pushed to you, your neighbor charges the fee, even if the channel was created by you. Another rule of thumb is that when your capital in a channel is depleted, you get to charge the fee. 12 | 13 | There are two kinds of fees, the base fee and the fee rate. 14 | 15 | ## Base fee 16 | 17 | The base fee is a fixed sum that is charged on each forward, typically 1 satoshi. You may also set this base fee higher or to 0, or charge any amount of millisatoshis. 18 | 19 | As each forward costs you computational power and storage, the base fee is meant to compensate you for your efforts of forwarding any payment. For example, for each new channel state your node has to keep a new revocation key on file. In case you are using a watchtower, this information has to be sent and stored on the watchtower as well. Such information has to be stored until the channel is closed, which can be costly. Choose your base fee wisely! 20 | 21 | ## Fee rate 22 | 23 | The fee rate is a proportion of the payment that you forward, typically measured in parts per million (ppm). 24 | 25 | It is meant to compensate you for the capital that you commit to your Lightning channels. 26 | 27 | [Read more: Update your channel fees](../../lightning-network-tools/lnd/channel-fees.md) 28 | -------------------------------------------------------------------------------- /lightning-network-tools/lightning-terminal/autoopen.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: >- 3 | AutoOpen helps node runners by opening new channels. It takes into account a 4 | variety of factors to improve the node’s position in the graph. 5 | --- 6 | 7 | # Autoopen 8 | 9 | AutoOpen and [Autofees](autofees.md) are available as part of Lightning Terminal’s Autopilot feature. When enabled, AutoOpen lets a node runner assign a budget, specify their time preference as well as define a minimum and maximum channel size. There is also the option to pass node pubkeys of preferred peers. It will then target a suitable point in time to batch open channels to save on fees. 10 | 11 | New channels are selected to improve the node’s reach into the Lightning Network. To measure this reach, AutoOpen uses betweenness centrality, which calculates how many paths between any two other nodes in the network go through the node in question. 12 | 13 |

Configure your Autoopen budget in the Lightning Terminal interface

14 | 15 | To use AutoOpen, [connect to Lightning Terminal](connect.md) and navigate to Autopilot under the Loop menu. This will let you enable AutoOpen, as well as set a budget, define the minimum and maximum channel sizes and specify preferred peers. The “speed” selector defines how sensitive AutoOpen should be to high onchain fees. 16 | 17 | When enabling AutoOpen, you are sharing your node’s public key as well as your current and past channels. This allows AutoOpen to determine your position in the graph, as well as avoid peering you with nodes you previously had channels with, especially if these channels had to be force closed or still have enough liquidity. 18 | 19 | When choosing channels, AutoOpen will look at your node’s channel size distribution and whether it overlaps with the channel size distribution of the new peer. As a small, not yet well connected node you may see channels being opened to well-connected nodes, while large nodes may see new peers that are smaller and less well connected. The channel size is determined using your node’s channel size, your peer’s channel sizes as well as your specified limits. 20 | 21 | AutoOpen will look out for low fee next block targets (compared to long term block fee history) to decide when to open new channels. How sensitive you are to onchain fees can be set through the UI via the time preference configuration. 22 | 23 | The new Autopilot feature will also set your initial channel fees for you. Using the fee rates of the new peer, AutoOpen will set the new adequate outbound fees for the new channel. 24 | 25 | AutoOpen does not close channels. When broadly used, it is expected to further decentralize the Lightning Network graph by avoiding all nodes to be connected to the same large hubs at the center of the network, and instead increase betweenness-centrality by connecting nodes that do not yet share common peers. 26 | -------------------------------------------------------------------------------- /the-lightning-network/overview.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: >- 3 | Learn how the Lightning Network functions. Get comfortable with its topology, 4 | channels, invoices and routing. 5 | --- 6 | 7 | # Overview 8 | 9 | The Lightning Network is a peer-to-peer payment network. It leverages payment channels anchored on the Bitcoin blockchain to enable near instant and low-cost settlement of bitcoin between participants. Multiple such payment channels are chained together to deliver payments to anyone in the network without requiring trust in participants. 10 | 11 | To understand the Lightning Network in its entirety, one should begin by learning about payment channels. 12 | 13 | Next, Lightning Network invoices are used by the recipient of a payment to specify amounts, features and the recipient’s location in the network. 14 | 15 | The entirety of all payment channels forms the Lightning Network. Information about channels and participants is relayed through a gossip network between peers. 16 | 17 | When making payments over the Lightning Network, the sender has to find a route from their node through routing nodes to the recipient. Nodes and their channels are known, but whether an individual node is available and has the liquidity to route the payment is not. In practice, that means constructing multiple theoretical routes and attempting them one by one. 18 | 19 | Each Lightning payment is atomic, meaning it is either completed or failed in full. This is achieved through Hash Time-lock Contracts (HTLC), which allow for individual payments to be settled on-chain in situations where a routing node were to become unresponsive or acts maliciously. 20 | 21 | Lightning Network nodes and channels are constrained by the capital they hold. To understand the Lightning Network, we must also understand how the concept of liquidity affects the reliability of payments, and how a routing node operator can earn fees by effectively deploying capital where it is most needed. 22 | 23 | The following guides assume basic knowledge of Bitcoin, specifically the UTXO model, unconfirmed transactions and their confirmation on the Blockchain. 24 | 25 | {% content-ref url="payment-channels/" %} 26 | [payment-channels](payment-channels/) 27 | {% endcontent-ref %} 28 | 29 | {% content-ref url="the-gossip-network/" %} 30 | [the-gossip-network](the-gossip-network/) 31 | {% endcontent-ref %} 32 | 33 | {% content-ref url="pathfinding/" %} 34 | [pathfinding](pathfinding/) 35 | {% endcontent-ref %} 36 | 37 | {% content-ref url="payment-lifecycle/" %} 38 | [payment-lifecycle](payment-lifecycle/) 39 | {% endcontent-ref %} 40 | 41 | {% content-ref url="multihop-payments/" %} 42 | [multihop-payments](multihop-payments/) 43 | {% endcontent-ref %} 44 | 45 | {% content-ref url="liquidity/" %} 46 | [liquidity](liquidity/) 47 | {% endcontent-ref %} 48 | 49 | {% content-ref url="l402/" %} 50 | [l402](l402/) 51 | {% endcontent-ref %} 52 | 53 | {% content-ref url="taproot-assets/" %} 54 | [taproot-assets](taproot-assets/) 55 | {% endcontent-ref %} 56 | -------------------------------------------------------------------------------- /docs/lnd/alloy-models/README.md: -------------------------------------------------------------------------------- 1 | # Alloy Models 2 | 3 | This folder houses "lightweight formal models" written using the 4 | [Alloy](https://alloytools.org/about.html) model checker and language. 5 | 6 | Compared to typical formal methods, Alloy is a _bounded_ model checker, 7 | considered a [lightweight 8 | method](https://en.wikipedia.org/wiki/Formal_methods#:~:text=As%20an%20alternative,Tools.%5B31) 9 | to formal analysis. Lightweight formal methods are easier to use than fully 10 | fledged formal methods as rather than attempting to prove the that a model is 11 | _always_ correct (for all instances), they instead operate on an input of a set 12 | of bounded parameters and iterations. These models can then be used to specify 13 | a model, then use the model checker to find counter examples of a given 14 | assertion. If a counter example can't be found, then the model _may_ be valid. 15 | 16 | Alloy in particular is an expressive, human readable language for formal 17 | modeling. It also has a nice visualizer which can show counter examples, aiding 18 | in development and understanding. 19 | 20 | Alloy is useful as when used during upfront software design (or even after the 21 | fact), one can create a formal model of a software system to gain better 22 | confidence in the _correctness_ of a system. The model can then be translated 23 | to code. Many times, writing the model (either before or after the code) can 24 | help one to better understand a given software system. Models can also be used 25 | to specify protocols in p2p systems such as Lightning (as it [supports temporal 26 | logic](https://alloytools.org/alloy6.html#:~:text=Meaning%20of%20temporal%20connectives), 27 | which enables creation of state machines and other interactive transcripts), 28 | serving as a complement to a normal prosed based specification. 29 | 30 | ## How To Learn Alloy? 31 | 32 | We recommend the following places to learn Alloy: 33 | * [The online tutorial for Alloy 4.0](https://alloytools.org/about.html): 34 | * Even though this is written with Alloy 4.0 (which doesn't support 35 | temporal logic), the tutorial is very useful, as it introduces 36 | fundamental concept of Alloy, using an accessible example based on a file 37 | system. 38 | 39 | * [Alloy Docs](https://alloy.readthedocs.io/en/latest/index.html): 40 | * This serves as a one stop shop for reference to the Alloy language. It 41 | explains all the major syntax, tooling, and also how to model time in 42 | Alloy. 43 | 44 | * [Formal Software Design with Alloy 6](https://haslab.github.io/formal-software-design/index.html): 45 | * A more in depth tutorial which uses Alloy 6. This tutorial covers more 46 | advanced topics such as [event 47 | reification](https://alloytools.discourse.group/t/modelling-a-state-machine-in-electrum-towards-alloy-6/88). 48 | This tutorial is also very useful, as it includes examples for how to 49 | model interactions in a p2p network, such as one peer sending a message 50 | to another. 51 | -------------------------------------------------------------------------------- /.github/workflows/doc-sync.yaml: -------------------------------------------------------------------------------- 1 | name: Sync Documents 2 | 3 | on: 4 | schedule: 5 | # Run this workflow automatically once a day at midnight. 6 | # * is a special character in YAML so you have to quote this string 7 | - cron: '0 0 * * *' 8 | workflow_dispatch: 9 | 10 | defaults: 11 | run: 12 | shell: bash 13 | 14 | jobs: 15 | sync-docs: 16 | name: Sync documents from upstream 17 | runs-on: ubuntu-latest 18 | strategy: 19 | # Allow other tests in the matrix to continue if one fails. 20 | fail-fast: false 21 | max-parallel: 1 22 | matrix: 23 | repo: [lnd, lightning-terminal] 24 | include: 25 | - repo: lnd 26 | org: lightningnetwork 27 | src: docs 28 | dest: docs/lnd 29 | - repo: lightning-terminal 30 | org: lightninglabs 31 | src: doc 32 | dest: docs/lit 33 | - repo: loop 34 | org: lightninglabs 35 | src: docs 36 | dest: docs/loop 37 | - repo: faraday 38 | org: lightninglabs 39 | src: docs 40 | dest: docs/faraday 41 | - repo: pool 42 | org: lightninglabs 43 | src: docs 44 | dest: docs/pool 45 | - repo: taproot-assets 46 | org: lightninglabs 47 | src: docs 48 | dest: docs/taproot-assets 49 | 50 | steps: 51 | - name: Checkout docs.lightning.engineering repo 52 | uses: actions/checkout@v2 53 | 54 | - name: Checkout ${{ matrix.repo }} repo 55 | uses: actions/checkout@v2 56 | with: 57 | repository: ${{ matrix.org }}/${{ matrix.repo }} 58 | path: ${{ matrix.repo }} 59 | 60 | - name: Pull code differences 61 | run: ./scripts/diff.sh ${{ matrix.repo }} ${{ matrix.src }} ${{ matrix.dest }} 62 | id: create-diff 63 | 64 | - name: Create Pull Request 65 | if: steps.create-diff.outputs.have_diff == 'true' 66 | id: cpr 67 | uses: peter-evans/create-pull-request@v3 68 | with: 69 | commit-message: update documentation 70 | title: Update ${{ matrix.repo }} documentation 71 | body: This PR was created to automatically sync ${{ matrix.repo }} documentation. 72 | branch: docs-${{ matrix.repo }} 73 | author: GitHub 74 | base: master 75 | 76 | - name: Check outputs 77 | if: steps.create-diff.outputs.have_diff == 'true' 78 | run: | 79 | echo "Pull Request Number - ${{ steps.cpr.outputs.pull-request-number }}" 80 | echo "Pull Request URL - ${{ steps.cpr.outputs.pull-request-url }}" 81 | 82 | - name: Merge Pull Request 83 | if: steps.create-diff.outputs.have_diff == 'true' 84 | uses: juliangruber/merge-pull-request-action@v1 85 | with: 86 | github-token: ${{ secrets.GITHUB_TOKEN }} 87 | number: ${{ steps.cpr.outputs.pull-request-number }} 88 | -------------------------------------------------------------------------------- /lightning-network-tools/lightning-terminal/command-line-interface.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: >- 3 | litd can be accessed using the litcli, lncli, pool, loop and frcli command 4 | line interfaces (CLI). 5 | --- 6 | 7 | # Command Line Interface 8 | 9 | Litd comes with a command line interface litcli. This interface is primarily used to generate new sessions for Lightning Node Connect (LNC) and interact with LND Accounts. These tools can be used to connect remotely to your node, e.g. to Lightning Terminal or mobile wallets. 10 | 11 | In addition, litd optionally bundles LND, Pool, Loop and Faraday with their command line interfaces. When compiling `litd`, by default, it doesn’t make `lncli`, `pool`, `loop` and `frcli`, as these might already be on your system. To specifically compile them, run make `go-install-cli` and refer to [our installation guide](get-lit.md). 12 | 13 | These command line interfaces by default point at their standalone clients, so when using litd in integrated mode the arguments have to be slightly adjusted to allow proper communication amongst the clients. 14 | 15 | ## Lightning Terminal 16 | 17 | In remote mode, `litd`, `loopd`, `poold`, `faraday` and `tapd` are run as part of the same binary by default, although each daemon may be run separately, or _remote_. 18 | 19 | ### litcli 20 | 21 | `litcli sessions add --label="My LNC" --type admin` 22 | 23 | By default, a pairing phrase created with litcli is valid for 3 months and is set to "readonly", meaning invoices cannot be paid or created and channels cannot be opened. You may extend this with the `--expiry ` and `--type` flags. 24 | 25 | ## Integrated mode 26 | 27 | In integrated mode, all binaries including LND are run as one. **All of these services are exposed both via port 8443 and 10009, by default the TLS certificate can be found in `~/.lit/tls.cert`** 28 | 29 | In some cases this certificate path has to be specified for the connection to succeed. 30 | 31 | ### loop 32 | 33 | `loop --tlscertpath ~/.lit/tls.cert --rpcserver=localhost:8443 terms in` 34 | 35 | [Learn more: The Loop CLI](../loop/the-loop-cli.md) 36 | 37 | ### pool 38 | 39 | `pool --tlscertpath ~/.lit/tls.cert --rpcserver=localhost:8443 accounts list` 40 | 41 | ### frcli 42 | 43 | `frcli --tlscertpath ~/.lit/tls.cert --rpcserver=localhost:8443 insights` 44 | 45 | [Learn more: The Faraday CLI](../faraday/the-faraday-cli.md) 46 | 47 | ### tapcli 48 | 49 | `tapcli --tlscertpath ~/.lit/tls.cert --rpcserver=localhost:8443 --network=mainnet accounts list` 50 | 51 | ### lncli 52 | 53 | `lncli getinfo` 54 | 55 | In integrated mode, LND is available through the same port as when run as a standalone process. The TLS certificate is stored in its expected location as well, hence no modification to this cli call are necessary. 56 | -------------------------------------------------------------------------------- /docs/lnd/release-notes/release-notes-0.18.5.md: -------------------------------------------------------------------------------- 1 | # Release Notes 2 | - [Bug Fixes](#bug-fixes) 3 | - [New Features](#new-features) 4 | - [Functional Enhancements](#functional-enhancements) 5 | - [RPC Additions](#rpc-additions) 6 | - [lncli Additions](#lncli-additions) 7 | - [Improvements](#improvements) 8 | - [Functional Updates](#functional-updates) 9 | - [RPC Updates](#rpc-updates) 10 | - [lncli Updates](#lncli-updates) 11 | - [Breaking Changes](#breaking-changes) 12 | - [Performance Improvements](#performance-improvements) 13 | - [Technical and Architectural Updates](#technical-and-architectural-updates) 14 | - [BOLT Spec Updates](#bolt-spec-updates) 15 | - [Testing](#testing) 16 | - [Database](#database) 17 | - [Code Health](#code-health) 18 | - [Tooling and Documentation](#tooling-and-documentation) 19 | 20 | # Bug Fixes 21 | 22 | * [Fixed a bug](https://github.com/lightningnetwork/lnd/pull/9459) where we 23 | would not cancel accepted HTLCs on AMP invoices if the whole invoice was 24 | canceled. 25 | 26 | # New Features 27 | 28 | ## Functional Enhancements 29 | 30 | ## RPC Additions 31 | 32 | ## lncli Additions 33 | * [`updatechanpolicy`](https://github.com/lightningnetwork/lnd/pull/8805) will 34 | now update the channel policy if the edge was not found in the graph 35 | database if the `create_missing_edge` flag is set. 36 | 37 | # Improvements 38 | ## Functional Updates 39 | ## RPC Updates 40 | 41 | ## lncli Updates 42 | ## Code Health 43 | ## Breaking Changes 44 | ## Performance Improvements 45 | 46 | # Technical and Architectural Updates 47 | ## BOLT Spec Updates 48 | 49 | ## Testing 50 | ## Database 51 | * [Remove global application level lock for 52 | Postgres](https://github.com/lightningnetwork/lnd/pull/9242) so multiple DB 53 | transactions can run at once, increasing efficiency. Includes several bugfixes 54 | to allow this to work properly. 55 | ## Code Health 56 | 57 | * [Golang was updated to 58 | `v1.22.11`](https://github.com/lightningnetwork/lnd/pull/9462). 59 | 60 | * [Improved user experience](https://github.com/lightningnetwork/lnd/pull/9454) 61 | by returning a custom error code when HTLC carries incorrect custom records. 62 | 63 | * [Make input validation stricter](https://github.com/lightningnetwork/lnd/pull/9470) 64 | when using the `BumpFee`, `BumpCloseFee(deprecated)` and `BumpForceCloseFee` 65 | RPCs. For the `BumpFee` RPC the new param `deadline_delta` is introduced. For 66 | the `BumpForceCloseFee` RPC the param `conf_target` was added. The conf_target 67 | changed in its meaning for all the RPCs which had it before. Now it is used 68 | for estimating the starting fee rate instead of being treated as the deadline, 69 | and it cannot be set together with `StartingFeeRate`. Moreover if the user now 70 | specifies the `deadline_delta` param, the budget value has to be set as well. 71 | 72 | ## Tooling and Documentation 73 | 74 | # Contributors (Alphabetical Order) 75 | 76 | * Ziggie 77 | * Jesse de Wit 78 | * Alex Akselrod 79 | * Konstantin Nick 80 | -------------------------------------------------------------------------------- /docs/lnd/zero_conf_channels.md: -------------------------------------------------------------------------------- 1 | # Setting up zero-conf channels in LND 2 | 3 | Zero-conf channels are channels that do not require confirmations to be used. Because of this, 4 | the fundee must trust the funder to not double-spend the channel and steal the balance of the 5 | channel. 6 | 7 | ## Startup 8 | 9 | Two options must be specified either on the command line or in the config file: 10 | - `protocol.option-scid-alias` 11 | - `protocol.zero-conf` 12 | 13 | If one of these is missing, zero-conf channels won't work. This applies for both the funder 14 | and fundee. 15 | 16 | ## Opening the channel 17 | 18 | The channel open flow is slightly different, so there are new requirements for the 19 | initiator and responder in the funding flow. 20 | 21 | ### Initiator requirements 22 | 23 | When opening the channel, the initiator must ensure that the `anchors` channel_type is 24 | enabled. Additionally, the initiator must specify on the `openchannel` command line call 25 | or the corresponding RPC that the zero-conf flag is set. 26 | 27 | ### Responder requirements 28 | 29 | The responder flow is different from the initiator's. If the responder has not specified 30 | a ChannelAcceptor, then ALL open channel requests will be failed regardless if they are 31 | zero-conf or not. The ChannelAcceptor RPC will give the responder information on whether 32 | the initiator is requesting a zero-conf channel via the channel type. 33 | 34 | If the responder has specified a ChannelAcceptor and the funder has set the zero-conf 35 | channel type, then the responder should set the ZeroConf flag to true if they wish to 36 | accept it and false otherwise. If ZeroConf is true, then MinAcceptDepth should be zero. 37 | 38 | It is possible for the responder to set the ZeroConf flag to true even when the funder 39 | did not specify the zero-conf channel type. This will only create a zero-conf channel if 40 | the funder is a non-LND node that supports this behavior. This is for compatibility with 41 | LDK nodes. In this case, the responder must know that the funder is using an implementation 42 | that supports this behavior (like LDK). The scid-alias feature bit must also have been 43 | negotiated. 44 | 45 | ## Updated RPC calls 46 | 47 | The `listchannels` and `closedchannels` RPC calls have been updated. They now include a 48 | list of all aliases that the channel has used. The `ChanId` in the response is the 49 | confirmed SCID for non-zero-conf channels. For zero-conf channels, the `ChanID` is the 50 | first alias used in the channel. The RPCs will also return the confirmed SCID for 51 | zero-conf channels in a separate field. 52 | 53 | A new RPC `listaliases` has been introduced. It returns a set of mappings from one SCID 54 | to a list of SCIDS. The key is the confirmed SCID for non-zero-conf channels. For 55 | zero-conf channels, it is the first alias used in the channel. The values are the list 56 | of all aliases ever used in the channel (including the key for zero-conf channels). This 57 | information can be cross-referenced with the output of `listchannels` and `closedchannels` 58 | to determine what channel a particular alias belongs to. -------------------------------------------------------------------------------- /docs/lnd/etcd.md: -------------------------------------------------------------------------------- 1 | # Experimental etcd support in LND 2 | 3 | With the recent introduction of the `kvdb` interface LND can support multiple 4 | database backends allowing experimentation with the storage model as well as 5 | improving robustness through e.g. replicating essential data. 6 | 7 | Building on `kvdb` in v0.11.0 we're adding experimental [etcd](https://etcd.io) 8 | support to LND. As this is an unstable feature heavily in development, it still 9 | has *many* rough edges for the time being. It is therefore highly recommended to 10 | not use LND on `etcd` in any kind of production environment especially not 11 | on bitcoin mainnet. 12 | 13 | ## Building LND with etcd support 14 | 15 | To create a dev build of LND with etcd support use the following command: 16 | 17 | ```shell 18 | $ make tags="kvdb_etcd" 19 | ``` 20 | 21 | The important tag is the `kvdb_etcd`, without which the binary is built without 22 | the etcd driver. 23 | 24 | For development, it is advised to set the `GOFLAGS` environment variable to 25 | `"-tags=test"` otherwise `gopls` won't work on code in `channeldb/kvdb/etcd` 26 | directory. 27 | 28 | ## Running a local etcd instance for testing 29 | 30 | To start your local etcd instance for testing run: 31 | 32 | ```shell 33 | $ ./etcd \ 34 | --auto-tls \ 35 | --advertise-client-urls=https://127.0.0.1:2379 \ 36 | --listen-client-urls=https://0.0.0.0:2379 \ 37 | --max-txn-ops=16384 \ 38 | --max-request-bytes=104857600 39 | ``` 40 | 41 | The large `max-txn-ops` and `max-request-bytes` values are currently required in 42 | case of running LND with the full graph in etcd. These parameters have been 43 | tested to work with testnet LND. 44 | 45 | ## Configuring LND to run on etcd 46 | 47 | To run LND with etcd, additional configuration is needed, specified either 48 | through command line flags or in `lnd.conf`. 49 | 50 | Sample command line: 51 | 52 | ```shell 53 | $ ./lnd-debug \ 54 | --db.backend=etcd \ 55 | --db.etcd.host=127.0.0.1:2379 \ 56 | --db.etcd.certfile=/home/user/etcd/bin/default.etcd/fixtures/client/cert.pem \ 57 | --db.etcd.keyfile=/home/user/etcd/bin/default.etcd/fixtures/client/key.pem \ 58 | --db.etcd.insecure_skip_verify 59 | ``` 60 | 61 | Sample `lnd.conf` (with other setting omitted): 62 | 63 | ```text 64 | [db] 65 | db.backend=etcd 66 | db.etcd.host=127.0.0.1:2379 67 | db.etcd.cerfile=/home/user/etcd/bin/default.etcd/fixtures/client/cert.pem 68 | db.etcd.keyfile=/home/user/etcd/bin/default.etcd/fixtures/client/key.pem 69 | db.etcd.insecure_skip_verify=true 70 | ``` 71 | 72 | Optionally users can specify `db.etcd.user` and `db.etcd.pass` for db user 73 | authentication. If the database is shared, it is possible to separate our data 74 | from other users by setting `db.etcd.namespace` to an (already existing) etcd 75 | namespace. In order to test without TLS, users are able to set `db.etcd.disabletls` 76 | flag to `true`. 77 | 78 | ## Migrating existing channel.db to etcd 79 | 80 | This is currently not supported. 81 | 82 | ## Disclaimer 83 | 84 | As mentioned before this is an experimental feature, and with that your data 85 | may be lost. Use at your own risk! 86 | -------------------------------------------------------------------------------- /docs/loop/faqs.md: -------------------------------------------------------------------------------- 1 | 2 | # Frequently Asked Questions 3 | 4 | ## How does Loop recover from a crash? 5 | When `loopd` is terminated (or killed) for whatever reason, it will pickup 6 | pending swaps after a restart. 7 | 8 | Information about pending swaps is stored persistently in the swap database. 9 | Its location is `~/.loopd//loop.db`. 10 | 11 | ## Can Loop handle multiple simultaneous swaps? 12 | It is possible to execute multiple swaps simultaneously. Just keep loopd 13 | running. 14 | 15 | ## What are the fees? 16 | 17 | You can pass the `--verbose` flag when using Loop to get a detailed fee 18 | breakdown 19 | 20 | ### Loop Out Fees 21 | 22 | An explanation of each fee: 23 | 24 | - **Estimated on-chain fee**: The estimated cost to sweep the 25 | HTLC in case of success, calculated based on the _current_ on-chain fees. 26 | This value is called `miner_fee` in the gRPC/REST responses. 27 | - **Max on-chain fee**: The maximum on-chain fee the daemon 28 | is going to allow for sweeping the HTLC in case of success. A fee estimation 29 | based on the `--conf_target` flag is always performed before sweeping. The 30 | factor of `100` times the estimated fee is applied in case the fees spike 31 | between the time the swap is initiated and the time the HTLC can be swept. But 32 | that is the absolute worst-case fee that will be paid. If there is no fee 33 | spike, a normal, much lower fee will be used. 34 | - **Max off-chain swap routing fee**: The maximum off-chain 35 | routing fee that the daemon should pay when finding a route to pay the 36 | Lightning invoice. This is a hard limit. If no route with a lower or equal fee 37 | is found, the payment (and the swap) is aborted. This value is calculated 38 | statically based on the swap amount (see `maxRoutingFeeBase` and 39 | `maxRoutingFeeRate` in `cmd/loop/main.go`). 40 | - **Max off-chain prepay routing fee**: The maximum off-chain routing 41 | fee that the daemon should pay when finding a route to pay the prepay fee. 42 | This is a hard limit. If no route with a lower or equal fee is found, the 43 | payment (and the swap) is aborted. This value is calculated statically based 44 | on the prepay amount (see `maxRoutingFeeBase` and `maxRoutingFeeRate` in 45 | `cmd/loop/main.go`). 46 | - **No show penalty (prepay)**: This is the amount that has to be 47 | pre-paid (off-chain) before the server publishes the HTLC on-chain. This is 48 | necessary to ensure the server's on-chain fees are paid if the client aborts 49 | and never completes the swap _after_ the HTLC has been published on-chain. 50 | If the swap completes normally, this amount is counted towards the full swap 51 | amount and therefore is actually a pre-payment and not a fee. This value is 52 | called `prepay_amt` in the gRPC/REST responses. 53 | 54 | ### Loop In Fees 55 | 56 | An explanation of each fee: 57 | 58 | - **Estimated on-chain fee**: The estimated on-chain fee that the 59 | daemon has to pay to publish the HTLC. This is an estimation from `lnd`'s 60 | wallet based on the available UTXOs and current network fees. This value is 61 | called `miner_fee` in the gRPC/REST responses. 62 | -------------------------------------------------------------------------------- /lightning-network-tools/lnd/inbound-channel-fees.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: >- 3 | Inbound channel fees allow node operators to more efficiently signal where 4 | liquidity scarcities occur. This improves capital allocation in the Lightning 5 | Network and allows channels to be utilized more 6 | --- 7 | 8 | # Inbound Channel Fees 9 | 10 | Inbound channel fees allow a node operator to set a fee on the incoming channel of a payment, as opposed to only the outgoing channel. This allows for a more granular fee schedule, which more accurately signals supply and demand of liquidity. 11 | 12 | While it is currently possible to limit the flow of funds to certain peers by raising outbound fees, it is not possible to limit the flow from certain peers. 13 | 14 | Inbound channel fees make this possible and solve the problem of “outbound drains.” Such outbound drains are nodes that open channels to you, push their funds outwards through your node and close their channel, leaving you without adequate outbound, an onchain UTXO, and no compensation. 15 | 16 | ## How inbound channel fees work 17 | 18 | Inbound channel fees are available as negative fees, or discounts on the outgoing channel fee. This allows for backwards compatibility, as nodes not compatible with inbound channel fees will still be able to make use of the channels, albeit without making use of the discount. 19 | 20 | To allow for safe usage of inbound channel fees, the discount is only applied as long as the total fee is larger than the combined fee of incoming and outgoing channel. This makes it impossible to lose funds through routing. 21 | 22 | Inbound channel fees are propagated as part of the general Lightning gossip, as older nodes will pass on information even if they do not understand it themselves. 23 | 24 | Positive inbound channel fees can optionally be set as well. However, as these positive inbound channel fees can only be understood by upgraded nodes, setting positive inbound channel fees is risky, as it can lead to routing failures among older nodes. 25 | 26 | To be able to set positive inbound channel fees, add the following to your `lnd.conf` file:\ 27 | `accept-positive-inbound-fees=true` 28 | 29 | For updated nodes, both positive and negative inbound channel fees become part of the network graph and are taken into account when calculating the fee of a potential payment route. 30 | 31 | ## How to set inbound channel fees 32 | 33 | Similar to outbound channel fees, inbound channel fees consist of a flat base fee, expressed in milli-satoshis, and a variable fee rate, expressed in parts per million (ppm). 34 | 35 | As of now, inbound channel fees can only be specified through the update channel policy command. For now, inbound channel fees should only be defined as a discount, e.g. set to zero or a negative value. 36 | 37 | All other values also have to be set every time this command is called. For example: 38 | 39 | `lncli updatechanpolicy --base_fee_msat 100 --fee_rate 1000 --time_lock_delta 80 --inbound_base_fee_msat -1000 --inbound_fee_rate_ppm -100 --chan_point b9740e90782497f9109fbbf4a787b1bf024e480813d781f402679a1ede96043c:0` 40 | 41 | \ 42 | An empty array should be returned in case of success. 43 | -------------------------------------------------------------------------------- /docs/pool/account_recovery.md: -------------------------------------------------------------------------------- 1 | # Account Recovery 2 | 3 | In this section, we'll cover the possible ways of recovering the funds within a 4 | Pool account upon data corruption/loss. Account funds are locked to a 2-of-2 5 | multi-sig output of the account owner and the Pool auctioneer until the 6 | account's expiration has been met, giving the account owner the security that 7 | funds will not be spend without the owner's consent. This expiration is included 8 | in the account output script, so it must be known in order to spend the account 9 | funds. There are two possible ways to recover an account's funds after data 10 | corruption/loss: 11 | 12 | - With Pool auctioneer's cooperation: which is the only method currently 13 | supported. 14 | - Without Pool auctioneer's cooperation: which will require storage of an 15 | additional data blob similar to the Static Channel Backups present within 16 | `lnd`. 17 | 18 | An auctioneer-assisted account recovery intent can be issued through the 19 | `pool accounts recover` command or the `RecoverAccounts` RPC. 20 | 21 | ```text 22 | $ pool accounts recover -h 23 | NAME: 24 | pool accounts recover - recover accounts after data loss with the help of the auctioneer 25 | 26 | USAGE: 27 | pool accounts recover [arguments...] 28 | 29 | DESCRIPTION: 30 | 31 | In case the data directory of the trader was corrupted or lost, this 32 | command can be used to ask the auction server to send back its view of 33 | the trader's accounts. This is possible as long as the connected lnd 34 | node is running with the same seed as when the accounts to recover were 35 | first created. 36 | 37 | NOTE: This command should only be used after data loss as it will fail 38 | if there already are open accounts in the trader's database. 39 | All open or pending orders of any recovered account will be canceled on 40 | the auctioneer's side and won't be restored in the trader's database. 41 | ``` 42 | 43 | ## Auctioneer-Assisted Account Recovery 44 | 45 | As part of the initial Lightning Pool launch, an account recovery method has 46 | been added that requires the cooperation of the auctioneer. This method is 47 | based on the account owner sending a recovery intent to the auctioneer, along 48 | with a challenge response to prove ownership. The recovery intent includes a 49 | set of keys derived by the same account BIP-0043 derivation path 50 | `m/1017'/coin_type'/220'/0/index`, so the same `lnd` seed that was to used to 51 | initially create the accounts must be used. 52 | 53 | Upon the auctioneer receiving the intent, it will verify the challenge 54 | response, determine the validity of account key to recovery, and provide the 55 | account owner the latest details of the account known to the auctioneer. This 56 | allows the account owner to continue using their account within the auction 57 | without having to perform any on-chain transactions. As usual, the account 58 | owner can decide to close the account and withdraw their funds to their desired 59 | outputs if they no longer wish to participate in the auction. 60 | 61 | Note that as a part of this process, all orders belonging to an account being 62 | recovered are canceled within the auction and are not restored to the account 63 | owner. 64 | -------------------------------------------------------------------------------- /lightning-network-tools/taproot-assets/become-an-edge-node.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: From routing node to Edge node 3 | --- 4 | 5 | # Become an Edge Node 6 | 7 | An Edge node routes payments between Taproot Asset channels and the larger Lightning Network. Parts marked in violet are provided by litd 8 | 9 | ## Existing routing node 10 | 11 | {% hint style="success" %} 12 | This functionality is provided by LND 13 | {% endhint %} 14 | 15 | Building an Edge node requires both outgoing and incoming liquidity with the greater Lightning Network. This implies a mighty routing node, but might also be achieved with a few girthy channels to routing nodes. 16 | 17 | [Read more: Understanding Liquidity](../../the-lightning-network/liquidity/understanding-liquidity.md) 18 | 19 | ## Assets 20 | 21 | {% hint style="success" %} 22 | This functionality is provided by tapd 23 | {% endhint %} 24 | 25 | The decision of what assets an Edge node is willing to route depends on the asset’s acceptance, liquidity and spreads. An Edge node could be affiliated directly with an issuer, but mostly likely acquires the assets on the open market. 26 | 27 | [Read more: Minting and sending Taproot Assets onchain](../pool/first-steps.md) 28 | 29 | ## Taproot Asset channels 30 | 31 | {% hint style="success" %} 32 | This functionality is provided by LND, tapd and litd 33 | {% endhint %} 34 | 35 | An Edge node may both open Taproot Asset channels and accept them. It will advertise which assets it accepts channels for. It may restrict the channels it accepts by their minimum or maximum size, as it would for regular Bitcoin channels. 36 | 37 | [Read more: Opening Taproot Asset channels](taproot-assets-channels.md) 38 | 39 | ## RFQ 40 | 41 | {% hint style="success" %} 42 | All litd nodes are able to use RFQ to communicate rates 43 | {% endhint %} 44 | 45 | Rates are communicated to peers directly via a process called “Request for Quote (RFQ)”. The gRPC API allows any Taproot Assets node to request quotes and use them when constructing payment routes. The RFQ process is typically between the user and a price oracle. 46 | 47 | ## The Oracle 48 | 49 | {% hint style="warning" %} 50 | This functionality requires external software 51 | {% endhint %} 52 | 53 | In the same way a routing node will set the rates at which it is willing to forward payments, an Edge node will set rates for each asset. These rates however may change far more frequently and are not broadcast as part of regular gossip announcements. 54 | 55 | The oracle is software that aggregates or determines the rates, either based on an order book, reference rates or public order books. The oracle may determine a single rate on top of which the Edge node charges a fee, or separate bid and ask rates, separated by a spread. 56 | 57 | [Read more: RFQ](become-an-edge-node.md#rfq) 58 | 59 | ## Hedging mechanisms 60 | 61 | {% hint style="warning" %} 62 | This functionality requires external services 63 | {% endhint %} 64 | 65 | Every forward shifts the balance of satoshis and assets in the Edge node. A sophisticated operator might want to hedge against price fluctuations, for example on a spot exchange. It is also conceivable that smaller Edge nodes use larger Edge nodes to hedge directly through Taproot Asset channels. 66 | -------------------------------------------------------------------------------- /lightning-network-tools/taproot-assets/multisignature.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: >- 3 | To secure your Taproot Assets you may distribute your keys across segregated 4 | devices and security zones. 5 | --- 6 | 7 | # Multisignature 8 | 9 | Taproot Assets and their balances are recorded offchain in Taproot outputs. Analogous to Bitcoin, Taproot Assets are held in outputs, which are locked through scripts, called Taproot Asset Outputs. The Bitcoin-level UTXO commits to this merkle tree, effectively anchoring the assets to a Bitcoin UTXO. 10 | 11 | To spend a Taproot Asset vUTXO, two conditions need to be met. 12 | 13 | 1. The Taproot Assets-level vUTXO script needs to be satisfied. In practice, that means the signature(s) to the Taproot Asset need to be valid and an eventual timelock needs to be satisfied. 14 | 2. The Bitcoin-level-UTXO script needs to be satisfied. In case of a single signer or cooperative signatories, this is a valid Schnorr signature. Additionally, Taproot transactions allow for multiple alternative spending conditions. 15 | 16 | ## Multisignature approaches 17 | 18 | The nature of the Taproot Assets protocol allows for multiple methods to securing Taproot Assets through multiple keys. 19 | 20 | ### At the Taproot Asset level 21 | 22 | Each individual Taproot Asset can be secured with multisig, either on the vUTXO level through Schnorr signatures (MuSig2, e.g. N-of-N) or on the script level. Given that MuSig2 signature can only be N-of-N, If a K-of-N multisignature contract is required, a tree of MuSig2 can be used to produce the various key combinations to fulfill the K-of-N requirement. To prevent the internal Taproot key from being used, the key is set to the NUMS key: A deterministic public key for which it can be proven that no private key exists. 23 | 24 | Multisig at the tapleaf layer level enables the owner of the Taproot Asset to not have to control the internal Taproot key, e.g. use a pocket universe. 25 | 26 | [Also see: Multisignature itest in tapd](https://github.com/lightninglabs/taproot-assets/blob/main/itest/multisig.go) 27 | 28 | ### At the internal Taproot key 29 | 30 | All Taproot Assets are held by a Taproot UTXO, allowing use of Taproot’s native MuSig2 feature to require multiple parties to sign off on every transaction. These arrangements are limited to n-of-n MuSig2. 31 | 32 | ### At the Bitcoin-level script 33 | 34 | To implement n-of-m multisignature schemes we have to make use of Bitcoin script, similar to how multisignature schemes work in Segwit addresses. This mechanism can be used in addition to MuSig2, for example to perform key recovery or instead of it, for example to introduce additional restrictions such as timelocks. 35 | 36 | ### The asset group key 37 | 38 | Grouped assets do not have a fixed supply, and new assets can be issued anytime using the asset group key. As an asset issuer, maintaining the integrity of the asset group key is crucial. This key is a 32 byte Schnorr key, similar to those used for the internal key of a Taproot transaction.. This allows for N-of-N MuSig2 using the same tools and mechanisms used to secure the internal Taproot key. 39 | -------------------------------------------------------------------------------- /lightning-network-tools/pool/account_recovery.md: -------------------------------------------------------------------------------- 1 | # Account Recovery 2 | 3 | In this section, we'll cover the possible ways of recovering the funds within a Pool account upon data corruption/loss. Account funds are locked to a 2-of-2 multi-sig output of the account owner and the Pool auctioneer until the account's expiration has been met, giving the account owner full control of the funds. This expiration is included in the account output script, so it must be known in order to spend the account funds. There are two possible ways to recover an account's funds after data corruption/loss: one that requires the Pool auctioneer's cooperation, which is the only method currently supported, and one without, which will require storage of an additional data blob similar to the Static Channel Backups present within `lnd`. An auctioneer-assisted account recovery intent can be issued through the `pool accounts recover` command or the `RecoverAccounts` RPC. 4 | 5 | ``` 6 | pool accounts recover -h 7 | NAME: 8 | pool accounts recover - recover accounts after data loss with the help of the auctioneer 9 | 10 | USAGE: 11 | pool accounts recover [arguments...] 12 | 13 | DESCRIPTION: 14 | 15 | In case the data directory of the trader was corrupted or lost, this 16 | command can be used to ask the auction server to send back its view of 17 | the trader's accounts. This is possible as long as the connected lnd 18 | node is running with the same seed as when the accounts to recover were 19 | first created. 20 | 21 | NOTE: This command should only be used after data loss as it will fail 22 | if there already are open accounts in the trader's database. 23 | All open or pending orders of any recovered account will be canceled on 24 | the auctioneer's side and won't be restored in the trader's database. 25 | ``` 26 | 27 | ## Auctioneer-Assisted Account Recovery 28 | 29 | As part of the initial Lightning Pool launch, an account recovery method has been added that requires the cooperation of the auctioneer. This method is based on the account owner sending a recovery intent to the auctioneer, along with a challenge response to prove ownership. The recovery intent includes a set of keys derived by the same account BIP-0043 derivation path `m/1017'/coin_type'/220'/0/index`, so the same `lnd` seed that was to used to initially create the accounts must be used. 30 | 31 | Upon the auctioneer receiving the intent, it will verify the challenge response, determine the validity of account key to recovery, and provide the account owner the latest details of the account known to the auctioneer. This allows the account owner to continue using their account within the auction without having to perform any on-chain transactions. As usual, the account owner can decide to close the account and withdraw their funds to their desired outputs if they no longer wish to participate in the auction. 32 | 33 | Note that as a part of this process, all orders belonging to an account being recovered are canceled within the auction and are not restored to the account owner. 34 | 35 | ## Umbrel 36 | 37 | In Umbrel, you may run the following command to recovery your account:\ 38 | `docker exec -it lightning-terminal_web_1 pool --rpcserver=localhost:8443 --tlscertpath=~/.lit/tls.cert accounts recover` 39 | -------------------------------------------------------------------------------- /lightning-network-tools/taproot-assets/minting-assets-with-an-external-signer.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Use an external signing device to protect your private keys. 3 | --- 4 | 5 | # Minting Assets With an External Signer 6 | 7 | The Taproot Assets protocol allows for great flexibility regarding the security of an asset. Keys exist on multiple layers, each of which may be distributed between users and services, hot (internet-connected) and cold (air-gapped) machines or specialized external signing devices. 8 | 9 | ## Asset issuance 10 | 11 | There are three keys relevant to issuance of a Taproot Asset. 12 | 13 | 1. The Bitcoin key controlling the UTXO anchoring the Taproot Asset on the Bitcoin level. 14 | 2. The Asset Script key controlling the spending of the vUTXO on the Taproot Asset level. 15 | 3. The Group key that identifies a grouped asset and allows for the expansion of the asset supply. 16 | 17 | Each of these keys may be held separately, with the group key being the most sensitive, as it can be used to reissue the asset and expand its supply without limits. The group key cannot be cycled and must be safe for the entire life-cycle of the asset. Keeping this key safe is paramount. 18 | 19 | As of now, only this group key can be held on an external device. The group key is defined by a custom derivation path of a standard master key, generated using a general seed phrase. This seed phrase can act as a backup of the key, while the signing device is used to authorize initial and further issuance of the asset. 20 | 21 | [Read: Generating the group key on an air-gapped machine using Chantools](https://github.com/lightninglabs/taproot-assets/blob/nums-non-spend-leaves/docs/external-group-key.md) 22 | 23 | [Read: Generating the group key on a specialized signing device](https://github.com/lightninglabs/taproot-assets/blob/main/docs/external-group-key-ledger.md) 24 | 25 | To also hold the Bitcoin key in a hardware wallet, additional work needs to be done to allow for signing of generic Taproot PSBTs. 26 | 27 | Similarly, while the Asset Script key could be held by a hardware wallet, the hardware wallet would need some understanding of what it is signing, ideally information of the vPSBT and Bitcoin PSBT. 28 | 29 | ## Asset transfer 30 | 31 | There are multiple keys relevant to transfer Taproot Assets. 32 | 33 | 1. The Bitcoin key controlling the UTXO anchoring the Taproot Asset is held by LND. However, LND cannot spend this UTXO alone, not even by accident. 34 | 2. To spend the UTXO, and with it the Taproot Asset, the taptweak held by \`tapd\` is needed. 35 | 3. The Asset Script key spending the vUTXO on the Taproot Asset level. 36 | 37 | While it is technically possible to keep either the Bitcoin key or the Asset Script key on a dedicated air-gapped or signing device, there is currently no mechanism equipped for that. 38 | 39 | A special case is that of pocket universes, where the Bitcoin key is held by a service, while the Asset Script key is held by the user. This allows for the efficient batching of potentially millions of asset transfers in a single Bitcoin transaction. The service does however not control the assets of the users and cannot move them independently. 40 | 41 | [FAQ: What is a pocket universe](../../the-lightning-network/taproot-assets/faq.md) 42 | -------------------------------------------------------------------------------- /lightning-network-tools/faraday/get-started.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Install and run faraday and frcli 3 | --- 4 | 5 | # Get Started 6 | 7 | ## Installation 8 | 9 | Faraday comes bundled in Lightning Terminal. Meaning if you have Lightning Terminal installed, you can already access Faraday through the command line and you may skip the step below. If you want to install Lightning Terminal, [follow this guide](../lightning-terminal/). 10 | 11 | To run Faraday, you need to be running LND from the [binary releases](https://github.com/lightningnetwork/lnd/releases), or compile from source with the command `make install tags="signrpc walletrpc chainrpc invoicesrpc"` 12 | 13 | You can run Faraday directly from the [binary releases](https://github.com/lightninglabs/faraday/releases), or compile it from source: 14 | 15 | `git clone https://github.com/lightninglabs/faraday.git`\ 16 | `cd faraday`\ 17 | `make && make install` 18 | 19 | ## Run Faraday 20 | 21 | Faraday, like bitcoind, LND and others, comes with two components: Faraday itself, and a command line interface (CLI) to interact with it. In this case, they are called `faraday` and `frcli`. 22 | 23 | To make full use of Faraday you will need to connect it to your Bitcoin node, for example `bitcoind` or `btcd`. To do that, run Faraday with the command `faraday --connect_bitcoin --bitcoin.host=localhost:8332 --bitcoin.user=[the RPC username as defined in bitcoin.conf] --bitcoin.password=[the RPC password as defined in bitcoin.conf]` 24 | 25 | If you want to run Faraday in the background, you can also write the output to `/dev/null` by amending `&>/dev/null &` to the above command.\ 26 | 27 | 28 | ### Lightning Terminal 29 | 30 | If you are running Lightning Terminal already, either locally or remotely, Faraday will be running inside of it already. However, you will need to specify the port everytime you run frcli using the flag `--rpcserver=localhost:8443`, for example `./frcli --rpcserver=localhost:8443 audit` 31 | 32 | If you are a Lightning Terminal user and want to avoid having to include the `--rpcserver` command every time or navigating to the location of the frcli binary, you may also add an entry to your aliases file (e.g. `~/.bash_aliases`): 33 | 34 | `alias frcli=’~/path/to/lit/./frcli --rpcserver=localhost:8443’` 35 | 36 | You may have to manually move over your node’s `tls.cert` to `~/.faraday/mainnet` 37 | 38 | To use all of Faraday’s features, we will have to configure Lightning Terminal to connect to our Bitcoin node. We can do that by amending the following lines to our `lit.conf` file: 39 | 40 | `faraday.connect_bitcoin=1`\ 41 | `faraday.bitcoin.host=[the ip or domain of our bitcoind node]:8332`\ 42 | `faraday.bitcoin.user=[our bitcoind username, as specified in our bitcoin.conf]`\ 43 | `faraday.bitcoin.password=[our bitcoind password, as specified in our bitcoin.conf]`\ 44 | 45 | 46 | Typically, bitcoind will not allow RPC connections from outside, although this can be configured with `rpcallowip=[IP of the machine you are running LiT on]`. If you are unsure about the security implications of opening up bitcoind’s RPC calls, consider using faraday on the same machine as your bitcoin node. 47 | -------------------------------------------------------------------------------- /lightning-network-tools/lightning-terminal/liquidity-report.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: >- 3 | Lightning Terminal Liquidity reports provide node operators with a quick view 4 | of their inbound capacity 5 | --- 6 | 7 | # Liquidity Report 8 | 9 | Inbound liquidity, or inbound capacity, refers to the ability of a node to receive Lightning payments. This inbound liquidity comes at a cost, charged to the payer in the form of a fee rate. As inbound liquidity depletes, peers raise their fees, and finding a path becomes more difficult as the payer has to attempt more routes before their payment succeeds. 10 | 11 | [Read more: Understanding Liquidity](../../the-lightning-network/liquidity/understanding-liquidity.md) 12 | 13 | As a merchant, plentiful and economical inbound capacity is an important key to successfully accepting Lightning payments. For routing nodes too, inbound capacity is a determining factor in your ability to route payments 14 | 15 | In [Lightning Terminal](./), navigate to “Loop” and click on “Liquidity Report” on the top right side to view your node’s liquidity report. For various simulated payment sizes, you can see the estimated fee somebody paying to your node would have to pay. 16 | 17 | The “Routable Liquidity” graph shows how many channels you can get paid through at several fee levels. It can be displayed as an ordinary or cumulative histogram. 18 | 19 | [Read more: How to get Inbound Capacity](../../the-lightning-network/liquidity/how-to-get-inbound-capacity-on-the-lightning-network.md) 20 | 21 | The “Routable Inbound” graph places your channels into various fee buckets, and shows for each fee bucket how many channels have liquidity available. 22 | 23 | 24 | 25 |

Sample liquidity report

26 | 27 | Don’t rely on other participants of the Lightning Network to remotely detect your liquidity needs. Monitor your node’s inbound capacity and fees and actively manage your node’s liquidity. Attempt to free up additional capacity first, for instance through [Lightning Loop](../loop/), and only close channels that can’t be empty otherwise. Maximize your percentage of channels that have inbound capacity, rather than maximize the number of your channels. Keep channels open and allow their cost to be amortized over multiple cycles, rather than closing them after their liquidity has been depleted. 28 | 29 | Needs Attention: Some fee ranges may be marked in red, indicating that no channels in that fee range have sufficient inbound capacity left. You may empty these channels by pushing satoshis out, for example into cold storage using Lightning Loop, or alternatively close them. 30 | 31 | [Read more: Liquidity Management for Lightning Merchants](../../the-lightning-network/liquidity/liquidity-management-for-lightning-merchants.md) 32 | 33 | Lightning Terminal’s Liquidity Report for now only takes into account local information, that is information gathered directly from your node. It visualizes available inbound capacity ordered by their remote fee, but does not take into account the quality of the inbound capacity. Channels might not always be useful for routing or receiving payments, for example in cases where the peer themselves lacks inbound capacity. 34 | -------------------------------------------------------------------------------- /docs/lnd/release-notes/release-notes-0.17.1.md: -------------------------------------------------------------------------------- 1 | # Release Notes 2 | - [Bug Fixes](#bug-fixes) 3 | - [New Features](#new-features) 4 | - [Functional Enhancements](#functional-enhancements) 5 | - [RPC Additions](#rpc-additions) 6 | - [lncli Additions](#lncli-additions) 7 | - [Improvements](#improvements) 8 | - [Functional Updates](#functional-updates) 9 | - [RPC Updates](#rpc-updates) 10 | - [lncli Updates](#lncli-updates) 11 | - [Breaking Changes](#breaking-changes) 12 | - [Performance Improvements](#performance-improvements) 13 | - [Technical and Architectural Updates](#technical-and-architectural-updates) 14 | - [BOLT Spec Updates](#bolt-spec-updates) 15 | - [Testing](#testing) 16 | - [Database](#database) 17 | - [Code Health](#code-health) 18 | - [Tooling and Documentation](#tooling-and-documentation) 19 | 20 | # Bug Fixes 21 | 22 | * A bug that caused certain API calls to hang [has been fixed](https://github.com/lightningnetwork/lnd/pull/8158). 23 | 24 | * [LND now sets the `BADONION`](https://github.com/lightningnetwork/lnd/pull/7937) 25 | bit when sending `update_fail_malformed_htlc`. This avoids a force close 26 | with other implementations. 27 | 28 | * A bug that would cause taproot channels to sometimes not display as active 29 | [has been fixed](https://github.com/lightningnetwork/lnd/pull/8104). 30 | 31 | * [`lnd` will now properly reject macaroons with unknown versions.](https://github.com/lightningnetwork/lnd/pull/8132) 32 | 33 | # New Features 34 | ## Functional Enhancements 35 | 36 | - Previously, when a channel was force closed locally, its anchor was always 37 | force-swept when the CPFP requirements are met. This is now 38 | [changed](https://github.com/lightningnetwork/lnd/pull/7965) to only attempt 39 | CPFP based on the deadline of the commitment transaction. The anchor output 40 | will still be offered to the sweeper during channel force close, while the 41 | actual sweeping won't be forced(CPFP) unless a relevant HTLC will timeout in 42 | 144 blocks. If CPFP before this deadline is needed, user can use `BumpFee` 43 | instead. 44 | 45 | ## RPC Additions 46 | 47 | * [`chainrpc` `GetBlockHeader`](https://github.com/lightningnetwork/lnd/pull/8111) 48 | can be used to get block headers with any chain backend. 49 | 50 | ## lncli Additions 51 | 52 | # Improvements 53 | ## Functional Updates 54 | ## RPC Updates 55 | ## lncli Updates 56 | ## Code Health 57 | ## Breaking Changes 58 | ## Performance Improvements 59 | 60 | - When facing a large mempool, users may experience deteriorated performance, 61 | which includes slow startup and shutdown, clogging RPC response when calling 62 | `getinfo`, and CPU spikes. This is now improved with [the upgrade to the 63 | latest `btcwallet`](https://github.com/lightningnetwork/lnd/pull/8019). In 64 | addition, it's strongly recommended to upgrade `bitcoind` to version `v24.0` 65 | and above to take advantage of the new RPC method `gettxspendingprevout`, 66 | which will further decrease CPU usage and memory consumption. 67 | 68 | # Technical and Architectural Updates 69 | ## BOLT Spec Updates 70 | ## Testing 71 | ## Database 72 | ## Code Health 73 | ## Tooling and Documentation 74 | 75 | # Contributors (Alphabetical Order) 76 | * Eugene Siegel 77 | * Olaoluwa Osuntokun 78 | * Yong Yu 79 | -------------------------------------------------------------------------------- /lightning-network-tools/lnd/watchtower.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: >- 3 | Learn how to setup a watchtower, either as a client or as a server, to watch 4 | over your own or another node. 5 | --- 6 | 7 | # Configuring Watchtowers 8 | 9 | A [watchtower](../../the-lightning-network/payment-channels/watchtowers.md) is a feature of a Lightning node that allows you to watch a node for potential [channel breaches](../../the-lightning-network/payment-channels/lifecycle-of-a-payment-channel.md) (the watchtower server). This functionality comes bundled in LND, but needs to be specifically enabled. Two nodes can act as each other’s watchtowers, meaning they simultaneously operate in server and client mode. 10 | 11 | The watchtowers discussed here are altruistic, meaning there is no compensation or other incentive for these watchtowers to serve your node. 12 | 13 | Ideally, such a watchtower is provided by yourself, on a separate machine, network and location from your own node to protect yourself against channel breaches that may occur while your node is offline for any reason. 14 | 15 | ## Run a watchtower 16 | 17 | To run a watchtower, you will have to enable its server functionality. This is done by adding the following to your `lnd.conf` configuration file: 18 | 19 | `watchtower.active=1` 20 | 21 | Once you have restarted your node, you should be able to see your watchtower’s information with: 22 | 23 | `lncli tower info` 24 | 25 | Your watchtower has its own public key. If you have [configured Tor](quick-tor-setup.md), the command above will also return your tower’s unique onion. If the above command cannot be found (No help topic for 'tower'), you may have to make sure LND is [compiled](run-lnd.md) with the `watchtowerrpc` flag. 26 | 27 | ``` 28 | { 29 | "pubkey": "02f1158dd65fb7dad3d8274e39edcb8c03ff639365884ced2f143372b5fb050bc1", 30 | "listeners": [ 31 | "[::]:9911" 32 | ], 33 | "uris": [ "02f1158dd65fb7dad3d8274e39edcb8c03ff639365884ced2f143372b5fb050bc1@ddoi7crm7rhj2eyztcsv6iprclrxhmsquhaswef3xphhu2fin726w7ad.onion:9911" 34 | ] 35 | } 36 | ``` 37 | 38 | ## Connect your node to a watchtower 39 | 40 | To connect to a watchtower, you will have to enable the client functionality. This can be done by adding the following to your `lnd.conf` configuration file: 41 | 42 | `wtclient.active=1` 43 | 44 | Once you have restarted your LND node, you may add a watchtower with the following command: 45 | 46 | `lncli wtclient add 02f1158dd65fb7dad3d8274e39edcb8c03ff639365884ced2f143372b5fb050bc1@ddoi7crm7rhj2eyztcsv6iprclrxhmsquhaswef3xphhu2fin726w7ad.onion:9911` 47 | 48 | \ 49 | Using the wtclient commands you can also list your watchtowers, remove them or display stats or your watchtowers policy. 50 | 51 | `lncli wtclient add` 52 | 53 | `lncli wtclient remove` 54 | 55 | `lncli wtclient towers` 56 | 57 | `lncli wtclient tower` 58 | 59 | `lncli wtclient stats` 60 | 61 | `lncli wtclient policy` 62 | 63 | The sweep fee is expressed in satoshi per vByte and can be changed by adding or editing the following in your configuration file: 64 | 65 | `wtclient.sweep-fee-rate=10` 66 | --------------------------------------------------------------------------------