14:59:46 <sgp_> from seth:
14:59:48 <sgp_> https://eprint.iacr.org/2020/1441.pdf
14:59:58 <sgp_> New pre-print proposing a method for payment channels on Monero (i.e. Lightning/a variant of atomic swaps/other L2 networks)
15:03:45 <sgp_> I also heard something about a new lelantus version from rehrar. Does anyone know the main improvements?
15:16:32 <sgp_> sarang: did you see a new lelantus version?
15:18:44 <sarang> It's been updated a few times, but I had not seen the November update
15:20:01 <sarang> Will be interesting to see if/how they solved one-time addressing
15:38:44 <sgp_> rehrar seemed to suggest they did so I will need to take a review
16:17:51 <dEBRUYNE> sarang, sgp_: Some info here -> https://www.reddit.com/r/Monero/comments/jwpqld/lelantus_stuff/
16:17:52 <monerobux> [REDDIT] Lelantus stuff (self.Monero) | 10 points (92.0%) | 12 comments | Posted by d_goddard | Created at 2020-11-18 - 22:14:17
18:33:30 <UkoeHB__> It doesn't seem like the authors of that paper consulted anyone involved in Monero R&D. The intro itself contains various confused arguments (fees being problematic) and omissions (atomic swaps, Triptych).
18:36:29 <moneromooo> Those two are also omitted in monero.
18:37:12 <UkoeHB__> they said there were no atomic swap proposals, and did not mention Triptych when listing other work on next-gen sig schemes
18:37:31 <moneromooo> OK, with this context it sounds more reasonable.
19:38:03 <ArticMine> bulletproofs+
19:40:31 <ArticMine> tx size reuction is 96 bytes per output or total?
19:41:13 <ArticMine> So for a 2 in 2 out transaction 96 bytes or 192 bytes?
19:41:58 <ArticMine> The funding proposal says 96 bytes per transaction
19:42:55 <moneromooo> total IIRC.
19:43:22 <moneromooo> Per proof, so it'd only be 192 if we did non aggregated proofs.
19:44:52 <ArticMine> thanks
20:04:53 <sarang> Yes, fixed amount per proof regardless of aggregation
20:17:18 <ArticMine> That would put a 2 in 2 out transaction just below 1900 bytes 1870 - 1875 bytes. So 1900 will work for the reference transaction size
20:18:11 <ArticMine> in bytes
20:21:42 <dEBRUYNE> sarang: Can you comment on how complex the feature would be? Is it worth the trade-off of touching sensitive parts of the code?
20:21:49 <dEBRUYNE> 5% is arguably, kind of minor
20:23:49 <sarang> I don't think it's particularly complex
20:24:07 <sarang> Much of the existing structure of the BP code can be reused or modified
20:24:40 <sarang> I happen to think it's worth it, but this is an inherent conflict of interest that should be accounted for
20:30:52 <ArticMine> It is 5% for 2 in 2 out for 1 in 2 out the drop is from ~1455 bytes to ~1359 bytes or ~6.6%
20:32:54 <ArticMine> There is a significant number of 1 in 2 out transactions
20:34:31 <ArticMine> The other thing to keep in mind is that these small improvements in transaction size do add up over time
20:35:36 <sarang> Also important to note that an audit of the code should absolutely happen
20:36:33 <ArticMine> Yes an audit of the code needs to happen
20:37:14 <ArticMine> I am in favor of going ahead with BP+
21:57:26 <aravind2212[m]> Hi guys, I am Aravind, a researcher from FAU Germany. My co-authors and I just made our work public, that is on achieving payment channels in Monero without forking the chain. You can find the preprint here https://eprint.iacr.org/2020/1441
21:58:24 <aravind2212[m]> Seth Simmons suggested me to talk about our work here..and see something comes out of this for Monero in practise
21:58:59 <aravind2212[m]> For those who do not know me, I was also involved in the Omniring project that came out last year.
21:59:10 <aravind2212[m]> Please do share your thoughts
22:05:10 <sarang> Hi aravind2212[m]!
22:05:35 <sarang> Sarang here, who was in contact with Tim Ruffing with some suggestions and questions about Omniring a while back
22:05:43 <sarang> Very interested to read your new preprint
22:05:44 <sarang> !
22:06:07 <aravind2212[m]> Hi! we met at MoneroKon last year too
22:06:13 <sarang> Oh, excellent
22:06:20 <sarang> Apologies for not recalling this :/
22:06:40 <sarang> I am quite bad at remembering people's names unless I hear them often
22:07:03 <sarang> I haven't read the preprint yet, but am very excited to :)
22:07:08 <aravind2212[m]> (y) no problem
22:08:10 <aravind2212[m]> the main technical innovation there is to realise timelock transactions without requiring any scripts on chain
22:08:16 <sarang> Thanks for stopping by this channel; it's always great to speak with researchers about their work
22:08:34 <aravind2212[m]> do share your thoughts after checking out the paper
22:08:39 <sarang> Absolutely!