boltzexchange / boltz-backend Goto Github PK

The gRPC stream SubscribeInvoices just shows events about invoices that got paid. But it should also forward data about invoices that couldn't be paid for some reason so that the middleware can tell the frontend that the Swap failed.

Service.ts should throw errors if an argument has the wrong type or is obviously invalid (negative rate, ...)

Right now Boltz just generates a new mnemonic if there is none found on the disk.

This issue is about setting up a new Boltz instance with an existing mnemonic, recovering the funds sent to the addresses and detecting which addresses were used already.

Right now a CLI command to refund a swap looks like this:

boltz-cli refundswap <network> <lockup_transaction> <redeem_script> <timeout_block_height> <refund_private_key> <destination_address> [fee_per_byte]

Six CLI arguments are hard to deal with and therefore we should use something like Inquirer.js to have a question answer like CLI interface.

Right now the wallet gets the UTXOs sorted by value and by whether the are confirmed (it prefers UTXOs that were included in a block of course):

      order: [
        ['value', 'DESC'],
        ['confirmed', 'DESC'],
      ],

This is not the best things to do because we will end up with many small UTXOs and therefore high transaction fees in the long term. The wallet should search for UTXOs with a value that is a little bit higher than the requested amount (the little bit more is for fees) while avoiding dust to change addresses. Accumulating two small UTXOs is also better than always spending the biggest one.

Any opinions on this? @peartobear @ImmanuelSegol

LTCD does not support the estimateFee method of BTCD. I discovered this in #35 and just hardcoded a fee of 10 sat per vbyte to avoid not implemented errors by LTCD.

Now we have to find a way to estimate a fee to use. I can think of two possible solutions:

• use another full node implementation that has fee estimation methods for BTC and LTC. And since that full node implementation has to be compatible with LND the only option is Bitcoin Core and Litecoin Core
• implement our own fee estimation tool by iterating over the transaction in the latest blocks and in the mempool to determine a reasonable fee

(Or we could simply not care about fees in Litecoin since the blocks are never full but that is not a long term solution.)

What do you think? @ImmanuelSegol @peartobear

Bitcoin Core warning on startup: Config options rpcuser and rpcpassword will soon be deprecated. Locally-run instances may remove rpcuser to use cookie-based auth, or may be replaced with rpcauth. Please see share/rpcauth for rpcauth auth generation.

Reverse swaps are automatically refunded but timeouts for normal swap are currently not handled at all

Currently, Boltz throws cryptic error messages originating from respective daemons. Catch and decode them for a more comprehensible, human-friendly error message.

Switch "Reverse swap" with asset-⚡/asset and vice versa for normal swap.

A sample bot-message ofter completion of a successful swap:

[mainnet]: BTC-⚡/LTC

ID: LbeydT
Pair: LTC/BTC
Order side: sell
Onchain amount: 0.26355812 LTC
Lightning amount: 0.002 BTC
Fees earned: 0.00131122 LTC
Miner fees: 0.0000034 LTC
Routing fees: 0 satoshi

Problem statement: At this moment, it is not recommended to do a Boltz swap on Apple's iPhone or iPad devices simply because iOS and iPadOS don't allow for triggering the automated or manual download of files, ergo, the user is left stranded with refund.json file opened in the browser while doing a reverse swap with no way to either download the refund.json file or go back and continue the swap without it. This problem is detrimental to the adoption for Boltz because most wallets are mobile-first and use a built-in Safari browser extension to access different lapps.

Solution: Convert the refund.json file to a QR code in .png format We already generate QR code client-side for the lightning invoices. Parse the refund.json file and refactor the saving and loading logic to use the QR code. Apple devices allow for a swift download of .png file so the QR-fied version of the refund.json could help us work around this Apple bottleneck. Likewise, refactor the refund logic to accommodate reading from the QR code instead of json files. A QR code is easily portable across devices and it will improve the overall experience around Boltz. The QR code is alphanumeric and has the maximum char limit of 4,296, which is well within the range for the contents of refund.json file.

