14:34:55 <sarang> New preprint that, like Triptych-2, uses an extension to Groth proofs (but in a different way and for a different application): https://eprint.iacr.org/2020/293
14:34:59 <sarang> Crazy timing!
14:54:06 <midipoet> what is the status of Zether, do you know?
15:08:39 <sarang> I do not know
15:10:49 <moneromooo> sarang: was there any known problem with multi sender txes, apart from the privacy leak to other senders in the same tx ?
15:11:29 <sarang> Under what transaction model?
15:11:41 <moneromooo> (and the fact it might not adapt to lelantus/triptych/etc)
15:11:59 <moneromooo> I'm asking with the current MLSAG system.
15:12:01 <sarang> Do you mean back when we discussed MoJoin and similar ideas with MLSAG?
15:12:03 <sarang> Ah
15:12:43 <sarang> In the dealer-free version, an observer could determine the input/output mappings
15:12:54 <moneromooo> Yes.
15:13:07 <sarang> In the dealer version, there was the information leak to the dealer (and partial leak to other senders, since you know which inputs/outputs are not yours)
15:13:40 <sarang> The idea that koe had removes this by adding additional communication requirements and data offsets
15:13:53 <moneromooo> Oh, I missed that...
15:15:28 <sarang> https://www.pdf-archive.com/2020/03/04/zerotomoneromaster-v1-1-0/zerotomoneromaster-v1-1-0.pdf (page 114)
15:16:05 <moneromooo> ty
15:16:17 <sarang> ^ proofreading draft
15:17:18 <sarang> Any of the ideas would require some retooling of the bulletproof generation workflow
15:17:39 <sarang> in addition to the signature stuff
15:39:06 <UkoeHB_> Which next gen protocols would be capable of joint tx?
15:52:29 <needmonero90> Have you checked potcoin
15:52:34 <needmonero90> Sorry I couldn't help myself, carry on
15:59:25 * Inge- hands needmonero90 some kettlecoin
16:00:10 <needmonero90> I heard potcoin was doing research and development into joint txes
16:00:45 * needmonero90 takes the kettlecoin
16:19:24 * UkoeHB_ feels bad
16:42:22 <sarang> UkoeHB_: RCT3, Lelantus, Triptych have linear dependence on signing keys (outside of key images, which are nonlinear)
16:42:30 <sarang> and therefore could be used in this way
16:42:57 <sarang> It isn't clear what would be affected by Triptych-2, which takes a different approach to multi-index signing
16:44:00 <sarang> I suspect it's possible to do multi-signer while keeping indices private in Triptcyh-2, but don't have a protocol for it yet
16:44:38 <sarang> Oh, you also mean non-multisig joint signing, between unrelated parties
16:44:59 <sarang> Triptych-1 definitely works for that as well, since it uses separate proofs per index
16:45:25 <moneromooo> "I suspect it's possible to do multi-signer while keeping indices private in Triptcyh-2" <- oooooh, that sounds very interesting...
16:46:16 <moneromooo> er... is multi-signer multisig (everyone signs all inputs) or multi sender (everyone signs their onw inputs) ?
16:46:21 <sarang> Yeah, I had specifically examined multisig in the context of single keys produced collaboratively (multisig) for Triptych-2, but less about jointly-constructed txs
16:52:38 <sarang> It would be a good addition to the preprint
16:54:06 <sarang> The secret indices come into play with some particular commitments and polynomial coefficients, the signing keys are used in a linear combination with offsets that could probably be done safely between parties, and the output commitments appear similarly
16:54:10 <sarang> Sounds like a fun problem :D
17:08:34 <sarang> Interesting new preprint: https://eprint.iacr.org/2020/289
17:09:09 <sarang> There had been some early interest in Jacobians of hyperelliptic curves for unknown-order constructions, but this calls the practical security and efficiency into question
17:10:54 <sarang> RSA and class groups are other options, but either lack good size efficiency or require trusted group parameter setup
17:29:39 <ArticMine> The idea behind the 00% was to keep some incentive for the the use of more than 2 output txs (smaller size) while pricing as much as possible the linear with number of outputs verification time
17:44:36 <sarang> ArticMine: remind me, was the specific 80% value arbitrary?
17:44:47 <sarang> (I haven't reviewed my logs for the conversation on this)
17:45:00 <sarang> I don't recall there being a deterministic reason for 80% exactly
18:18:46 <ArticMine> It was arbitrary
18:19:10 <sarang> ok, thanks
18:19:11 <sarang> ^ UkoeHB_
18:19:52 <ArticMine> It comes down to relative weight one gives to verification vs size
18:20:02 <sarang> yep
18:20:12 <sarang> UkoeHB_ had asked earlier about the specific value
18:20:28 <sarang> I didn't recall if it was arbitrary or not
18:22:22 <ArticMine> One in principle could make it deterministic if one cold measure the relative impact on the network of a size attack vs a verification attack
18:27:48 <UkoeHB_> 80% seems ok as a ballpark of a more deterministic estimate
18:29:22 <UkoeHB_> The world of safety factors is a lot of intuition lol