• #37
• Run tests
• Check uniffi bindings
• Check flutter bindings

We should expose a method on the wallet to expose its information. Currently, its balance and public key should be enough, but I'm open to other suggestions.

See specification here: https://github.com/satoshilabs/slips/blob/master/slip-0077.md

We currently set the blinding variant in init_wallet:

    let desc = singlesig_desc(
        &signer,
        Singlesig::Wpkh,
        lwk_common::DescriptorBlindingKey::Elip151,
        false,
    );

If the blinding keys can be derived from the wallet's seed, then we don't have to store it for each tx.

This issue proposes to:

• create two util methods derive_blinding_private_key and derive_blinding_public_key
• replace the storing of the blinding key by calling the utils

Let the user specify which amount he wants to set

• the invoice amount (e.g. how many sats will be paid by the sender) with CreateSwapRequest::new_lbtc_reverse_invoice_amt
• the onchain amount (e.g. how many L-sats should arrive in the Liquid wallet) with CreateSwapRequest::new_lbtc_reverse_onchain_amt

Migrate Dart/Flutter packages from frb v2 playground repository for liquid project to this repository.

Our try_resolve_pending_swap does not consider the case when a swap is in transaction.refunded state.

This depends on SatoshiPortal/boltz-rust#42 .

As previously discussed, we should:

• Set a limit to the number of pending sends, 3 seems a good amount
• Store the necessary information for recovery in the temporary persister
• Find a way to compress, encrypt and backup this information so it can be persisted in some form of storage provider (e.g. Android/iCloud keychain, Google Drive etc.). Should be handled in #65 mostly.

Importing the mnemonic into Blockstream Green, the balance for the Native Segwit Liquid wallet (p2wpkh) shows zero and no send / receive txs.

However, the CLI shows a non-zero balance.

It seems that on the send case where we initiate the lockup transaction, boltz doesn't wait for confirmation when the payment is less than 100k sats but pays the invoice and broadcast immediately the claim transaction.
So we should return immediately after we detect the claim in the mempool with payment success.
We can do the same for receive case where We don't need to wait for the swapper lockup tx to confirm and we can initiate the claim immediately after we see the lockup in the mempool.

This is fine for the CLI, as it's used for tests, but not as a generic mechanism in lib.

Since we have the requirement of working on multiple devices simultaneously we need some sort of sync mechanism.
Best would be to use the chain as single source of truth if possible.
Since the onchain wallet has the ability to recover confirmed transactions, we only need to handle pending transactions for the send use-case (our lockup that are not claimed).
Since we generate the keys to be able to refund (we send the pubkey to boltz to include in the script) we can generate them in a recoverable way (using a derivation path of our wallet master key).
So For every lockup that is not spend (claimed) we need to recover its corresponding refund key and create the refund tx.

Let's discuss that option.

Originally posted by @hydra-yse in #32 (comment)

• Update list_payments
• Update DB (e.g. populate both amount fields when inserting)

It's referenced in a few bindings (for example here: https://github.com/breez/breez-sdk-liquid/pull/97/files#diff-533b462261cd8fce8f8c58f3501c3c2c30dbd906ee0058174af25d59eddd88fdR81)

We'll also need it when we release this SDK.

Perhaps use the same semantic as in the sdk? prepare_receive_payment ?

The more swaps were created and failed to complete, the more threads are opened, even after restarting the app.