This is a WIP and all the discussion/improvements are welcome.

• Explore the QR code design to include Boltz refund logo and the trade ID explicitly written on the QR code. Look at QR codes for WeChat mini-programs
• Decide on whether to make this consistent across all devices or this would be Apple-only feature craved out of necessity. My vote: We should strive to have a uniform UX across all the devices.
• What is the best way to go about it from architectural POV, A next.js export module or an inbulit python script which runs client-side, parses the file, and creates the code.

Sometimes the gRPC command createSwap is stuck and has to be restarted to work

Followup to #142

With this new one we have 9 Discord commands now and I think I should improve the help command so that it actually shows how to use the commands instead of just listing them.

Listing the full command with all options in withdraw <OTP token> <currency> <address> <amount in whole coins *or* "all"> style would definitely help.

This page's on-chain amounts should always show amounts from the actual confirmed UTXO. At the moment it displays some previously estimated amount (or I don't know what really).

In an example boltz asked me to send 0.01183132 LTC. Which I did.

Then it shows this LTC amount:

Just read the amount info from the bitcoind/litecoind UTXO or (even easier) read it from the same data source that displayed the 0.01183132 to me in the previous step.

Goes without saying: for both directions - boltz receiving & sending.

Guage the feasibility of allowing users to claim 0-conf tx. Related Frontend issue [tbd]

Right now we are hardcoding the certificates of the Docker images of BTCD, LTCD and LND which is fine for now but eventually I think it is reasonable to do it similar to LND by letting the services generate their own certificates and mounting the folder of the certificates on the host machine.

Currently swaps can only be refunded if and when the transaction gets atleast one confirmation. Allow transactions to be refunded from mempool as well for smoother UX

If Boltz issues the invoice it can include something like "0.2 LTC boltz.exchange swap"

The integration tests are timing out from time to time on Travis. That shouldn't happen.

I think the reason for the timing out is that the BTCD and LTCD are generating about 433 blocks in the beginning of the tests to activate SegWit on the simnet and the LNDs need to catch up which takes longer than the test timeout of 10 seconds on slow machines.

One way to solve this is preparing SegWit activated simnet networks and LNDs that already have a channel to eachother and putting that setup into a Docker image.

Right now the Lightning invoices of reverse Swaps have no memo unlike the BIP21 payment request which have a description that looks like this

Submarine Swap to ${lightningCurrency}

• based on taproot/musig2
• l-btc/btc only so far

Once the SwapManager gets an invoice it should tell LND to calculate a route to pay it so that we can use SendToRoute instead of SendPayment. This should result in faster Swap executions and maybe we can also tell the user that he shouldn't bother sending onchain coins if his invoice can't be paid anyways.

If the timeout expires The SwapManager should automatically refund failed reverse swaps.

The wallet should never send amounts that are smaller than a predefined value to change addresses but add them to the fee instead. This dust value should be configurable on a per chain basis.

The latest version of bitcoinjs-lib, 5.1.0, adds support for PSBT and deprecates some classes we are using right now. This should be refactored

GetInfo returns Error: 2 UNKNOWN: Unknown Error if one or more services of which the status should be shown is not available. Instead of doing that it should print the individual error messages of the services and show them to the user so that he can deal with the errors.

Right now the config parsing is a mess. We should refactor it so that it works properly.

One feature that would be nice to have is parsing the config files of the services Boltz connects to so that the user can simply copy paste the path to the config file instead of values for the host, port, SSL certificate and in case of LND the macaroon file.

It would be nice to have #37 and #43 before

All pending Swaps and reverse Swaps should be saved to the database so that the information about them isn't lost if Boltz crashes or gets restarted while a Swap is in progress.

We should follow the BIP-84 for derivation paths. Right now we are using the same path for every key of a currency which is messy and will make recovering from a mnemonic really hard and inefficient.

I propose to use the standardized path:

