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

Dual funding and interactive tx construction wire messages #1794

Merged
merged 3 commits into from
May 8, 2023

Conversation

dunxen
Copy link
Contributor

@dunxen dunxen commented Oct 21, 2022

The first of a set of PRs to enable dual-funded channels using the interactive transaction construction workflow. This PR adds the messages and events required by the protocol to get that out of the way for the review of upcoming logic PRs.

Copy link

@ariard ariard left a comment

Choose a reason for hiding this comment

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

Primarly just the dual-funding messages

lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
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.

We should get some encoding/decoding tests. Are you looking to land this as-is prior to implementing the dual-funding stuff, or do you want to hold this PR until you have an implementation sketch?

lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
@dunxen
Copy link
Contributor Author

dunxen commented Oct 25, 2022

We should get some encoding/decoding tests. Are you looking to land this as-is prior to implementing the dual-funding stuff, or do you want to hold this PR until you have an implementation sketch?

Working on encoding tests for this PR. Yeah, my idea was to get this up and then just base the sketch on this PR. Although, I don't see any reason we can't land just the message stuff first as long as we don't actually handle them.

@codecov-commenter
Copy link

codecov-commenter commented Oct 26, 2022

Codecov Report

Patch coverage: 42.22% and project coverage change: -0.58 ⚠️

Comparison is base (56b0c96) 91.63% compared to head (40a7a56) 91.05%.

❗ Current head 40a7a56 differs from pull request most recent head 2ace882. Consider uploading reports for the commit 2ace882 to get more accurate results

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1794      +/-   ##
==========================================
- Coverage   91.63%   91.05%   -0.58%     
==========================================
  Files         104      104              
  Lines       51985    52305     +320     
  Branches    51985    52305     +320     
==========================================
- Hits        47638    47628      -10     
- Misses       4347     4677     +330     
Impacted Files Coverage Δ
lightning-net-tokio/src/lib.rs 75.76% <0.00%> (-2.85%) ⬇️
lightning/src/events/mod.rs 41.64% <0.00%> (-2.35%) ⬇️
lightning/src/ln/channel.rs 90.02% <ø> (+0.05%) ⬆️
lightning/src/ln/channelmanager.rs 88.80% <ø> (ø)
lightning/src/ln/functional_test_utils.rs 92.65% <0.00%> (-0.14%) ⬇️
lightning/src/ln/peer_handler.rs 57.43% <0.00%> (-5.15%) ⬇️
lightning/src/ln/wire.rs 56.84% <0.00%> (-7.05%) ⬇️
lightning/src/util/test_utils.rs 72.38% <0.00%> (-4.68%) ⬇️
lightning/src/util/ser.rs 88.23% <42.85%> (-0.21%) ⬇️
lightning/src/ln/msgs.rs 83.39% <67.73%> (-5.32%) ⬇️

... and 23 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

@dunxen dunxen force-pushed the 2022-10-dualfunding-act-1 branch 2 times, most recently from 5ff4b1f to e8b095f Compare October 27, 2022 13:01
@TheBlueMatt
Copy link
Collaborator

Working on encoding tests for this PR. Yeah, my idea was to get this up and then just base the sketch on this PR. Although, I don't see any reason we can't land just the message stuff first as long as we don't actually handle them.

We could also pipe them through the ChannelMessageHandler stuff, and just not expose the feature bit and ignore/error on the messages in ChannelManager itself. That would make the PR a bit more robust without having to add any specific logic.

@dunxen dunxen force-pushed the 2022-10-dualfunding-act-1 branch 2 times, most recently from 756064a to a788fcd Compare November 3, 2022 13:52
@dunxen dunxen changed the title DRAFT: Dual funding messages Dual funding messages Nov 3, 2022
@dunxen dunxen marked this pull request as ready for review November 3, 2022 13:54
@TheBlueMatt
Copy link
Collaborator

Oops, bad timing, looks like this needs rebase now.

@TheBlueMatt
Copy link
Collaborator

General question - how likely is the spec to change at this point? Is it pretty fixed at this point or is it likely to change out from under us?

@dunxen
Copy link
Contributor Author

dunxen commented Nov 3, 2022

General question - how likely is the spec to change at this point? Is it pretty fixed at this point or is it likely to change out from under us?

As far as I know, the messages seem quite fixed now after some small tweaks. There's just some discussion on ordering of inputs/outputs, although that may have be en resolved already. No rush for this to be reviewed and merged, but it is in a better state at least. I'd give it a little longer, maybe a topic for the next spec meeting.

@TheBlueMatt
Copy link
Collaborator

Alright, sounds good. Let's not merge this until we're confident things are fixed, but happy to land it when you think we're good.

@wpaulino
Copy link
Contributor

Any updates @dunxen?

@dunxen
Copy link
Contributor Author

dunxen commented Jan 13, 2023

Any updates @dunxen?

Just waiting on feedback on the est_witness_weight field in the spec which will probably be removed anyway. This is ready for review though.

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.

Didn't bother verifying the messages match the BOLT changes, but probably wont.

