-
Notifications
You must be signed in to change notification settings - Fork 412
Add Shared Input support in interactive TX construction #3842
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 @wpaulino as a reviewer! |
/// malleable. | ||
pub prevtx: TransactionU16LenLimited, | ||
/// malleable. Omitted for shared input. | ||
pub prevtx: Option<TransactionU16LenLimited>, |
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.
We could make this an enum along with shared_input_txid
, but I'm not sure what's a good name to call it
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.
Probably not a good suggestion, but how about just TxInputOrigin
with Txid
and PrevTx
variants?
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 think it's a good idea to keep the message struct field names close to the names in the spec.
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.
Discussed this offline with @wpaulino. While ideally we could use an enum to represent the correct semantics, in practice we don't want to fail parsing if they are incorrect. Otherwise, we'd disconnect rather than simply abandoning the negotiation.
1 similar comment
1 similar comment
I managed to do it: first I refactored the shared output support as discussed, then added shared input support in a similar style. Although this PR does not include spicing, I also checked the changes with splicing (shared input is used there). |
166e364
to
b2e0da8
Compare
total_input_satoshis = total_input_satoshis.saturating_add(shared_input); | ||
if is_initiator { | ||
our_funding_inputs_weight = | ||
our_funding_inputs_weight.saturating_add(P2WSH_INPUT_WEIGHT_LOWER_BOUND); |
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.
This needs to be the weight of the full witness (see FUNDING_TRANSACTION_WITNESS_WEIGHT
) plus the base input weight
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.
That's included in P2WPKH_INPUT_WEIGHT_LOWER_BOUND
, I think:
/// Lower bound for P2WPKH input weight
pub(crate) const P2WPKH_INPUT_WEIGHT_LOWER_BOUND: u64 =
BASE_INPUT_WEIGHT + EMPTY_SCRIPT_SIG_WEIGHT + P2WPKH_WITNESS_WEIGHT;
// If there is a shared input, account for it, | ||
// and for the initiator also consider the fee | ||
if let Some(shared_input) = shared_input { | ||
total_input_satoshis = total_input_satoshis.saturating_add(shared_input); |
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.
Is this supposed to be the full channel value of the shared input, or just the locally owned portion of it?
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.
The locally owned portion, as this calculation is for ensuring that the contribution is enough to cover the (locally owned) outputs and fees.
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 have some doubts about the possible rounding errors due to the msat->sat conversion.
@wpaulino thanks for the comments. I will process them (I've re-requested review accidentally, please ignore that). |
1 similar comment
This simplifies tracking separately the expected and actual shared output. In the initiator case, we can just provide the shared output separately, instead of including it within other outputs, and marking which one is the output. We can use the same field for the intended shared output in the initiator case, and the expected one in the acceptor case.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3842 +/- ##
==========================================
+ Coverage 89.95% 90.92% +0.97%
==========================================
Files 164 164
Lines 131981 142768 +10787
Branches 131981 142768 +10787
==========================================
+ Hits 118718 129812 +11094
+ Misses 10586 10350 -236
+ Partials 2677 2606 -71 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Review comments addressed. Keeping the fixup commits separately for now, but in the end I will just squash into a single commit. |
In interactive TX construction, add support for shared input:
Additionally, the
prevtx
field of theTxAddInput
message is changed to Optional, as it should not be set for the shared input (it cannot, as the full funding transaction is not stored on the acceptor side) (spec discussion: lightning/bolts#1160 (comment))To be used by splicing, see #3736 .
Note: this PR does not include splicing negotiation.