--- Log opened Thu Nov 19 00:00:21 2020
01:52 < dr-orlovsky> raj_: the problem of rust-lightning is that it was never used in production and I had heard reports of a lot of issues arising from its architecture. Let's leave TLVs aside; BigSize is not a complex type to migrate. I gave my response in github here: https://github.com/LNP-BP/rust-lnpbp/issues/136#issuecomment-730256306
01:53 < dr-orlovsky> After we will complete this part we can see what else is needed to implement message encodings; but the core logic of channel management in rust-lightning is simply incompatible with what we need in LNP Node and for RGB support in lightning and we can't just "use it" without rewriting >90% of it
02:25 < dr-orlovsky> Please let me know if I have addressed all you questions or I missed something
02:56 < raj_> Hmm.. I think I got seriously confused there somewhere. Yes it makes sense if we are talking about reimplemnting TLVs better than rust-lightning. Then I am confused what else do you mean by LN-Encoding? If Bigsize is the concern then its already merged with my last PR and yes its very short.
02:59 < raj_> Probably thats it then? Theres not much to encode else in LN. All of the data are byte serialized (big endian uniformly, if I am not wrong).
03:07 < raj_> Also, do you prefer this conversations in github or here? I guess in github many others can participate. But I also dont wanna create noise in public with my missunderstandings.
05:15 -!- zoe_ [uid464843@gateway/web/irccloud.com/x-oinzxrmdbxviakpn] has joined #lnp-bp
10:39 < dr-orlovsky> raj_: It could be that I am missing something. But I assume at least you have to encode public keys, signarutes, hashes, hash preimages etc, etc, which is a set of types. Even if it is simple, we do not yet have it.
12:01 -!- louneskmt [54642c1d@29.44.100.84.rev.sfr.net] has joined #lnp-bp
12:28 -!- louneskm_ [~textual@29.44.100.84.rev.sfr.net] has joined #lnp-bp
12:29 -!- louneskmt [54642c1d@29.44.100.84.rev.sfr.net] has left #lnp-bp []
12:31 -!- louneskm_ [~textual@29.44.100.84.rev.sfr.net] has left #lnp-bp []
13:29 -!- zoe_ [uid464843@gateway/web/irccloud.com/x-oinzxrmdbxviakpn] has quit [Quit: Connection closed for inactivity]
23:03 < raj_> dr-orlovsky: After given another detailed look at strict encdoning pattern, I am still little confused. The strict encoding pattern has 3 startegies: Bitcoin consensus, HashFixedBytes and Wrapped. BitcoinConsesnsus covers everything that needs to be encoded by bitcoin rules, ex: primitive types as LE bytes, Bitcoin structures like publickey, signatures, OutPoints etc with VarInt and other requirements.  HashFixed bytes
23:03 < raj_> covers all hash type data. For the rest of the custome datatypes as defined both in standard library and lnpbp Wrapper and custom implemntations are used like Vec<T> and TaggedHash etc. So if we are not concerned about BigSize and TLVs at this stage, I am not seeing why we cant just use strict encoding directly. All the consensus related structures are already covered, Hixed hash byte structures are covered, custom objects
23:03 < raj_> like BtreeMap<K, V> doesn't need to follow any BOLTs and are local to lnpbp.
23:05 < raj_> So it seems we can simply use strict_encoding to serailize whatever data we need, and then use message constructors as per BOLTs to create TLVs with BigSize and whatever.
23:10 < raj_> We can reimplement the same pattern with another trait like LN-Encode, but if we end up using the same strategies that are already coverd, will it be very useful?
--- Log closed Fri Nov 20 00:00:24 2020