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

lnwallet: apply dust amounts to fees #214

Merged
merged 3 commits into from
Jul 7, 2017

Conversation

bryanvu
Copy link
Contributor

@bryanvu bryanvu commented Jun 3, 2017

If an HTLC’s value is below a node’s dust limit, the amount for that
HTLC should be applied to to the fee used for the channel’s commitment
transaction. This PR also adds minor refactoring of the dust limit unit tests.

@mention-bot
Copy link

@bryanvu, thanks for your PR! By analyzing the history of the files in this pull request, we identified @Roasbeef, @AndrewSamokhvalov and @cjamthagen to be potential reviewers.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.006%) to 72.982% when pulling db7e585657aa78deb286622edbb77d845e522333 on bryanvu:dustfees into 74897dc on lightningnetwork:master.

@ABISprotocol
Copy link

ABISprotocol commented Jun 6, 2017

Suggestion regarding how to deal with cases where HTLC’s value is below a node’s dust limit: rather than the entire amount for that HTLC being applied to the fee used for the channel’s commitment
transaction, the HTLCs (that are below a node's dust limit) are gathered together (aggregated) by lnwallet until they can be made part of a transaction. There is then a fee, a transaction and a donation (off by default, unless the user specifies they wish to have donation for transaction(s) and specifies a recipient). Where the donation is left in the "off," or default position by the user, the HTLCs below the node's dust limit would be fully applied to the fee used for the channel's commitment transaction. The donation and recipient(s) would be specified by the user from their GUI wallet (visual example of how this might look like in a user's GUI wallet settings based on an actual example). Support from GUI wallets would vary but the basic support for the functionality of this would be present in lnwallet.

Further concepts relating to this suggestion are here and also here.

Edit: As typical safety circumstance, if for some reason the channel is force closed during payment, and dust htlc/payment aren't settled after aggregation, then it is not included in the commitment transaction (thus, it would be given as a fee to miners).

Copy link

@ABISprotocol ABISprotocol left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested changes at #214 (comment) (Fee - transaction - donation)

@Roasbeef
Copy link
Member

Roasbeef commented Jul 3, 2017

@ABISprotocol that can't be done as is. Doing so would require a new transaction to be create when closing a transaction forcibly which would be a protocol modification. While your idea may be interesting when applied to a user facing wallet with a GUI, it isn't very applicable to this situation.

Copy link
Member

@Roasbeef Roasbeef left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work breaking up the dust-limit related unit tests to focus on a particular scenario at a time! As we discussed the original test sprawled a bit and was rather fragile.

My comments are pretty minor so, if after this round of review and a bit of local testing I don't find any issues, then we should be able to get this merged pretty quickly.

@@ -1309,12 +1310,14 @@ func (lc *LightningChannel) fetchCommitmentView(remoteChain bool,
numHTLCs := 0
for _, htlc := range filteredHTLCView.ourUpdates {
if htlc.Amount < dustLimit {
dustFees = dustFees + htlc.Amount
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can be simplified to dustFees += htlc.Amount.

continue
}
numHTLCs++
}
for _, htlc := range filteredHTLCView.theirUpdates {
if htlc.Amount < dustLimit {
dustFees = dustFees + htlc.Amount
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can be simplified to dustFees += htlc.Amount.

@@ -1301,6 +1301,7 @@ func (lc *LightningChannel) fetchCommitmentView(remoteChain bool,
// * when dumping fees back into initiator output, only dumb explicit
// fee
var dustLimit btcutil.Amount
var dustFees btcutil.Amount
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor style nit: within the codebase whenever we have two or more variable declarations following each other we collapse them into a single var declaration like so:

var (
    dustLimit btcutil.Amount
    dustFees
)

Alternatively, since they're of the same type, we can do something like this:

var dustLimit, dustFees btcutil.Amount

@@ -1324,8 +1327,8 @@ func (lc *LightningChannel) fetchCommitmentView(remoteChain bool,
// on its total weight. Once we have the total weight, we'll multiply
// by the current fee-per-kw, then divide by 1000 to get the proper
// fee.
totalCommitWeight := commitWeight + btcutil.Amount(htlcWeight*numHTLCs)
commitFee := (lc.channelState.FeePerKw * totalCommitWeight) / 1000
weight := commitWeight + btcutil.Amount(htlcWeight*numHTLCs)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, downgraded to a less descriptive variable name? Was this only to ensure that the line below (with the added operation) wouldn't overflow 80 characters? If so, then either the line should be wrapped, or the - dustFees can mutate the commitFee variable on a new line. In either case, we end up with an additional line.

If an HTLC’s value is below a node’s dust limit, the amount for that
HTLC should be applied to to the fee used for the channel’s commitment
transaction.
Split up and simplified dust limit tests.
@coveralls
Copy link

coveralls commented Jul 6, 2017

Coverage Status

Coverage increased (+0.01%) to 74.116% when pulling 23952cd on bryanvu:dustfees into dc0ab06 on lightningnetwork:master.

@bryanvu
Copy link
Contributor Author

bryanvu commented Jul 6, 2017

Just pushed with the requested changes.

Copy link
Member

@Roasbeef Roasbeef left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🏄🏻‍♀️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants