-
Notifications
You must be signed in to change notification settings - Fork 368
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
Dual funding and interactive tx construction wire messages #1794
Conversation
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.
Primarly just the dual-funding messages
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 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 ReportPatch coverage:
📣 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
☔ View full report in Codecov by Sentry. |
5ff4b1f
to
e8b095f
Compare
We could also pipe them through the |
e8b095f
to
ff23ca9
Compare
756064a
to
a788fcd
Compare
Oops, bad timing, looks like this needs rebase now. |
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. |
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. |
a788fcd
to
fb9706f
Compare
fb9706f
to
43f2e77
Compare
43f2e77
to
78c8fe7
Compare
Any updates @dunxen? |
Just waiting on feedback on the |
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.
Didn't bother verifying the messages match the BOLT changes, but probably wont.
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.
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 :)
78c8fe7
to
dc9b02a
Compare
Looks like the BOLT PR is ~ready to land? So we should be able to move forward here, right? |
66f5adc
to
645b337
Compare
645b337
to
40a7a56
Compare
Needs a rebase now that the dependent PR has landed. |
223b799
to
bce24b6
Compare
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.
LGTM, just two minor comments regarding witness serialization.
bce24b6
to
5cd41ed
Compare
/// 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>, |
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.
🤮 lets make this required 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.
I'll bring it up. So required for V2 channels?
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.
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)
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.
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.
5cd41ed
to
ddfddcf
Compare
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.
ddfddcf
to
2ace882
Compare
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.
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); |
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.
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); |
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 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 |
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.
TIL signaling has two ls in british english.
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.
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> { |
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.
typo?
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.
sigh, yeah :/
Yeah copied signature over.
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. |
/// The node_id of the node which should receive this message | ||
node_id: PublicKey, | ||
/// The message which should be sent. | ||
msg: msgs::TxAddInput, |
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 typo -- TxAddInput
instead of TxAbort
(will create a PR, as this is merged)
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.