m / purpose' / coin_type' / account' / change / address_index

For example if we use the coin_type 0 for Bitcoin:

Keys P2PKH address would have the path:

m / 44' / 0' / 0' / change / address_index

Keys for P2SH nested P2PKH addresses:

m / 49' / 0' / 0' / change / address_index

Keys for P2WPKH addresses:

m / 84' / 0' / 0' / change / address_index

If we want to add another coin, for example Litecoin, we simply increment the coin_type. The keys for P2PKH Litecoin addresses would have the path:

m / 44' / 1' / 0' / change / address_index

The keys for swaps and reverse swaps should have a different purpose'

The business model of Boltz providers is to charge fees on every swap. But how should that be done? Solely via the rate or with an extra parameter for CreateSwap and CreateReverseSwap that adds a specific amount to the funds the user should send?

Also: should there be a flat fee for every swap, a fee in percent or both?

For the wallet this depends on #41 to be merged and means that all addresses should be rescanned and checked for new UTXOs.

For normal Swaps this depends on #45 and means that the addresses should be rescanned and the Swaps executed if there were funds sent to them. One also has to make sure that the Swap wasn't refunded by the user while Boltz was offline.

Reverse Swaps are a little bit trickier because there are edge cases in which Boltz crashed, was restarted or offline while the LND was operating normally. Therefore after a restart the invoices of all pending reverse Swaps should be checked on whether they are settled (and the onchain funds claimed) so that Boltz doesn't try to refund successful reverse Swaps.

The wallet currently doesn't support creating replaceable transactions. Implementing this feature would help replace existing transaction with one with a higher fees to avoid HTLC time outs.

The timeout for the Swap scripts is bestBlockHeight + 10 right now. To make that configurable the RPC methods CreateSwap and CreateReverseSwap should take some kind of timeout as parameter.

I would suggest a relative block height instead of an absolute. So that if the middleware sets timeoutBlockHeight = x the backend gets the height of the best block and adds x to it.

Also the default timeout should be configurable for each chain. 10 blocks on Bitcoin take a longer amount of time than 10 blocks on Litecoin or Ethereum statistically speaking.

The wallet should not only use it's default fee but also accept the fee per vbyte for the transaction as parameter.

The BIP70 payment protocol is used by BitPay and unfortunately their are still a popular with merchants.

Therefore I think that Boltz should be able to parse and pay BIP70 payment requests as onchain parts of a swap. This would allow the users to pay those invoices with any wallet of their choice (only the BitPay, Copay and forks of that wallet support BIP70).

Creating unsigned or partially signed transactions to be passed around to multiple signers is currently implementation dependent, making it hard for people who use different wallet software from being able to easily do so. Implementing PSBT support will help tackle this issue by allowing even offline signers to sign transactions without needing direct access to the UTXO set and without risk of being defrauded.

PSBT would be nice for refund and claim transactions. With PSBT the signing of those transaction wouldn't need to happen in the browser but could be in a wallet that supports PSBT.

• getaddress btc, getaddress ltc
• remote/local channel balance exhausted alerts. threshold configurable.
• withdraw x.x btc, withdraw x.x ltc (fixed address) OTP required
• high number of failed swaps from same IP - alert
• newaddress btc, newadress ltc (includes above commands listing all addresses, indicating which ones were (used). Sorted by top newest to bottom oldest.
• getlockedfunds btc, getlockedfunds ltc
• getpendingswaps
• htlctimelockconfig <pairid> <timeout in minutes> OTP required
• gethtlctimelockconfig

All these commands should also have a CLI implementation, to avoid Discord as a single point of failure.

The generation of BIP21 payment requests should be moved to the middleware since it is too high level and specific to be included in the backend.

Right now we are just trying to reconnect BTCD, LTCD or one of the LNDs if the initial connection on startup fails. We should also implement a reconnect logic if request or streaming call in the case of LND fails while Boltz is running.

The Boltz gRPC client of the middleware could be used as reference.