14:07:50 <cjd> Hey folks, is there any ongoing effort on HTLC / lightning network support ?
14:07:59 <cjd> (thanks moneromooo for pointing me here)
14:14:43 <sarang> HTLC seems unlikely, given how transaction authorization is done
14:15:06 <sarang> There is ongoing work relating to DL-based constructions
14:35:30 <cjd> The DL "contractless contracts" stuff ?
14:38:26 <sarang> Transaction protocols that enable DL-based authorization with other functionality like non-interactive refunds (the sort of plumbing that would be useful for swaps, channels, networks, etc.)
14:38:36 <sarang> It's quite tricky to get right without consequence
14:41:22 <cjd> Yeah and if it's a requirement that people can "appear to spend" these transactions as per the CryptoNote protocol, it's an uphill battle
14:42:06 <sarang> DLSAG was a very promising approach toward this, but has tracing issues due to the way it computes linking tags
14:42:44 <sarang> The non-linearity of Monero linking tags is precisely what prevents this now
14:43:06 <sarang> but DLSAG used linear tags for a necessary Diffie-Hellman construction
14:43:58 <cjd> Looking at the paper now
16:29:33 <flipchan> Hey, any project looking for a python/rust dev?
18:18:21 <sarang> Hello all
18:18:30 <sarang> Quiet day!
18:18:51 <sarang> I'm finishing up an update (with moneromooo) to wallet message signing
18:19:03 <sarang> Will push the commit once testing is done
18:48:11 <h4sh3d[m]> flipchan: what about implementing ´Discrete logarithm equality across groups’ from Sarang in Rust? I wanted to give it a try in the next weeks, and I can collaborate if you want
18:49:07 <h4sh3d[m]> sarang: do you think it’s valuable?
18:49:43 <sarang> I suppose it depends on what future protocols might use a Rust library, whether in Monero or not
18:49:58 <sarang> If useful, here's a proof-of-concept version in Python: https://github.com/SarangNoether/skunkworks/tree/discrete/discrete
18:50:09 <sarang> (it's for research only; don't use in production)
18:50:20 <sarang> using ed25519 and ed448 as the example curves
18:50:44 <derpy_bridge> <[discord] DynaChip#0559>: Cool
18:50:50 <sarang> But it certainly sounds like a fun project anyway :D
18:51:08 <derpy_bridge> <[discord] DynaChip#0559>: Got anymore cool GitHubs?
18:51:32 <sarang> For what?
18:51:39 <sarang> GitHub is full of code!
18:51:42 <derpy_bridge> <[discord] Kayla#5718>: @Cool guy [irc]
18:51:43 <derpy_bridge> <[discord] Kayla#5718>: ```we might not have any rules in the discord but be mindful that those other communities have their own guidelines```
18:51:57 <derpy_bridge> <[discord] DynaChip#0559>: Ok
18:51:57 <moneromooo> Don't spam in this channel please.
20:17:54 <flipchan> h4ash3d[m]: yeah maybe
20:21:13 <sarang> h4sh3d[m]: did you have particular curve implementations in mind for testing?
20:21:26 <flipchan> github server  error
20:21:43 <flipchan> github seems more and more unstable these days
20:22:16 <h4sh3d[m]> Secp256k1 and curve25519 would be useful for swaps I think =p
20:22:57 <sarang> Most definitely! I only chose ed448 because it was easy to modify the ed25519 library :)
20:23:17 <h4sh3d[m]> Sure
20:23:49 <flipchan> now github is up
21:03:46 <defterade_> sarang: just out of curiosity, was there an incident that lead you to add the "do not use in production" warning to repo links or just common courtesy?
21:09:57 <sarang> Research code is often proof of concept, and not written with production security in mind
21:10:17 <sarang> And is not formally reviewed etc.
21:11:08 <sarang> I recall when the Zerocoin flaw was identified, and the repo had been marked as research only but was used in production for different projects anyway
21:11:18 <sarang> Best to avoid this
22:18:39 <sarang> A new preprint looking at traceability in Monero and Zcash: https://eprint.iacr.org/2020/593
22:19:08 <sarang> The usual caveat, of course, that preprints undergo _no_ formal review before posting, so there is no guarantee that any of this preprint's conclusions are correct
22:20:30 <sarang> It would be interesting to see specific information on transactions they looked into, to see how well the default software is performing
22:21:22 <sarang> (I'll say it once again, because this seems to be often misunderstood: anyone can post a preprint... there is no formal review for preprints!)
22:42:37 <maybefbi> sarang, UkoeHB_: if we combine DLSAG scheme and say CLSAG scheme, there will two sets of aggregate public keys correct? One for the left side of the 2-tuple and one for the right side of the 2-tuple?
22:43:16 <UkoeHB_> not sure, I haven't looked at DLSAG
22:43:33 <maybefbi> ok
22:43:43 <dEBRUYNE> sarang: Any preliminary observations from the paper?
22:43:49 <dEBRUYNE> Or did you not skim it yet?
22:48:30 <sarang> maybefbi: only one of the two keys in each dual-key output pair is selected for inclusion
22:48:40 <sarang> dEBRUYNE: no, not yet
22:48:55 <sarang> I only skimmed it _super_ briefly, and will read it more carefully tomorrow
22:49:07 <sarang> Posting it here in case others wish to read it too
22:50:05 <maybefbi> sarang: thanks