lightning/src/ln/functional_test_utils.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
Copy link
Contributor

@alecchendev alecchendev left a comment

Choose a reason for hiding this comment

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

Mainly just looked through the new message structs and how they're serialized and compared them to the spec PR, noted anything that stood out to me :)

lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Show resolved Hide resolved
lightning/src/ln/msgs.rs Show resolved Hide resolved
@TheBlueMatt
Copy link
Collaborator

Looks like the BOLT PR is ~ready to land? So we should be able to move forward here, right?

lightning/src/util/ser.rs Show resolved Hide resolved
lightning/src/ln/channel.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Show resolved Hide resolved
fuzz/targets.h Outdated Show resolved Hide resolved
@wpaulino
Copy link
Contributor

wpaulino commented May 2, 2023

Needs a rebase now that the dependent PR has landed.

@dunxen dunxen force-pushed the 2022-10-dualfunding-act-1 branch 2 times, most recently from 223b799 to bce24b6 Compare May 3, 2023 08:55
Copy link
Contributor

@wpaulino wpaulino left a comment

Choose a reason for hiding this comment

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

LGTM, just two minor comments regarding witness serialization.

lightning/src/util/ser.rs Outdated Show resolved Hide resolved
lightning/src/util/ser.rs Outdated Show resolved Hide resolved
@dunxen dunxen force-pushed the 2022-10-dualfunding-act-1 branch from bce24b6 to 5cd41ed Compare May 4, 2023 11:18
@dunxen dunxen changed the title Dual funding messages Dual funding and interactive tx construction wire messages May 4, 2023
wpaulino
wpaulino previously approved these changes May 4, 2023
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Show resolved Hide resolved
/// The channel type that this channel will represent. If none is set, we derive the channel
/// type from the intersection of our feature bits with our counterparty's feature bits from
/// the Init message.
pub channel_type: Option<ChannelTypeFeatures>,
Copy link
Collaborator

Choose a reason for hiding this comment

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

🤮 lets make this required in the spec.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll bring it up. So required for V2 channels?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok so I think with next release for each implementation, we want to target making this required, outside of the dual-fund spec: lightning/bolts#851 (comment)

Copy link
Collaborator

Choose a reason for hiding this comment

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

Mmm, I haven't tried to look at what % of nodes support channel types, we're probably getting to the point where we can require it but maybe not quite yet. I'm not really I sure I understand tbast's point there but we can take it to that issue and leave it optional here for now.

lightning/src/ln/msgs.rs Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
lightning/src/ln/msgs.rs Outdated Show resolved Hide resolved
dunxen added 3 commits May 5, 2023 11:40
This is the first of a set of PRs to enable the experimental dual-funded
channels feature using interactive transaction construction. This allows
both the channel initiator and channel acceptor to contribute funds
towards the channel.
@dunxen dunxen force-pushed the 2022-10-dualfunding-act-1 branch from ddfddcf to 2ace882 Compare May 5, 2023 09:41
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.

All the comments can be addressed in a followup or left (or now), up to you.

///
/// Use [`TransactionU16LenLimited::into_transaction`] to convert into the contained `Transaction`.
#[derive(Clone, Debug, PartialEq, Eq)]
pub struct TransactionU16LenLimited(Transaction);
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: I think this maybe belongs in ser.rs.

impl Readable for TransactionU16LenLimited {
fn read<R: Read>(r: &mut R) -> Result<Self, DecodeError> {
let len = <u16 as Readable>::read(r)?;
let mut tx_reader = FixedLengthReader::new(r, len as u64);
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 we should check that the reader has no more bytes after reading a transaction. Its not a huge deal, but nice to enforce.

pub serial_id: u64,
}

/// A tx_complete message signalling the conclusion of a peer's transaction contributions during
Copy link
Collaborator

Choose a reason for hiding this comment

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

TIL signaling has two ls in british english.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh true. My mind reads both as valid, but my linguistics write impl does British lol

@@ -567,7 +850,7 @@ impl NetAddress {
}

impl Writeable for NetAddress {
fn write<W: Writer>(&self, writer: &mut W) -> Result<(), io::Error> {
fn write<W: Writer>(&self, writer: &mut W) -> Result<(), io::Error> {
Copy link
Collaborator

Choose a reason for hiding this comment

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

typo?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

sigh, yeah :/
Yeah copied signature over.

@dunxen
Copy link
Contributor Author

dunxen commented May 5, 2023

All the comments can be addressed in a followup or left (or now), up to you.

Will address as followup if that's okay. Out at the moment. Probably good to have the fix in for the fuzz sooner than later.

@wpaulino wpaulino merged commit 4062695 into lightningdevkit:main May 8, 2023
@dunxen dunxen deleted the 2022-10-dualfunding-act-1 branch May 9, 2023 17:38
/// The node_id of the node which should receive this message
node_id: PublicKey,
/// The message which should be sent.
msg: msgs::TxAddInput,
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like a typo -- TxAddInput instead of TxAbort (will create a PR, as this is merged)

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.

7 participants