lnswap / lnstxbridge Goto Github PK

need to add/validate LP client version checks to avoid compatibility issues.

Hi! In my last transaction the STX transfer went through, but I also received a BTC refund.

Need to investigate why lockstx nonces are so high, causes these txns to get stuck in mempool.

issue is related to manual nonce tracking.

This will track sbtc support on LNSwap

in rare cases, it's possible for the aggregator to mark a confirmed tx as in mempool which sets the swap in a wrong state.

06/01/2023 01:40:44:943 ESC[36mverboseESC[39m: s.1711 updateSwapStatus with 29e9l3, transaction.confirmed, 

06/01/2023 01:40:44:975 ESC[34mdebugESC[39m: Swap 29e9l3 update: {
  "status": "transaction.confirmed",
  "transaction": {}
}

06/01/2023 01:40:45:214 ESC[36mverboseESC[39m: s.1711 updateSwapStatus with 29e9l3, astransaction.mempool, 

06/01/2023 01:40:45:235 ESC[34mdebugESC[39m: Swap 29e9l3 update: {
  "status": "astransaction.mempool",
  "txId": "740fd7155dc666a3231143b636f2211bee54f2fe89d64d286cd3eff3fcd94502",
  "transaction": {
    "id": "740fd7155dc666a3231143b636f2211bee54f2fe89d64d286cd3eff3fcd94502"
  }
}

This will ensure backend can be used as an API, currently frontend handles this.

maxlimit should be dynamically checked by a balance query while accepting swap.

when an LP does not have good channel connections or good liquidity, the swap attempt fails.

aggregator should be able to intercept this error message and continue trying to find a suitable LP until swap request succeeds or fails.

ref: https://discord.com/channels/928550468328767518/928864225164664832/1077083727093563432

due to random amounts and minimum checks, some swaps fail with this error before moving on to lockstx step.

Need to check if there's an issue while aggregator is contacting providers that may lead to below error.

User succeeded in 2nd attempt

these should be tracked per chain because stacks blocks are not 1-to-1 with bitcoin blocks. they drift by about %15.

so expirychecks should be improved per chain/timeoutblockheight.

Currently stacks-blockchain-api doesn't have a way to subscribe to blocks so we periodically check blockheight but now stacksnursery has no access to this information and can't check for expired swaps.

This leads to hold invoices not being canceled, which leads to channel force closures.

Requested this feature: hirosystems/stacks-blockchain-api#815

Need to apply a workaround meanwhile to avoid remote force closed channels, work ongoing with this commit: pseudozach@768159e

        "channel_point": "00fb018580b0abf1ec0e94efa6450a4192cd0870ec1520fdc73c15bc08a78b78:1",
        "chan_id": "772749966163968001",
        "chain_hash": "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f",
        "closing_tx_hash": "bac8bbb1ce41cacae2f6a78b7be8a5317305fe49b9327d46f763b3ad3f95b3d7",
        "remote_pubkey": "02a90e3f7e3782bdd9b2da75dd6036122d589e5fc8ce0171ef9695b88f1f3b3320",
        "capacity": "3125131",
        "close_height": 703753,
        "settled_balance": "525528",
        "time_locked_balance": "0",
        "close_type": "REMOTE_FORCE_CLOSE",
        "open_initiator": "INITIATOR_REMOTE",
        "close_initiator": "INITIATOR_REMOTE",
        "resolutions": [
            {
                "resolution_type": "INCOMING_HTLC",
                "outcome": "TIMEOUT",
                "outpoint": {
                    "txid_bytes": "d7b3953fadb363f7467d32b949fe057331a5e87b8ba7f6e2caca41ceb1bbc8ba",
                    "txid_str": "bac8bbb1ce41cacae2f6a78b7be8a5317305fe49b9327d46f763b3ad3f95b3d7",
                    "output_index": 0
                },
                "amount_sat": "9116",
                "sweep_txid": ""
            },
            {
                "resolution_type": "COMMIT",
                "outcome": "CLAIMED",
                "outpoint": {
                    "txid_bytes": "d7b3953fadb363f7467d32b949fe057331a5e87b8ba7f6e2caca41ceb1bbc8ba",
                    "txid_str": "bac8bbb1ce41cacae2f6a78b7be8a5317305fe49b9327d46f763b3ad3f95b3d7",
                    "output_index": 1
                },
                "amount_sat": "525528",
                "sweep_txid": "1667fbb2595bc57972337b35185737cb8ec094e8dfaa34b2765de3a9a7eb6d9d"
            }
        ]
    },

aggregator should check minimum amount a provider accepts (as per config not available balance) to ensure unnecessary selection errors are avoided.

as @pors.btc reported, backend seems to stop getting block from the websocket so need to add additional checks/reconnect logic.

https://explorer.stacks.co/txid/SP2507VNQZC9VBXM7X7KB4SF4QJDJRSWHG4V39WPY.stxswap_v8?chain=mainnet

Need to update all references to stacks.co nodes to hiro API as per announcement: https://forum.stacks.org/t/domain-migrations-for-hiro-hosted-services/14609

If client bitcoind zmqnotifications or firewall is not properly configured, this leads to client not receiving btc tx which lead to swaps quietly failing.

aggregator - client api should report this status or misconfigurations might lead to poor performance of a provider.

Looks like @stacks/transaction package doesn't properly calculate nonce if there's already a tx in mempool. Is there a better way? Should stackschainclient calculate and keep an internal count of nonce?

error:

"status": "transaction.failed"
"failureReason": "onchain coins could not be sent"
"error":"transaction rejected","reason":"ConflictingNonceInMempool"

upgrade the node to https://github.com/blockstack/stacks-blockchain/releases/tag/2.0.11.4.0
and integrate /v2/fees/transaction to see if it helps confirmation times.

during mempool congestion, some transactions fail to be claimed on BTC due to low fee.

Details:
Currently mempool is congested

Right now aggregator bitcoin node has mempoolinfo:

bitcoin-cli getmempoolinfo
{
"loaded": true,
"size": 24930,
"bytes": 89551553,
"usage": 222151104,
"total_fee": 11.14205283,
"maxmempool": 300000000,
"mempoolminfee": 0.00002187, ---> 0.00002187 * 100000000 = 2187/kb = 2.135 sat/vB
"minrelaytxfee": 0.00001000,
"unbroadcastcount": 0
}

LP client prepared this tx with 272 sat fee, claim tx vsize is 136 which is 2 sat/vB as stated in code:
https://github.com/LNSwap/lnstxbridge-client/blob/main/lib/chain/ChainClient.ts#L199

so we end up with this error:

Best solution is to run a mempool.space on the aggregator to help with fee estimation and allow LPs to utilize it.