-
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
-
-
jberman[m]
## Results of the fix
-
jberman[m]
I simulated get_outs using the proposed fix, and plotted against the current:
-
-
-
-
UkoeHB
Sounds good to me
-
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
-
sarang
At any rate, the communication complexity remains high
-
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
-
sarang
Downside is that like Seraphis, it requires a modified address format
-
sarang
(Disclaimer: Cypher Stack receives funding by the Firo project in part to develop the Lelantus 3 protocol)
-
sarang
We're still working on the transaction and ledger security model for the protocol
-
sarang
The new constructions are a parallel Groth-Bootle proving system and a modified Chaum-Pedersen proof
-
sarang
The security proofs for parallel Groth-Bootle are straightforward
-
sarang
and the Chaum-Pedersen security proof holds under particular assumptions about the prover statements that hold for the application used in the protocol
-
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
-
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
-
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
-
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)
-
sgp_[m]
My personal opinion is that a change of the address format is bad but not a nonstarter
-
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
-
UkoeHB
my biased opinion is moving to Seraphis/Lelantus3/?? would be worth the investment in the long run
-
sarang
Address migration would be a huge engineering and UX investment, not to mention requiring action from users to continue receiving funds
-
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, ...)
-
boogerlad[m]
monero's no where near mass adoption, so in my view, frequent breaking changes are fine
-
sgp_[m]
Having complicated multisig worries me tbh as people actually use it now
-
sgp_[m]
Is there a good comparison chart between the three that's updated?
-
sarang
No, but I'll work one up for DEF CON
-
sarang
The new protocols are so new and in flux :D
-
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"...
-
boogerlad[m]
very true, exchanges will take their sweet time to upgrade...
-
sarang
Well, not really... failing to upgrade with that consensus change would mean you don't get to play on the network anymore
-
sgp_[m]
<sarang "The new protocols are so new and"> Yeah this is the crazy part :/
-
ErCiccione
Should we set a MRL meeting?
-
UkoeHB
might as well
-
ErCiccione
We could try again to set a date: Next wednesday?
-
UkoeHB
fine with me
-
Inge
Is there potential for a re-match between Triptych and Lelantus3 ?
-
ErCiccione
sarang would you be available for a meeting Wednesday 4th?
-
UkoeHB
re-match?
-
coinstudent2048[
I'll join 😀, as long as it's not before dawn in my side of the world...
-
ErCiccione
coinstudent2048: usually meetings are at 16-17 UTC, but it's flexible
-
PapuaHardyNet
where do these meetings happen btw?
-
Inge
Aqui!
-
Inge
(here)
-
ErCiccione
While we wait for an answer from sarang: is somebody from core going to be available for a meeting on Wedensday?
-
ErCiccione
binaryFate luigi1111 ArticMine fluffypony^
-
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?
-
garth
*Would
-
garth
If so, there is a precedent for this working
-
binaryFate
I am available on Wed
-
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
-
ErCiccione
Nice. Let's wait for sarang, if he is in i think we have the numbers for a discussion
-
selsta
sarang: will lelantus3 be suitable for monero? afaik lelantas 1 and 2 had issues which made it unsuitable for monero
-
sarang
Lelantus 1 and 2 have significant limitations and issues with their security proofs
-
sarang
Lelantus 3 and Seraphis have similar structures, benefits, and drawbacks
-
sarang
(Disclaimer that the Firo project funds Cypher Stack research that includes work on Lelantus 3)
-
sarang
The size and verification scaling are similar to that of Triptych, but you get enhanced opt-in view capabilities, much simpler multisig, etc.
-
sarang
Downside is a breaking change in address construction
-
sarang
Note that Firo plans to use the name "Lelantus Spark" instead of Lelantus 3, apparently
-
sarang
shrug
-
selsta
Lelantus had some other "downside" but I don't remember it currently.
-
sarang
Lelantus 1 didn't support direct anonymous transactions
-
sarang
Lelantus 2 had recipient addresses in the clear
-
selsta
"self-spend tracing problem"
-
selsta
found it in the logs
-
sarang
Both had/have flawed balance proofs as well
-
sarang
Triptych has the advantage of nice compatibility with the existing codebase and address structure
-
UkoeHB
was L3 changed since we last discussed so subaddresses can be supported?
-
sarang
Not yet. I asked if this was considered a priority at this time, and was told it was not
-
sarang
But some aspects of the design are in flux for efficiency reasons
-
wfaressuissia[m]
Are there any competitors for L3 ?
-
selsta
UkoeHB's Seraphis
-
boogerlad[m]
since subaddresses aren't supported with l3, does that mean scanning times for incoming transactions will be longer? (if implemented)
-
sarang
Scanning times would be on par with CryptoNote-type outputs
-
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