-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Initiated channels do not show total fees for closing txs in getTransactions #2936
Comments
can I help with this one? |
I found out what the problem is. Here on btcwallet https://github.com/btcsuite/btcwallet/blob/master/wallet/notifications.go#L110 the I could think on 2 fixes for that. Calculate it properly on btcwallet, what makes most sense for me. What do you guys suggest? |
@vctt94 Sounds like fixing it in |
@vctt94 thanks a ton for grabbing this. @halseth et.al I wanted to make sure that this was actually a bug. Technically, the transaction that comes back from LND in |
IMO there needs to be a way that a user can see what fees were paid from channel opening, for accounting purposes, however I had a change of heart RE what |
Related issue: #2594 |
#3961 now displays channel initiator in the close summary, which allows you to determine which party paid the opening fees. Opening fees aren't specifically listed in
I'm not sure whether it makes sense for us to extract fees on lnd level, since |
It wasn't me but @vctt94 that suggested the fix :P I haven't looked very closely at this but IIRC the underlying issue for fixing this on btcwallet is that the wallet doesn't consider the input of the closing transaction (i.e. the multisig output) as a wallet-owned address. For the wallet to do that (and count the input as a debit) you'd have to import the multisig script into the wallet. Which comes with its own set of issues (the wallet would account for the input as wallet owned, it would scan for it, you'd need to be able to remove the script to reduce the watched set, etc). There's also the larger issue of who is actually paying the closing tx's fee (was it the local wallet or the remote wallet or was it split among the two?). Unconditionally importing the script into the wallet would lead both wallets to consider as if they paid the fee. Seems to me all accounting for ln-related operations should only happen in lnd (and |
I wanted to see if this issue has made any progress as it seems to be getting on the older side. The only accounting hole in LND is the closure data, currently it seems LND is providing no fee data on any closures, even the ones I have initiated. As a developer building on LND and using accounting to drive metrics, missing this data is not ideal. Needing to integrate with an external service or all the possible backend chain wallets to fill such a small gap seems like the wrong approach. |
@cryptosharks131 have you seen https://github.com/lightninglabs/faraday? It has accounting features that use a backend node to fill in the missing fee closure information. |
Thanks @Roasbeef I am aware of this tool, however, few users have this installed and adding this as a dependency to run LNDg seems like a poor approach to the solution, especially for those using Umbrel type setups. I still believe it would be best if LND was aware of all of its accounting numbers. The closures dataset all seems to populate after the closure has fully confirmed and sweep txs are listed, a poll to the backend at this time should fill in this dataset? Alternatively, a gRPC available to poll txs manually from which ever backend is configured in LND already could also serve the purpose for developers to access without needing to deploy outside solutions. In the mean time, I have started to add API integration to LNDg in v1.3.0 to attempt to get closure fees from a mempool type block explorer. Although it is not the best solution as it still can fail in some cases, it seems to be the best solution currently to get around this missing data. |
Background
Channels that I create (initiate) show opening tx fees, but do not show closing tx fees in either
getTransactions
orlncli listchaintxns
Your environment
Steps to reproduce
When a user requests to open a channel with another node, a call to
getTransactions
returns the opening transaction with the correcttotal_fees
for the opening transaction. Once you close the channel, the transaction shows up undergetTransactions
howevertotal_fees
remains 0 (possibly due to the way we would calculate the fee based on the multisig from the channel)NOTE This sample data is on regtest but was also performed on mainnet, please reach out directly if you'd like tx information/logs for mainnet
Expected behaviour
total_fees
contains the amount of fees for the channel close transaction ingetTransactions
Actual behaviour
total_fees
is0
in the closing transaction of the channel from the intiatorThe text was updated successfully, but these errors were encountered: