ok300 5f74b9df4b Restore: Associate swap tx IDs from onchain data (#399)
* Add extend_incomplete_failed_send_swaps() on first sync

* Find lockup txs

* Send Swaps: find refund txs

* Simplify recover_send_swap_tx_ids, add recover_receive_swap_tx_ids

* recover_receive_swap_tx_ids: batch tx lookups

* Move onchain-restore methods to own module

* Store restored data in own struct

* Fix CI: bump pubspec.lock dependencies

* LiquidChainService: add get_scripts_history_electrum()

* restore_onchain: rely on batch call to fetch histories of all known swaps

* Rename get_scripts_history_electrum

* Rename restore_onchain.rs, flatten onchain inner module

* Rename ImmutableDb to SwapsList

* Simplify logic in restore.rs

* restore.rs: Add chain swap support, simplify logic

* restore.rs: add logging when script retrieval fails

* restore.rs: remove unused field create_resp

* restore.rs: rename SwapCompositeData to SwapHistory

* restore.rs: allow unused fields in simulated immutable data

* restore.rs: cargo fmt

* Cargo fmt

* Fix failing test

* When fetching script history, also fetch if tx is confirmed or not

* Recover send swaps: fetch claim tx IDs

* Recover onchain data: persist reconstructed swaps

* Simplify recover_from_onchain: store swap txs per swap ID

* Receive swaps: do not treat lockup/claim txs as pair

* Clarify meaning of partial swap state

* Cargo clippy

* Receive Chain Swap: distinguish BTC lockup from claim/refund tx

* Send Chain Swap: distinguish BTC lockup/claim by vout, not by history order

* get_partial_state: default to Created when state is unclear

* Receive Chain Swaps: differentiate BTC refund from BTC claim txs

* Send Swaps: clarify reason for defaulting to TimedOut on no lockup

* Chain swaps: add docs for meaning of server, user txs

* Recover Receive swaps: cover the case when only the lockup is available

* HistoryTxId: store confirmation block height

* Receive swaps: differentiate claim tx from swapper refund tx

* recover_from_onchain: extract immutable DB (swaps list) as arg

* Rename get_partial_state to derive_partial_state

* Restore: remove validation steps

* Restore chain swaps: treat as Complete only when claim is confirmed

* Fix clippy warnings

* Remove restore call from sync call
2024-08-30 17:18:25 +00:00
2024-07-09 17:25:05 +02:00
2024-06-18 09:34:47 +02:00
2024-04-29 21:49:52 +02:00
2024-08-05 16:29:07 -04:00

Breez SDK - Liquid

Overview

The Breez SDK provides developers with a end-to-end solution for integrating self-custodial Lightning payments into their apps and services. It eliminates the need for third-parties, simplifies the complexities of Bitcoin and Lightning, and enables seamless onboarding for billions of users to the future of peer-to-peer payments.

To provide the best experience for their end-users, developers can choose between the following implementations:

The Breez SDK is free for developers.

What Is the Liquid Implementation?

The Liquid implementation is a nodeless Lightning integration. It offers a self-custodial, end-to-end solution for integrating Lightning payments, utilizing the Liquid Network with on-chain interoperability and third-party fiat on-ramps.

Core Functions

  • Sending payments via protocols such as: bolt11, lnurl-pay, lightning address, btc address.
  • Receiving payments via protocols such as: bolt11, lnurl-withdraw, btc address.
  • Interacting with a wallet e.g. balance, max allow to pay, max allow to receive, on-chain balance.

Key Features

  • On-chain interoperability
  • LNURL functionality
  • Multi-app support
  • Multi-device support
  • Real-time state backup
  • Keys are only held by users
  • Fiat on-ramps
  • Open-source

Getting Started

Head over to the Breez SDK - Liquid documentation to start implementing Lightning in your app.

API

API documentation is here.

Command Line

The Breez SDK - Liquid cli is a command line client that allows you to interact with and test the functionality of the SDK.

Support

Have a question for the team? Join our Telegram channel or email us at contact@breez.technology

How Does the Liquid Implementation Work?

The Liquid implementation uses submarine swaps and reverse submarine swaps to send and receive payments, enabling funds to move frictionlessly between the Lightning Network and the Liquid sidechain.

Breez SDK - Liquid

When sending a payment the SDK performs a submarine swap, converting L-BTC from a users Liquid wallet into sats on the Lightning Network, and sends them to the recipient.

When receiving a payment, the SDK performs a reverse submarine swap, converting incoming sats into L-BTC, and then deposits them in the users Liquid wallet.

Build & Test

  • cli: Contains the Rust command line interface client for the SDK - Liquid.
  • lib: Contains the root Rust cargo workspace.
    • bindings: The ffi bindings for Kotlin, Flutter, Python, React Native, and Swift.
    • core: The core SDK - Liquid rust library.
  • packages: Contains the plugin packages for Dart, Flutter, and React Native.

Within each sub-project readme, there are instructions on how to build, test, and run.

SDK Development Roadmap

  • Send/Receive Lightning payments
  • CLI Interface
  • Foreign languages bindings
  • Export/Import SDK data
  • Pay BTC on-chain
  • Receive via on-chain address
  • LNURL-Pay
  • LNURL-Withdraw
  • Send to a Lightning address
  • Receive via Lightning address
  • Real-time sync
  • Webhook for receiving payments
  • Offline receive via notifications
  • Offline swaps via notifications
Description
No description provided
Readme MIT 6.1 MiB
Languages
Rust 55.2%
Dart 23.3%
Swift 7.9%
Kotlin 6.7%
C 3.3%
Other 3.4%