Skip to content

Add Fee Estimation in ChannelMonitor #334

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

Merged

Conversation

ariard
Copy link

@ariard ariard commented Apr 9, 2019

May go before or after #305 but should go before #333

@ariard ariard force-pushed the 2019-04-fee-estimation-monitor branch from c472359 to 3937747 Compare April 10, 2019 00:18
Copy link
Collaborator

@TheBlueMatt TheBlueMatt left a comment

Choose a reason for hiding this comment

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

Awesome! I'm surprised this didn't have follow-on requirements in the functional tests (which probably means we should expand our functional tests, but hey, at least this patch is easy).

@@ -475,6 +490,32 @@ impl ChannelMonitor {
}
}

fn get_claim_tx_weight(inputs: Vec<InputDescriptors>, output_scriptpubkey: &Script) -> u64 {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Isn't this missing a *4 somewhere? Weight is 4x the size for non-witness bits, but less for the witness bits. It would be nice to just commit a test that generates some transactions and checks this function.

Copy link
Author

Choose a reason for hiding this comment

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

Damn right this definitely need test! I'm gonna to add a unit one for get_claim_tx_weight on this PR, and was planning to extend functional ones for bump txn thing IMO it gonna to need serious testing

@ariard ariard force-pushed the 2019-04-fee-estimation-monitor branch 3 times, most recently from ef7b9fd to b28825e Compare April 12, 2019 17:19
Copy link
Collaborator

@TheBlueMatt TheBlueMatt left a comment

Choose a reason for hiding this comment

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

Probably take the testing commit from https://github.com/TheBlueMatt/rust-lightning/tree/2019-04-334-review and make sure it works afterwards.

@@ -1165,6 +1209,7 @@ impl ChannelMonitor {
value: htlc.amount_msat / 1000, //TODO: - fee
}),
};
single_htlc_tx.output[0].value -= fee_estimator.get_est_sat_per_1000_weight(ConfirmationTarget::HighPriority) * (single_htlc_tx.get_weight() + Self::get_witnesses_weight(&vec![if htlc.offered { InputDescriptors::RevokedOfferedHTLC } else { InputDescriptors::RevokedReceivedHTLC }])) / 1000;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should drop the TODO: - fee two lines up.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Gah, unrelated to this PR but isnt there a missing spendable_outputs.push() two lines below here?

Copy link
Author

Choose a reason for hiding this comment

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

Seems you're right, but rightly likely they should move from place after #333 so added a note to todo it there

@@ -1370,16 +1417,18 @@ impl ChannelMonitor {
inputs.push(input);
values.push((tx.output[transaction_output_index as usize].value, payment_preimage));
total_value += htlc.amount_msat / 1000;
input_descriptors.push(if htlc.offered { InputDescriptors::OfferedHTLC } else { InputDescriptors::ReceivedHTLC });
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think this only makes sense for OfferedHTLCs (ie HTLCs to us). See, however, #337.

Copy link
Author

Choose a reason for hiding this comment

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

Agree our current is likely boggus, will test it but you may tag it as "good first issue" IMO it's pretty straightforward to test

Copy link
Author

Choose a reason for hiding this comment

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

But as code branches are, for now and only if it's temporary, seems to me that makes sense for both. You may claim an offered HTLC with preimage tx before remote timeout it with its HTLC-timeout and you may claim a received HTLC with timeout tx before remote get it with its HTLC-success.

@@ -475,6 +486,36 @@ impl ChannelMonitor {
}
}

fn get_witnesses_weight(inputs: &Vec<InputDescriptors>) -> u64 {
let mut tx_weight = 0;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Doesn't this need to start with 2 for the flags bytes?

Copy link
Author

Choose a reason for hiding this comment

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

Aaaah in fact I was adding them in test to get the right count but it didn't trigger me that it wasn't normal and that I should get them from get_witnesses_weight....

@ariard ariard force-pushed the 2019-04-fee-estimation-monitor branch from b28825e to d0b3aad Compare April 16, 2019 23:27
@ariard
Copy link
Author

ariard commented Apr 16, 2019

Just took the assertion commit, spendable output will have to move after claim tx confirmation delay so will fix it here.

@ariard ariard force-pushed the 2019-04-fee-estimation-monitor branch from d0b3aad to 1c7ba90 Compare April 19, 2019 00:09
@TheBlueMatt TheBlueMatt merged commit 2811b07 into lightningdevkit:master Apr 21, 2019
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.

2 participants