[2024-03-22T21:41:25Z INFO  electrum_client::raw_client] Trying to connect to 35.201.74.156:465 (attempt 1/1) with timeout 100s
[2024-03-22T21:41:25Z INFO  electrum_client::raw_client] Trying to connect to 35.201.74.156:465 (attempt 1/1) with timeout 100s
[2024-03-22T21:41:25Z INFO  electrum_client::raw_client] Trying to connect to 35.201.74.156:465 (attempt 1/1) with timeout 100s
[2024-03-22T21:41:25Z INFO  electrum_client::raw_client] Trying to connect to 35.201.74.156:465 (attempt 1/1) with timeout 100s
[2024-03-22T21:41:25Z INFO  electrum_client::raw_client] Trying to connect to 35.201.74.156:465 (attempt 1/1) with timeout 100s
[2024-03-22T21:41:25Z INFO  electrum_client::raw_client] Trying to connect to 35.201.74.156:465 (attempt 1/1) with timeout 100s
[2024-03-22T21:41:25Z INFO  electrum_client::raw_client] Trying to connect to 35.201.74.156:465 (attempt 1/1) with timeout 100s
[2024-03-22T21:41:25Z INFO  electrum_client::raw_client] Trying to connect to 35.201.74.156:465 (attempt 1/1) with timeout 100s
[2024-03-22T21:41:25Z INFO  electrum_client::raw_client] Trying to connect to 35.201.74.156:465 (attempt 1/1) with timeout 100s
[2024-03-22T21:41:25Z INFO  electrum_client::raw_client] Trying to connect to 35.201.74.156:465 (attempt 1/1) with timeout 100s
[2024-03-22T21:41:25Z INFO  electrum_client::raw_client] Trying to connect to 35.201.74.156:465 (attempt 1/1) with timeout 100s
[2024-03-22T21:41:25Z WARN  breez_sdk_liquid::wallet] Could not claim yet. Err: Wrong response received from Boltz servers
[2024-03-22T21:41:25Z WARN  breez_sdk_liquid::wallet] Could not claim yet. Err: Wrong response received from Boltz servers
[2024-03-22T21:41:25Z WARN  breez_sdk_liquid::wallet] Could not claim yet. Err: Wrong response received from Boltz servers
[2024-03-22T21:41:25Z WARN  breez_sdk_liquid::wallet] Could not claim yet. Err: Wrong response received from Boltz servers
[2024-03-22T21:41:25Z WARN  breez_sdk_liquid::wallet] Could not claim yet. Err: Wrong response received from Boltz servers
[2024-03-22T21:41:25Z WARN  breez_sdk_liquid::wallet] Could not claim yet. Err: Wrong response received from Boltz servers
[2024-03-22T21:41:25Z WARN  breez_sdk_liquid::wallet] Could not claim yet. Err: Wrong response received from Boltz servers
[2024-03-22T21:41:25Z WARN  breez_sdk_liquid::wallet] Could not claim yet. Err: Wrong response received from Boltz servers
[2024-03-22T21:41:25Z WARN  breez_sdk_liquid::wallet] Could not claim yet. Err: Wrong response received from Boltz servers
[2024-03-22T21:41:25Z WARN  breez_sdk_liquid::wallet] Could not claim yet. Err: Wrong response received from Boltz servers
[2024-03-22T21:41:25Z WARN  breez_sdk_liquid::wallet] Could not claim yet. Err: Wrong response received from Boltz servers
[2024-03-22T21:41:30Z INFO  electrum_client::raw_client] Trying to connect to 35.201.74.156:465 (attempt 1/1) with timeout 100s
[2024-03-22T21:41:30Z INFO  electrum_client::raw_client] Trying to connect to 35.201.74.156:465 (attempt 1/1) with timeout 100s
[2024-03-22T21:41:30Z INFO  electrum_client::raw_client] Trying to connect to 35.201.74.156:465 (attempt 1/1) with timeout 100s
[2024-03-22T21:41:30Z INFO  electrum_client::raw_client] Trying to connect to 35.201.74.156:465 (attempt 1/1) with timeout 100s
[2024-03-22T21:41:30Z INFO  electrum_client::raw_client] Trying to connect to 35.201.74.156:465 (attempt 1/1) with timeout 100s
[2024-03-22T21:41:30Z INFO  electrum_client::raw_client] Trying to connect to 35.201.74.156:465 (attempt 1/1) with timeout 100s
[2024-03-22T21:41:31Z INFO  electrum_client::raw_client] Trying to connect to 35.201.74.156:465 (attempt 1/1) with timeout 100s
[2024-03-22T21:41:31Z INFO  electrum_client::raw_client] Trying to connect to 35.201.74.156:465 (attempt 1/1) with timeout 100s
[2024-03-22T21:41:31Z INFO  electrum_client::raw_client] Trying to connect to 35.201.74.156:465 (attempt 1/1) with timeout 100s
[2024-03-22T21:41:31Z INFO  electrum_client::raw_client] Trying to connect to 35.201.74.156:465 (attempt 1/1) with timeout 100s
[2024-03-22T21:41:31Z INFO  electrum_client::raw_client] Trying to connect to 35.201.74.156:465 (attempt 1/1) with timeout 100s
[2024-03-22T21:41:31Z WARN  breez_sdk_liquid::wallet] Could not claim yet. Err: Wrong response received from Boltz servers
[2024-03-22T21:41:31Z WARN  breez_sdk_liquid::wallet] Could not claim yet. Err: Wrong response received from Boltz servers
[2024-03-22T21:41:31Z WARN  breez_sdk_liquid::wallet] Could not claim yet. Err: Wrong response received from Boltz servers
[2024-03-22T21:41:31Z WARN  breez_sdk_liquid::wallet] Could not claim yet. Err: Wrong response received from Boltz servers
[2024-03-22T21:41:31Z WARN  breez_sdk_liquid::wallet] Could not claim yet. Err: Wrong response received from Boltz servers
[2024-03-22T21:41:31Z WARN  breez_sdk_liquid::wallet] Could not claim yet. Err: Wrong response received from Boltz servers
[2024-03-22T21:41:31Z WARN  breez_sdk_liquid::wallet] Could not claim yet. Err: Wrong response received from Boltz servers
[2024-03-22T21:41:31Z WARN  breez_sdk_liquid::wallet] Could not claim yet. Err: Wrong response received from Boltz servers
[2024-03-22T21:41:31Z WARN  breez_sdk_liquid::wallet] Could not claim yet. Err: Wrong response received from Boltz servers
[2024-03-22T21:41:31Z WARN  breez_sdk_liquid::wallet] Could not claim yet. Err: Wrong response received from Boltz servers
[2024-03-22T21:41:31Z WARN  breez_sdk_liquid::wallet] Could not claim yet. Err: Wrong response received from Boltz servers

There should ideally be a single thread that iterates over pending or ongoing swaps.

This is a tracking issue describing the necessary features for the Liquid to Lightning swaps POC.
The implementation should be split into two phases, ideally:

(FINISHED) PHASE 1 - Using Boltz Testnet Exchange:

• Add support for lwk, generate wallets and fund them
• Add lightning node management (single-node)
• Implement normal_submarine_swap
• Implement reverse_submarine_swap

PHASE 2 - Creating our own Swapper:

• Adding lightning node management (multiple-nodes)
• Remove Boltz client and implement custom swapper
• Fix swap methods to use the custom swapper

Right now, the claim tx absolute fee is hardcoded to 134 sats.

However, we need a more reliable way to determine this dynamically.

For example, the minimum fee on Liquid is 0.1 sat/vB. One solution could be to calculate the absolute fee based on this feerate.

Another idea is to use the claim tx fee returned by Boltz in the swap creation response.

send-payment lnbc10u1pnp8fa5pp5metdkaj36l7ntaglv5tqvazw26czrpnxclx4xcwda8kq2r7wmkyscqpjsp5g8dnxtytte5y20p8a0h3vnxxkh4cztculp6currjsa9sj4a3j0as9q7sqqqqqqqqqqqqqqqqqqqsqqqqqysgqdqqmqz9gxqyjw5qrzjqwryaup9lh50kkranzgcdnn2fgvx390wgj5jd07rwr3vxeje0glcll69wq3zjrksrqqqqqlgqqqqqeqqjqxgav46y0vue50zhsl46kjln38agnfnxhtym3xrv47fx2vq75vxhhehq9l5el8kre5flfq6gtnf3wehjmf2zf3hzfh682hdwue3ecuvcpvqrh4r

Error: Generic boltz error: HTTP(Status(400, Response[status: 400, status_text: Bad Request, url: https://api.boltz.exchange/createswap]))

This issue should follow after #4. The idea is to be able to backup/sync/restore data throughout different wallet instances. Ideally, we should restore:

• A list of pending/completed transactions
• Optional wallet settings (if any)

Moreover, we should keep in mind to which degree a local storage is really necessary, as there should be ways to fetch the transaction history directly from the Liquid chain with a scan (could be optimized by only fetching the utxo set history pertaining to a certain (saved) txid, though there is some investigation to be done, we can start with scanning the whole chain and checking the history one by one)

For example receive-payment has --onchain-amount-sat and --invoice-amount-sat.
I would also not give the option to have two options here, I think invoice paying is always about how much the payer pays so I suggest to remove the options here. The fee is included in the response anyway.

As of right now, if the folder doesn't exist, any app using the lib will fail to startup.

Currently the lwk_wollet persists all its cache in the .wollet directory, but it seems like the data is getting written at every launch rather than being added when necessary

Similarly to the SDK, we should add support for UniFFI and flutter/RN binding generation

Depending on the network used, a different DB file should be used.

One way to solve this is to have a different subfolder under data_dir, then store the respective DB file under the correct path.

All the methods defined in #4 , #5 and #6 should have a cli counterpart, so that they can be interactively tested and used.

Trying to receive on mainnet in CLI fails to complete. The output shows

[2024-04-23T16:22:28Z ERROR ls_sdk::wallet] [Ongoing Receive] Could not contact Boltz servers for claim status                                                    
[2024-04-23T16:22:33Z ERROR ls_sdk::wallet] [Ongoing Receive] Could not contact Boltz servers for claim status                                                                  
[2024-04-23T16:22:38Z ERROR ls_sdk::wallet] [Ongoing Receive] Could not contact Boltz servers for claim status 

In the sending LN wallet, the outgoing payment appears as pending or queued.

This happens only on mainnet. It works well on testnet.

Add a short section in the library README.md describing how an app integrating the library would backup and restore.

I think it is better especially when more and more fields will be added.

The implementation needs to support the following:

• #13
• #16
• #19

The logs of the previous run get wiped when the CLI is restarted.

We should instead append to the log.

This let the user think the payment succeed while it is still pending.
If we want to return before waiting for confirmation (also on receive) we need to add a pending status for the payments.
Currently the payment is marked as sent while it is still in pending.

Currently when receiving, all funds are sent to the same Liquid address (active_address).

We should always derive and use a different address for each receive.

This tracking issue aims at defining both the necessary and long-term features which are planned to be implemented:

Priority Issues

• #4
• #5
• #6
• #7

Secondary Issues

• #8
• #9
• #10

In this project, we're always fetching it from Boltz with BoltzApiClient::swap_status. This can leave us exposed to issues like BoltzExchange/boltz-backend#537 , causing us to fail to fetch the swap status and therefore fail to complete the swap (#104).

In contrast, in Breez SDK we're calculating the swap status ourselves: https://github.com/breez/breez-sdk/blob/2c1bcfced2cf36fa9f7baee5de8bbb1c81838c1e/libs/sdk-core/src/models.rs#L1450

We should fallbacks and redundancies, to make us resilient to the error above.

A few possible ideas:

• instead of BoltzApiClient::swap_status we calculate the status ourselves
• we first try BoltzApiClient::swap_status, then if it fails, we fallback to our own calculation
• we first try the v2 Boltz API (fastest), then if it fails the v1 BoltzApiClient::swap_status, then our calculation