Lnd: Initiated channels do not show total fees for closing txs in getTransactions

Created on 12 Apr 2019  路  8Comments  路  Source: lightningnetwork/lnd

Background

Channels that I create (initiate) show opening tx fees, but do not show closing tx fees in either getTransactions or lncli listchaintxns

Your environment

  • v0.5.1-beta
  • Darwin (Mac OS Majave)
  • bitcoind 0.17

Steps to reproduce

When a user requests to open a channel with another node, a call to getTransactions returns the opening transaction with the correct total_fees for the opening transaction. Once you close the channel, the transaction shows up under getTransactions however total_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

{ amount: '-0.16786002',
  transaction: '8254ecc786633551d2ca5ae32f75629fd6d7940e9c284229b33edd264997910b',
  blockNumber: 6097,
  timestamp: '1555022291',
  fees: '0.00008787' },
{ amount: '0.16768165',
  transaction: '4cbef435eba3370451c53738e3acb35c4bf575877ad05286150649814d548a4c',
  blockNumber: 6127,
  timestamp: '1555022591',
  fees: '0' } ]

Expected behaviour

total_fees contains the amount of fees for the channel close transaction in getTransactions

Actual behaviour

total_fees is 0 in the closing transaction of the channel from the intiator

P3 backend bug help wanted rpc wallet

Most helpful comment

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 getTransactions shouldn't be expected to produce correct fee information for non-completely-wallet-created transactions).

All 8 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 details.Debits is an empty array, therefore, not calculating the fee.

I could think on 2 fixes for that. Calculate it properly on btcwallet, what makes most sense for me.
Or we can calculate the fee at lnd's wallet at https://github.com/lightningnetwork/lnd/blob/master/lnwallet/btcwallet/btcwallet.go#L576

What do you guys suggest?

@vctt94 Sounds like fixing it in btcwallet is the most correct fix. What do you think? :)

@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 getTransactions is correct, because the funds are taken out of the inputs from the commitment transactions (multi-sig). At that point, your wallet is just receiving a balance cause the multi-sig paid the fees. Do you think this change would be confusing to users?

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 getTransactions should be returning

IMO there needs to be a way that a user can see what fees were paid from channel opening, for accounting purposes

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 CloseSummary, but I think it's reasonable to get this value from the channel while it's open/ examining the opening tx to determine fees?

At that point, your wallet is just receiving a balance cause the multi-sig paid the fees. Do you think this change would be confusing to users?

I'm not sure whether it makes sense for us to extract fees on lnd level, since listchaintxns is more of an on-chain api, and should remain ignorant of lightning level use cases. My vote would be for making the change in BtcWallet as @matheusd suggests.

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 getTransactions shouldn't be expected to produce correct fee information for non-completely-wallet-created transactions).

Was this page helpful?
0 / 5 - 0 ratings

Related issues

hxsquid picture hxsquid  路  3Comments

AnthonyRonning picture AnthonyRonning  路  3Comments

sunnya97 picture sunnya97  路  3Comments

danielemiliogarcia picture danielemiliogarcia  路  3Comments

joostjager picture joostjager  路  3Comments