--- Log opened Fri Nov 20 00:00:24 2020 00:24 < dr-orlovsky> I have no guarantee that bitcoin encoding matches lightning encodings from BOLTs for all those types. Have you checked each of them? 00:25 < dr-orlovsky> and I am pretty sure there is a lot of BitSize use right inside LN messages outside of any TLVs 00:25 < dr-orlovsky> for instance, how you will encode feature flags with bitcoin/strict encoding? Vector of networks in `init` message? etc, etc 00:43 -!- zoe_ [uid464843@gateway/web/irccloud.com/x-jfgelyyvjioyxhjc] has joined #lnp-bp 01:09 < raj_> So far as I have checked, BOLTs donot specifies any encoding standard for primtive types (both standard library and Bitcoin types). BOLT specifies LN message formats which I think are different from this type of encoding that we are talking about. And yes that includes BigSize at various places and many other LN specific data types. I think they need to be handled case by case basis depending on msg types, rather something 01:09 < raj_> like strict_encoding which has balnket implemntations on everything. 01:10 < dr-orlovsky> I do not get why they have to be handled at the message level but not at the type level with a dedicated trait 01:11 < raj_> For example I dont think we need any other encoding to represent Transaction data other than what Bitcoin consensus rules dictate. So a Tx object will be serialised in the same way for both RGB, Bitcoin and LN. Which is handled by strict_encoding using BitcoinConsensus Strategy. Same for Publickey, Signature, Hash etc.. 01:12 < dr-orlovsky> ok, I think we can abandon this task and I need to look into it myself. It will be clearly faster for me to do what I need in this regard in the code then to explain what and why it is needed 01:14 < raj_> > I do not get why they have to be handled at the message level but not at the type level with a dedicated trait 01:14 < raj_> Hmm. Probably we can handle them via some trait. But we do need to implement specific logics for specific msg types. So in that sense its not gonna match with what we are doing in strict_encode. In my head I am seeing them as APIs that will form these msgs while using strict_encoding for underlying data when needed. And it will handle Bigsize, and other BOLTs requirement. 01:14 < raj_> Yes, probably that. Because I am not being able to guess what needs to be done here.. 01:15 < dr-orlovsky> I have a feeling that we can avoid doing custom per-message encodings, but there is no way of exlaining it w/o doing code myself 01:18 < raj_> Hmm. I guess now I see what you were intending.. Use the same pattern like strict_encode but use it for encoding LN messages. It probably can be done but i need to think more. I havent thinking in that direction this whole time. I guess it would be better if you try to do it as you are more thorough with this particular pattern. I understood the sense of it. And I do agrre there would be way to do LN msg encoding using that 01:18 < raj_> pattern. But I wouldn't know readily. 01:21 < raj_> If you come up with some sample code, I might know then how to extend over it. But I feel I would be more productive in some other direct task in the meantime. So feel free to assign me on anything you have other than this. We can come back to this after an initial sketch. 01:25 < raj_> One more point regarding this. We would need a complete TLV implentation before we can start encoding LN msg data. LN msgs include them in many places. So probably fleshing TLVs out first would be a good idea. 14:32 -!- zoe_ [uid464843@gateway/web/irccloud.com/x-jfgelyyvjioyxhjc] has quit [Quit: Connection closed for inactivity] --- Log closed Sat Nov 21 00:00:23 2020