-
Notifications
You must be signed in to change notification settings - Fork 412
[Custom Transactions] Add TxBuilder
trait, support fixed additional outputs
#3775
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
base: main
Are you sure you want to change the base?
Conversation
👋 Thanks for assigning @carlaKC as a reviewer! |
c245ca1
to
7fc2092
Compare
7fc2092
to
6aa0848
Compare
fa3ea56
to
14b83a3
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3775 +/- ##
==========================================
+ Coverage 89.53% 90.37% +0.84%
==========================================
Files 157 160 +3
Lines 125310 133578 +8268
Branches 125310 133578 +8268
==========================================
+ Hits 112192 120721 +8529
+ Misses 10429 10231 -198
+ Partials 2689 2626 -63 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
🔔 1st Reminder Hey @TheBlueMatt! This PR has been waiting for your review. |
🔔 2nd Reminder Hey @TheBlueMatt! This PR has been waiting for your review. |
🔔 3rd Reminder Hey @TheBlueMatt! This PR has been waiting for your review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a reasonable API on first pass! Will have something smarter to say once I've rebased on this 👌
🔔 4th Reminder Hey @TheBlueMatt! This PR has been waiting for your review. |
🔔 5th Reminder Hey @TheBlueMatt! This PR has been waiting for your review. |
🔔 6th Reminder Hey @TheBlueMatt! This PR has been waiting for your review. |
🔔 7th Reminder Hey @TheBlueMatt! This PR has been waiting for your review. |
🔔 8th Reminder Hey @TheBlueMatt! This PR has been waiting for your review. |
🔔 9th Reminder Hey @TheBlueMatt! This PR has been waiting for your review. |
🔔 10th Reminder Hey @TheBlueMatt! This PR has been waiting for your review. |
🔔 11th Reminder Hey @TheBlueMatt! This PR has been waiting for your review. |
🔔 12th Reminder Hey @TheBlueMatt! This PR has been waiting for your review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. I assume this is kinda blocked until we land more of 0FC?
@@ -622,6 +622,21 @@ impl HTLCOutputInCommitment { | |||
&& self.cltv_expiry == other.cltv_expiry | |||
&& self.payment_hash == other.payment_hash | |||
} | |||
|
|||
pub(crate) fn is_dust(&self, feerate_per_kw: u32, broadcaster_dust_limit_sat: u64, features: &ChannelTypeFeatures) -> bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we want the interface to decide this, shouldn't it just be a new flag in HTLCOutputInCommitment
rather than a method?
let mut value_to_self_msat_offset = 0; | ||
|
||
let feerate_per_kw = feerate_per_kw.unwrap_or_else(|| self.get_commitment_feerate(funding, generated_by_local)); | ||
|
||
for htlc in self.pending_inbound_htlcs.iter() { | ||
if htlc.state.included_in_commitment(generated_by_local) { | ||
if !htlc.is_dust(local, feerate_per_kw, broadcaster_dust_limit_sat, funding.get_channel_type()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume in the future this will be something the TxBuilder
decides?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall LN spec is moving in a direction where whether a HTLC is dust is solely a function of its amount and the dust_limit_satoshis
p2p setting - so I thought we could let channel make that decision. Could we require all future HTLC-transactions (including customized ones) to pay exogenous fees ? I find them so superior so I thought this was fair.
I have an alternative branch where TxBuilder
makes that decision - but it got thorny quite fast (see get_pending_htlc_stats, get_available_balances_for_scope, next_local/remote_commit_tx_fee_sat
), but happy to revisit this.
Yes would love to merge this as part of the 0FC PR sequence ! Also would like to merge #3855 first, to make sure whatever API we settle on here fits in nicely with a splicing world; in that world for a single set of included HTLCs based on their state, we generate multiple commitments, so this is relevant to this PR here. |
hi @TheBlueMatt on this branch here i make an attempt at an API that supports "fixed additional outputs" on commitment transactions.
I place today's 330 sat anchors in that bucket, but the API should allow for custom ones.
The API should also let people customize all the existing outputs on the commitment transaction.
Still need to think about any remaining TODOs for additional outputs that are only present for some commitments (eg. DLC outputs), depending on how we'd like to prioritize these.
One TODO that remains is abstracting away the calls to
chan_utils::commit_and_htlc_tx_fees_sat
in channel dust exposure calculations.