Sometime the last version of LND shows to me incorrect balance of wallet. To see examples below
lnd commit cfb5e249b9d6dae9e44dcf56c29c3eda531290fe (actual master at 2019-03-11)uname -a on *Nix) CentOS 6btcd, bitcoind, or other backend 0.17.1Don't know
It should show correct balance from confirmed UTXO from wallet
For example right now i saw:
l walletbalance
{
"total_balance": "85601",
"confirmed_balance": "85601",
"unconfirmed_balance": "0"
}
I know that node has 25 BTC. Some BTC in channels. I checked:
l listchannels|grep local_balance|sed -r -e 's#.*"([0-9]+)".*#\1#'|awk '{s+=$1} END {print s}'
1836160500
l pendingchannels|grep local_balance|sed -r -e 's#.*"([0-9]+)".*#\1#'|awk '{s+=$1} END {print s}'
39769984
After i did for checking:
l listchaintxns|grep amount|sed -r -e 's#.*"(-?[0-9]+)".*#\1#'|awk '{s+=$1} END {print s}'
635162828
I saw that all UTXO in wallet are confirmed. So the walletbalance should be show this number but it shows the 85601
After i restarted the LND and after restart:
l walletbalance
{
"total_balance": "635162828",
"confirmed_balance": "635162828",
"unconfirmed_balance": "0"
}
Because i restarted i didn't catch the bug but i have other lnd node where i see right now the same problem. But i didn't restarted yet.
Do you see any logs for transactions after the restart? Is this on one of the nodes where you've had previous wallet issues?
No, it's other node - lnd-07
I can send the full log to you (through gpg encrypting) as i did already if you need
https://drive.google.com/file/d/1YSZwQc7Y3GT5zHul5NgOZo4N142LDQlJ/view?usp=sharing
Here is full logs from 2019-03-11 (tailed)
If you will need i can prepare full log
FWIW, if you have pending open channels, then those funds won't show up in the wallet balance momentarily as we lock the outputs during funding to avoid double spends.
FWIW, if you have pending open channels, then those funds won't show up in the wallet balance momentarily as we lock the outputs during funding to avoid double spends.
I understand it but it not my case, i wrote above that i checked this by:
l pendingchannels|grep local_balance|sed -r -e 's#.*"([0-9]+)".*#\1#'|awk '{s+=$1} END {print s}'
39769984
Only 0.39 BTC were in pending
LND-22 has now same problem. And a long time. Yesterday when i posted this ticket - there was same problem and it is right now. I didn't restarted this node. There is same versions of lnd & bitcoind and right now at lnd-22:
# walletbalance by lnd
l walletbalance
{
"total_balance": "2489983",
"confirmed_balance": "2489983",
"unconfirmed_balance": "0"
}
# channelbalance by lnd
l channelbalance
{
"balance": "1998264095",
"pending_open_balance": "50979350"
}
# The real walletbalance which should be showed because the node has 25 BTC (channels + wallet)
l listchaintxns|grep amount|sed -r -e 's#.*"(-?[0-9]+)".*#\1#'|awk '{s+=$1} END {print s}'
532362331
# In pending channels only 0.5 BTC
l pendingchannels|grep local_balance|sed -r -e 's#.*"([0-9]+)".*#\1#'|awk '{s+=$1} END {print s}'
50980001
# And for checking of channelbalance - the same sigits, it's OK:
l listchannels|grep local_balance|sed -r -e 's#.*"([0-9]+)".*#\1#'|awk '{s+=$1} END {print s}'
1998264095
So i think there is real bug and LND doesn't see some confirmed UTXOs
And may be it will few help - there (lnd-22 too) is transactions from listchaintxns which are not-confirmed and will not be i think because they look like double spending UTXO. But please notice there is sum (29973538 sat or 0.29 BTC) not close to 5 BTC
...
{
"tx_hash": "fb3d1b87549b45ff1e34142a21411bc420adc7e096357f46b29ccb414f6a32b6",
"amount": "1440192",
"num_confirmations": 28,
"block_hash": "00000000000000000013cc37f66ca3f68c3c786d4e02d8b30a4a6f2e7e19c246",
"block_height": 566984,
"time_stamp": "1552549429",
"total_fees": "0",
"dest_addresses": [
"bc1qe9l8zunq9mt94m9a5va5xgtetgax57vpjkgvnu"
]
},
{
"tx_hash": "ef5611d9e17df2bf326d22078311034ad30c3af19e9dd0ae92f5d99411104046",
"amount": "4995777",
"num_confirmations": 0,
"block_hash": "",
"block_height": 0,
"time_stamp": "1552398845",
"total_fees": "0",
"dest_addresses": [
]
},
{
"tx_hash": "cd2508be4e8d17b8d74539ef4807ab0b7c0eed9023f96a465a2a1f3e65a8ef6b",
"amount": "9991285",
"num_confirmations": 0,
"block_hash": "",
"block_height": 0,
"time_stamp": "1552404220",
"total_fees": "0",
"dest_addresses": [
]
},
{
"tx_hash": "599c3e79fe180853839d88a59806e59c77cc06a260ba3c7a3db8ffb6d408fc74",
"amount": "4995724",
"num_confirmations": 0,
"block_hash": "",
"block_height": 0,
"time_stamp": "1552399780",
"total_fees": "0",
"dest_addresses": [
]
},
{
"tx_hash": "b85110d5265a144cfe92d0a742b668007694e35263df624680e6f0821c9dff8f",
"amount": "4995777",
"num_confirmations": 0,
"block_hash": "",
"block_height": 0,
"time_stamp": "1552398739",
"total_fees": "0",
"dest_addresses": [
]
},
{
"tx_hash": "fb620990cc95adb58f724c02e58e1d0065b005ae7767605987f4345a2e8e7da6",
"amount": "4994975",
"num_confirmations": 0,
"block_hash": "",
"block_height": 0,
"time_stamp": "1552404220",
"total_fees": "0",
"dest_addresses": [
]
}
]
}
We won't be able to properly track this down without knowing exactly which transactions that pay to your wallet are not being accounted for within walletbalance. I checked out the logs and don't see anything that jumps out to me. If you can give us those transaction hashes then we'll know exactly what to look for.
We won't be able to properly track this down without knowing exactly which transactions that pay to your wallet are not being accounted for within
walletbalance. I checked out the logs and don't see anything that jumps out to me. If you can give us those transaction hashes then we'll know exactly what to look for.
I decided to give you full logs of both LNDs. All files are encrypted by your release-signing key
Here are two log files: lnd-07 (first messages - now i don't see incorrect balance because i restarted the lnd) and lnd-22 (last messages here - now this lnd works without restarting and there is incorrect balance)
lnd-07: https://drive.google.com/open?id=1JvgLJi3E9hhqFAUKHoStUq1O17QvnmGl
lnd-22: https://drive.google.com/open?id=1EN0VuEjo2EdocZMLp0zrO8vLVqKmUjkz
I hope it will enough to understand what there happened?
@LNBIG-COM please re-read my last comment. The logs have the information we need, but there's so much information to parse that it's hard to tell where things could've gone wrong. Please provide a transaction hash that you see within listchaintxns which is not being accounted for within walletbalance.
Ok, i will try. But now i already made many changes with channels, i think there many changes and i will be needed to start again
When i will see same error i will let to know - i will send full logs and full dump of listchaintxns
Ok?
Now i saw (not long time) looked like same problem but it was related with autopilot. I have autopilot.allocation=1.0 and i saw now different results of walletbalance and sum of amounts of listchaintxns. But now there were unconfirmed transactions.
Can block autopilot _confirmed_ _UTXOs_ which not used (no used transactions in `listchaintxns) but will not be accounted in walletbalance?
I'm already confused in all these different not spent values of satoshies. I think you can close issue and i will create new if i will have more certain info for you
And my suggestion to extend walletbalance info. For example to add 4th field where will be balances of blocked amounts of autopilot for example or locked sums which are not seen.
I think you will constantly have reports from users that somewhere something is lost in the balance of wallet. All problems from that. It's because you don't have a clear debit / credit. It scares sometimes.
Can block autopilot confirmed UTXOs which not used (no used transactions in `listchaintxns) but will not be accounted in walletbalance?
No. The funding manager (responsible for opening channels) locks any UTXOs attempted to be used to fund a channel. If that transaction ends up being invalid (due to double spending an input, or exceeding a mempool chain depth, etc.) then the transaction will be removed from the wallet, but the UTXOs remain locked, which could be the reason as to why you're seeing this.
I think we can close this a a duplicate of #1693?
Don't think so, but can still close it as we don't have enough information. Can re-open if we come across this again.