00:09:28 <jberman[m]> Here's a working draft for a WIP PR to fix the decoy selection issue in 7807, I figure discussion here would be useful before submitting
00:09:55 * jberman[m]  < https://libera.ems.host/_matrix/media/r0/download/libera.chat/5df598dae4b57dcf251f7450f5107a560fdb4aa6/message.txt >
00:10:33 <jberman[m]> ## Results of the fix
00:10:33 <jberman[m]> I simulated get_outs using the proposed fix, and plotted against the current:
00:10:50 * jberman[m] uploaded an image: (61KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/RZvJjmiXDfTFFblXwXZEYvwK/10%20block%20unlock%20fix%20vs.%20current%20%5B1%5D.png >
00:10:51 * jberman[m] uploaded an image: (31KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/ymgdZoeFNJmohvLpMXjaLYUX/10%20block%20unlock%20fix%20vs.%20current%20%5B2%5D.png >
00:12:10 * jberman[m]  < https://libera.ems.host/_matrix/media/r0/download/libera.chat/0c3d44fcadf8feadeade84b049d5ca596e87ea4a/message.txt >
00:19:58 <UkoeHB> Sounds good to me
01:05:16 <sarang> I originally had a commitment round for the challenge values, but reasoned that parallel execution risks could be mitigated by binding the inputs to the per-player values in the hash aggregation; I'm not entirely convinced
01:05:27 <sarang> At any rate, the communication complexity remains high
01:06:37 <sarang> FWIW the Lelantus 3 WIP protocol only requires private key shares in a single modified Chaum-Pedersen proof, which is straightforward to produce and can be done linearly
01:07:44 <sarang> Downside is that like Seraphis, it requires a modified address format
01:08:17 <sarang> (Disclaimer: Cypher Stack receives funding by the Firo project in part to develop the Lelantus 3 protocol)
01:09:07 <sarang> We're still working on the transaction and ledger security model for the protocol
01:09:48 <sarang> The new constructions are a parallel Groth-Bootle proving system and a modified Chaum-Pedersen proof
01:10:08 <sarang> The security proofs for parallel Groth-Bootle are straightforward
01:11:08 <sarang> and the Chaum-Pedersen security proof holds under particular assumptions about the prover statements that hold for the application used in the protocol
01:12:18 <sarang> In theory you lose SHVZK under certain group element choices, but this would result in an invalid transaction anyway due to verification failures elsewhere in the protocol
01:23:42 <sarang> Oh, should mention that there's also a version of Lelantus 3 that moves the private key share stuff from Chaum-Pedersen to parallel Groth-Bootle instead, but that's more computationally complex
01:24:26 <sarang> Chaum-Pedersen complexity doesn't scale with input anonymity set size, so the Groth-Bootle work could be offloaded to a more capable device
01:25:50 <sarang> I suspect that any protocol with sufficiently simple multisignature operations (and, in this case, linking tag construction for double-spend protection) will require address/key modifications (but don't have a proof of this conjecture)
01:58:18 <sgp_[m]> My personal opinion is that a change of the address format is bad but not a nonstarter
02:02:14 <sarang> To be clear, addresses can still occupy two group elements and be generated from the same types of seeds and private keys, but need to be constructed with different group arithmetic and used differently under the hood
02:17:51 <UkoeHB> my biased opinion is moving to Seraphis/Lelantus3/?? would be worth the investment in the long run
02:19:32 <sarang> Address migration would be a huge engineering and UX investment, not to mention requiring action from users to continue receiving funds
02:20:25 <sarang> But I agree that currently there's a bit of a brick wall in terms of useful future functionality (streamlined multisig, enhanced opt-in view capabilities, ...)
02:22:25 <boogerlad[m]> monero's no where near mass adoption, so in my view, frequent breaking changes are fine
02:24:57 <sgp_[m]> Having complicated multisig worries me tbh as people actually use it now
02:25:49 <sgp_[m]> Is there a good comparison chart between the three that's updated?
02:27:35 <sarang> No, but I'll work one up for DEF CON
02:27:57 <sarang> The new protocols are so new and in flux :D
02:28:28 <sarang> boogerlad[m]: keep in mind that there's a consensus breaking change with the same addresses, and then there's "everyone needs a new address"...
02:32:08 <boogerlad[m]> very true, exchanges will take their sweet time to upgrade...
02:34:39 <sarang> Well, not really... failing to upgrade with that consensus change would mean you don't get to play on the network anymore
03:47:46 <sgp_[m]> <sarang "The new protocols are so new and"> Yeah this is the crazy part :/
06:34:52 <ErCiccione> Should we set a MRL meeting?
06:39:32 <UkoeHB> might as well
08:00:14 <ErCiccione> We could try again to set a date: Next wednesday?
08:01:20 <UkoeHB> fine with me
08:08:06 <Inge> Is there potential for a re-match between Triptych and Lelantus3 ? 
08:14:28 <ErCiccione> sarang would you be available for a meeting Wednesday 4th?
08:20:48 <UkoeHB> re-match?
08:21:27 <coinstudent2048[> I'll join 😀, as long as it's not before dawn in my side of the world...
08:28:27 <ErCiccione> coinstudent2048: usually meetings are at 16-17 UTC, but it's flexible
09:45:34 <PapuaHardyNet> where do these meetings happen btw?
09:54:39 <Inge> Aqui!
09:54:44 <Inge> (here)
10:08:06 <ErCiccione> While we wait for an answer from sarang: is somebody from core going to be available for a meeting on Wedensday?
10:08:34 <ErCiccione> binaryFate luigi1111 ArticMine fluffypony^
11:34:12 <garth> Sarang: With the new address format be able to be functional alongside the old address format, similar to bitcoin keeping old address formats alongside new Segwit bech32 addresses?
11:34:27 <garth> *Would
11:35:02 <garth> If so, there is a precedent for this working
14:52:09 <binaryFate> I am available on Wed
17:17:43 <ArticMine> I am traveling to Las Vegas on Wednesday. Assuming no flight delay and reliable WiFi on the plane I may be able to attend after 16:00 until ~18:30 UTC
18:32:57 <ErCiccione> Nice. Let's wait for sarang, if he is in i think we have the numbers for a discussion
22:40:18 <selsta> sarang: will lelantus3 be suitable for monero? afaik lelantas 1 and 2 had issues which made it unsuitable for monero
23:47:32 <sarang> Lelantus 1 and 2 have significant limitations and issues with their security proofs
23:47:48 <sarang> Lelantus 3 and Seraphis have similar structures, benefits, and drawbacks
23:48:10 <sarang> (Disclaimer that the Firo project funds Cypher Stack research that includes work on Lelantus 3)
23:48:40 <sarang> The size and verification scaling are similar to that of Triptych, but you get enhanced opt-in view capabilities, much simpler multisig, etc.
23:48:51 <sarang> Downside is a breaking change in address construction
23:49:24 <sarang> Note that Firo plans to use the name "Lelantus Spark" instead of Lelantus 3, apparently
23:49:25 <sarang> shrug
23:49:56 <selsta> Lelantus had some other "downside" but I don't remember it currently.
23:50:08 <sarang> Lelantus 1 didn't support direct anonymous transactions
23:50:16 <sarang> Lelantus 2 had recipient addresses in the clear
23:50:25 <selsta> "self-spend tracing problem"
23:50:30 <selsta> found it in the logs
23:50:31 <sarang> Both had/have flawed balance proofs as well
23:51:15 <sarang> Triptych has the advantage of nice compatibility with the existing codebase and address structure
23:51:26 <UkoeHB> was L3 changed since we last discussed so subaddresses can be supported?
23:51:50 <sarang> Not yet. I asked if this was considered a priority at this time, and was told it was not
23:54:27 <sarang> But some aspects of the design are in flux for efficiency reasons
23:55:09 <wfaressuissia[m]> Are there any competitors for L3 ?
23:55:26 <selsta> UkoeHB's Seraphis
23:56:26 <boogerlad[m]> since subaddresses aren't supported with l3, does that mean scanning times for incoming transactions will be longer? (if implemented)
23:57:15 <sarang> Scanning times would be on par with CryptoNote-type outputs
23:57:49 <sarang> I'm not saying that subaddresses won't be possible, just that they had been considered not a priority for Firo use at this time