Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bug]: sweep transaction not recognized by on-chain wallet #7181

Open
dannydeezy opened this issue Nov 19, 2022 · 9 comments
Open

[bug]: sweep transaction not recognized by on-chain wallet #7181

dannydeezy opened this issue Nov 19, 2022 · 9 comments
Labels
bug Unintended code behaviour mempool P1 MUST be fixed or reviewed utxo sweeping

Comments

@dannydeezy
Copy link

Background

LND performed some type of sweep on an anchor output, but this tx was not registered in the lnd on-chain wallet, so the input it used to fund the sweep still appears unspent, but it is spent by a tx in my mempool

note i'm running a larger than normal mempool

Your environment

  • version of lnd latest
  • which operating system (uname -a on *Nix) ubuntu
  • version of btcd, bitcoind, or other backend bitcoind
  • any other relevant environment details
@dannydeezy dannydeezy added bug Unintended code behaviour needs triage labels Nov 19, 2022
@dannydeezy
Copy link
Author

i guess some sweep happend

SWPR: Creating sweep transaction 3c0f4964e5eb1795e058f74d3fd998fa1f1f6bf583218cea61ee54021a265c23 for 2 inputs (da9596f83f6802a432d9a69d6f56289886a4f602a6620c4f9ebce1c915593b6f:0 (CommitmentAnchor), ee2b82a8a45199d62ef4d1bf811100a7ec662483003e9030b28b4eae3de2fdbc:1 (TaprootPubKeySpend)) using 253 sat/kw, tx_weight=725, tx_fee=0.00000183 BTC, parents_count=0, parents_fee=0 BTC, parents_weight=0

LNWL: Inserting unconfirmed transaction 3c0f4964e5eb1795e058f74d3fd998fa1f1f6bf583218cea61ee54021a265c23

but when i do listunspent, that second input shows up here still

		{
			"address_type": 4,
			"address": "bc1p4dat5n7s339tx032ev4thc6rqn0eppwph3nt30yjrs62mzt8ej8spydpeq",
			"amount_sat": 39362962,
			"pk_script": "5120ab7aba4fd08c4ab33e2acb2abbe34304df9085c1bc66b8bc921c34ad8967cc8f",
			"outpoint": "ee2b82a8a45199d62ef4d1bf811100a7ec662483003e9030b28b4eae3de2fdbc:1",
			"confirmations": 92
		},

@dannydeezy
Copy link
Author

sorry nevermind, the missing transaction actually isn't in my bitcoind node mempool for some reason

@dannydeezy
Copy link
Author

sorry nevermind, the missing transaction actually isn't in my bitcoind node mempool for some reason

but it did make it out to mempool.space, blockstream, etc.
weird that LND is not recognizing the unconfirmed sweep tx

@Roasbeef
Copy link
Member

Roasbeef commented Nov 21, 2022

lnd doesn't look at the mempool for any spends/confirmations. It only watches on chain, since that always gives us a single source of truth to target against (vs trying to target something in the mempool that might have no ever). In the future mempool policy may only get more murky as well. Once things are confirmed, then the wallet will remove any UTXOs created from that invalidated anchor sweep.

sorry nevermind, the missing transaction actually isn't in my bitcoind node mempool for some reason

Also if it never got to you, then there's no way lnd would see it. There's no global mempool view, which is why we wait for things to be confirmed before acting on them (some special cases apply).

@dannydeezy
Copy link
Author

dannydeezy commented Nov 21, 2022

lnd should always know about unconfirmed spends that it created though?
in this case my LND created a sweep transaction but this transaction seemed to never register in the wallet, as one of the inputs used was still appearing as unspent

sorry my original descriptions were confusing as i was still trying to figure out what happened

@Roasbeef
Copy link
Member

Roasbeef commented Nov 29, 2022

lnd should always know about unconfirmed spends that it created though?

Yeah it should, but if the transaction it went to broadcast was actually invalid (the input was spent), then that would be resolved by the sweeper eventually trying a different input set to ensure things are swept properly.

I'm not sure what the original issue was tracking though. Does your on chain data (txns/utxos, etc) look correct now?

@dannydeezy
Copy link
Author

dannydeezy commented Nov 30, 2022

Yeah it should, but if the transaction it went to broadcast was actually invalid (the input was spent), then that would be resolved by the sweeper eventually trying a different input set to ensure things are swept properly.

the transaction the lnd sweeper broadcasted was valid, it was this tx 3c0f4964e5eb1795e058f74d3fd998fa1f1f6bf583218cea61ee54021a265c23, which eventually confirmed

everything resolved once 3c0f4964e5eb1795e058f74d3fd998fa1f1f6bf583218cea61ee54021a265c23 confirmed on chain.

but things were in a weird state in the several hours while that tx was hanging around in my mempool: the lnd wallet had not updated its list of unspents, so one of the inputs to that transaction was still showing up in listunspents. this caused problems for my on-chain wallet operations because my scripts kept trying to use one of those inputs in its new transactions, which would fail to broadcast b/c they were double-spends

@dannydeezy
Copy link
Author

dannydeezy commented Nov 30, 2022

unfortunately i don't know how i can reproduce this and i don't think i have any more valuable information, but perhaps this could be an explanation:

maybe somehow the call timed out when LND was trying to broadcast the original automatic sweep transaction 3c0f4964e5eb1795e058f74d3fd998fa1f1f6bf583218cea61ee54021a265c23, such that it made it to my mempool, but LND never processed the response from bitcoin core, so that LND did not record the spend, which is why the wallet utxo list did not get updated immediately

@Horndev
Copy link

Horndev commented Feb 8, 2023

I think I may be experiencing something like this, and LND keeps creating sweeps of the same invalid anchor UTXO that has already been mined.

The problem is that it keeps locking up my valid UTXOs trying to sweep this, until it shows I have no UTXO to spend.

I have both of these in my listchaintxns...

020000000001028571023aa77db0317ac9e78c7114ca89bc274c5be20dead6e4e673128dd2b3c801000000000000000048fefaff6b8845d25a47275a3b1293c708d35d87a22663bb54b25f5f381eb00b0100000000000000000168ae1f00000000002251204e714f6ecc8ccaf307b1c47c51b61e50f85fb48db6e5d98a3eb5905c0e4641820247304402207c098b7ddc4d09b7f0f72265c630a6f24c86bd9f56d2f0821df7b937535bf49c022046bc5c11751d88336bcb5038a9b1f60e195c6024a77995242a62a0517c0c603401282103fbf21f752192b0022491a0478b5a4c94ff1534e7328fb9884e8e88675d29e6f8ac736460b2680140dd305a449aec63b772f08679501835f58efeeccbc2f85613848afb3b0e8f1ad60f81fb39958969feeea872e26e7d8f890b631a66e406999ae047c24c7b118cb3abd50b00

and 020000000001028571023aa77db0317ac9e78c7114ca89bc274c5be20dead6e4e673128dd2b3c8010000000000000000402a839bc36b61c6714c9bc076670ca0ebcb3d72d05c9237691483c128a6a7d4000000000000000000010ace020000000000225120ca2f32bfb44c79fda9efbb474076ed20f4824c0bf8317d06b4a65dc0b42eb2ad02483045022100e4f2feb3c0d274b0351a565cf460e477e61e7ae21400ffb52cb85ff8477709dd02205066f5e3578e2cc5a348f8e25926a5359d1f1aaa5cc6913331b064ff207d75d001282103fbf21f752192b0022491a0478b5a4c94ff1534e7328fb9884e8e88675d29e6f8ac736460b26801409be7cb57b719e235e1bb59fb04b4839e6264b70ab82064444b460497aea1c62415c2fcc2150ba5c70daf9eae3766b82764a12d1e3ca68c906d18edd0869c89f4b2d50b00

are both being sent by my node, but c8b3d28d1273e6e4d6ea0de25b4c27bc89ca14718ce7c97a31b07da73a027185:1 is trying to be swept multiple times. These transactions are rejected by nodes, and will never be mined and the small UTXO to sweep is already spent.

Basically, I can't open more channels as LND goes into a state where my entire on-chain balanced is eventually marked as unconfirmed in a bunch of these bad sweeps.

LND 0.15.4-beta

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Unintended code behaviour mempool P1 MUST be fixed or reviewed utxo sweeping
Projects
None yet
Development

No branches or pull requests

5 participants