discreetlogcontracts / dlcspecs

Specification for Discreet Log Contracts
Creative Commons Attribution 4.0 International
238 stars 36 forks source link

Update messaging and serialization #171

Closed Tibo-lg closed 2 years ago

Tibo-lg commented 3 years ago

I am confused how we differentiate a single_contract_info from a enumerated_contract_descriptor if they both have the same type?

Depending on the context, you know which one you want to read so there is no confusion. It's a bit the same as how you distinguish between a u16 or u64, you don't have a type prefix, you just know which one you expect.

benthecarman commented 3 years ago

Depending on the context, you know which one you want to read so there is no confusion. It's a bit the same as how you distinguish between a u16 or u64, you don't have a type prefix, you just know which one you expect.

Oh I see, offer, accept, and sign, all still have their types defined

benthecarman commented 3 years ago

If we are going to break backwards compatability with current messages, it may be worth to change it so the messages will fit for the current lightning spec. ie break up accept and sign tlvs so they can fit in a single message

Tibo-lg commented 3 years ago

Oh I see, offer, accept, and sign, all still have their types defined

Yes exactly, all messages that are sent directly on wire need to have a specific type number defined (from the custom LN space).

If we are going to break backwards compatability with current messages, it may be worth to change it so the messages will fit for the current lightning spec. ie break up accept and sign tlvs so they can fit in a single message

I think we discussed about that at some point, but the preferred approach was to have a protocol to split messages into packets. So we would keep the current serialization format but before being sent on wire each message (that is too large) would be split before being sent on wire, and reconstructed on the receiver side.

benthecarman commented 3 years ago

I think we discussed about that at some point, but the preferred approach was to have a protocol to split messages into packets. So we would keep the current serialization format but before being sent on wire each message (that is too large) would be split before being sent on wire, and reconstructed on the receiver side.

Do we have a timeline on that?

Tibo-lg commented 3 years ago

Do we have a timeline on that?

Not really. Tbh honest I had kind of forgotten about it, but I realize I might actually need it rather soon. I don't think I can spend time on that before next meeting so maybe we can bring that up then?

Christewart commented 3 years ago

Are the version messages in #163 omitted for a reason or just forgot? Or perhaps I'm just missing it

Tibo-lg commented 3 years ago

Are the version messages in #163 omitted for a reason or just forgot? Or perhaps I'm just missing it

Sorry I'm not sure I see what you mean? The protocol version field is there as well: https://github.com/discreetlogcontracts/dlcspecs/pull/163/files#diff-e0f5b925f91a1c09c6daf26f9a7d28816cb9ff9f08863faca719b7ee0a1cc065R69

Christewart commented 2 years ago

superseded by #163