00:12:24 atoc from what I can see the dalek libraries seem to lake of the interfaces to implement point hash properly, which is a pity, because with everyhting else it is very easy to use. I was able to implement LSAG for example within a couple of hours. I'm also working towards adding signing to monero-rs, but am trying to bundle and wrap crypto-ops.c instead. 00:13:32 s/lake of/lack/ - lol 00:21:15 TheCharlatan here are some repos sarang shared with me: https://github.com/crate-crypto 00:21:25 How have you found the monero-rs work, TheCharlatan? 00:21:35 I'm trying to get better at Rust :) 00:21:57 sarang: this is a good tut: https://www.youtube.com/watch?v=U1EFgCNLDB8 00:22:26 I saw some other resources too, but Derek Banas is good at doing quick language tuts (typically under an hour) 00:22:57 although I would skip to 20 mins as the first 20 mins of that is pretty basic 00:29:50 fun fact: you can have multiple cli wallets open concurrently 00:34:24 atoc afaik the point hash algorithm is not the same. Their MLSAG implementation uses Ristretto's hash from bytes: https://github.com/crate-crypto/MLSAG/blob/master/src/transcript.rs#L57 , which is not the same as monero's. 00:36:12 sarang, don't have an opinion on it yet. 01:58:20 thinking about escrowed marketplaces.. the transaction graph is a quite troublesome heuristic. I imagine nearly every single marketplace trade looks like: buyer_wallet -> [multisig_wallet, change to buyer_wallet] -> [vendor_wallet, change to buyer_wallet]. There is change in both instances since a buyer will have to over-fill the multisig wallet to 01:58:20 compensate for fees and so on. If those change outputs then get spent together or close together in the buyer's transaction tree.. very obvious spend-loop will reveal real spends with high probability. 02:02:51 miners, pool, escrowed marketplaces, and exchanges, all have bad heuristics 02:10:39 We could do a coinjoin style system. However, we hit a roadblock in that participants have to know more about each other's inputs than we're comfortable with. If you can find a way out, then this would blunt this heuristic a fair bit. 03:49:32 I think it can be done without conveying any information 03:51:21 basically all youre doing is taking a number of transactions and merging them into one; all that's required to hide this fact from observers is sharing some secret scalars amongst participants, which are used to mix up the commitment masks 03:52:47 I noticed you said "sharing some secret scalars amongst participants" :) 03:53:04 That seems to contradict "without conveying any information". 03:53:16 they are just masks that get added or subtracted to the commitments 03:54:01 conveys barely any info how about that lol 03:54:26 basically it indicates which input signatures and outputs belong to each participant, that's it 03:54:38 and it's only known amongst the participants 03:54:40 Well, that's bad, no ? 03:55:12 It means it gives an incentive to some creepy spy to join coinjoin groups. 03:55:19 And they get lots of info about real spends. 03:55:42 dont bitcoin coinjoin participants already get the same info? 03:55:52 I don't know. 03:56:29 Well, they do, since they don't have ring signatures. 03:56:51 there may be a way to use shared secrets so only if all other participants are malicious does the honest signer's inputs and outputs get revealed 03:57:08 but if all are malicious, it's obvious anyway regardless of method 03:57:26 That could be enough... 03:57:44 If you're interested about this, there's a lot of chat about this from... I dunno, a year ago ? 03:58:18 I had a mostly working PoC, but I abandoned it due to this flaw. 03:58:23 I can do a short writeup about my thoughts 03:58:48 sarang has some witty name for it IIRC, which should help grep logs if one remembers what it was... 03:59:30 It would be a most excellent find :) 04:00:24 * moneromooo afk 04:25:36 mojoin 04:26:37 https://github.com/SarangNoether/skunkworks/blob/mojoin/mojoin 04:27:15 The idea was to simplify things a bit by assuming limited information is passed to a designated dealer about the input/output mappings 04:27:27 It hasn't been formalized beyond that brief informal writeup 04:28:09 MLSAGs can be easily replaced with CLSAGs for this purpose 04:29:51 ah trusted dealer problem, didn't think that far ahead damn 04:30:16 The dealer doesn't learn anything about signing indices though 04:30:24 since you clearly own X inputs and outputs, so how the hell do you send them to others without revealing the quantity? 04:31:30 another way might be arbitrary sub-coalition trees, so only pairs or small clusters of participants know the input/output groupings 04:32:17 At any rate, we never determined a way to keep everything secret from all players without some trust designation 04:38:42 koe: also note that the range proof needs to be produced collaboratively as an aggregate to avoid distinguishability 04:38:48 and that carries particular trust requirements as well 04:38:55 This is worked into the mojoin idea 04:39:59 could you do some kind of 'bounce around the circle', incrementally building up the inputs and outputs but making it difficult for any small coalition to figure out the groupings? 04:41:27 or maybe an n-way encryption channel that participants may anonymously submit info to? e.g. signing with a ring signature and encrypting with n-way shared secret 04:43:06 obviously idk about bulletproofs, maybe there are more strict requirements 04:45:03 you can hide the commitment groupings by having shared secrets between each pair of participants, then one in each pair 'adds' fractions of the share key to all their commitments, and the other in the pair 'subtracts' fractions from all their commitments 04:46:00 so there is obviously a setup phase where the total # of participants are known, and each participant must create a share secret with the other and decide who will add and who will subtract 04:47:11 and then the group of participants set up a non-linkable ring signature based n-way encrypted channel, and randomly submit their pieces of the transaction 04:50:07 im reminded of PyBitmessage where messages are sent to a message board, and reverse traceability is hard 04:50:32 the biggest problem is it could be quite slow 04:51:02 if any participant is not online 05:06:48 and linkable ring sigs can be used to sign components where each participant is expected to contribute a piece, perhaps the base transaction private key (to be used for all address in normal case, or Janus mitigation + subaddresses in the special case with individuals contributing the other transaction pub keys for their respective outputs) 05:08:41 there would be some leakage if subaddresses are used, since any participant can test rKs for suspected recipient address (unavoidable given efficient janus method) 05:12:25 ok that's enough out of me, lmk if anyone thinks this is workable (e.g. bulletproofs ??) 13:42:16 atoc there is also https://github.com/cryptonote-rust/raw-crypto . However I am having a hard time trusting some of the things the author did to export it all from the monero source tree; for example some bound checks are missing now. 15:36:01 Redid the mojoin description in Markdown for easier GitHub viewing: https://github.com/SarangNoether/skunkworks/blob/mojoin/mojoin.md 17:02:33 hey wouldn't it be simpler to just to a range proof on the sum of output amounts instead of each one? 17:03:23 You need to know that each output is guaranteed not to be big enough to overflow 17:03:54 But to answer your question, yes, it would be simpler :) 17:05:19 wouldn't it be implied? since it takes like 2^72 outputs to overflow 17:06:12 If they're of the expected amount size 17:06:26 That's the point of the proofs 17:06:32 to assure that this is in fact the case 17:06:45 what am I thinking youre right 17:07:05 If one output is enormous and another is small, the sum could overflow and appear small but reasonably valid 17:07:12 but then you've broken it 17:07:31 For non-join operations, aggregate rangeproofs are super small and fast anyway 17:07:38 yeah that's the whole point of range proofs from the beginning lmao.. my brain likes to jump places without looking 17:07:43 And FWIW there _is_ an MPC for Bulletproofs, but it comes with particular requirements 17:08:03 anyway, is possible or not possible to collaborate on a bulletproof range proof? 17:08:17 One nice thing about the MoJoin dealer trust is that it falls into place with the Bulletproofs trust requirements 17:08:21 Yes 17:08:31 yes to both? impossible! 17:08:36 ? 17:08:43 oh, heh 17:08:58 Yes, it is possible to jointly construct an aggregate rangeproof without revealing private commitment data 17:09:15 is that not enough for the n-way channel proposal? 17:09:19 The proof appears identical to one aggregated by only a single player 17:09:47 It takes 3 rounds and you either need full communication between all players, or dealer trust and 1-to-n communication rounds 17:10:14 I haven't found an exploit that could arise if the dealer is malicious, though 17:10:16 I was thinking, you can mask how many players there are by imagining each output has its own identity 17:10:25 But the SHVZK assumption requires it for the proofs to work 17:12:15 so the addition of a dealer just speeds things up? 17:12:30 Allows for simplified communication, yes 17:12:43 With no trust, it's n-to-n comms for each round 17:12:49 With trust, it's 1-to-n comms 17:12:58 Ok good to know 17:13:10 One player can do the final inner product compression with no trust requirements at the end 17:13:34 The n-to-n is so each player can separately compute the F-S challenges using everyone's partial proof data 17:13:50 If you can trust the dealer to compute the challenge correctly, the dealer can just send the challenges to everyone 17:13:55 but then players can't check them 17:14:00 I think dealer based mojoin is somewhat dead in the water even with the benefits, due to trust requirement. Which is evidenced by the concept getting stuck 1 year ago 17:14:01 So you lose the assumption of honest verifier 17:14:23 IIRC the original concept leaked some particular commitment data 17:14:29 Not sure exactly 17:14:48 This has the advantage of leaking only the mappings, but nothing within particular rings 17:15:13 ok, Ill do a writeup with all my thoughts and indicate the dealer vs n-way approaches 17:15:25 Yeah, I'd love to hear other ideas 17:15:25 will incorporate your doc suggestions as well 17:16:24 Not sure if you were here earlier, but I re-formatted that writeup in markdown 17:16:28 it rendered poorly in github 17:16:35 the monerologs.net has it 17:16:37 No other changes 17:16:38 cool 20:34:29 What’s the limit on number of inputs? I’ve seen 1000+ before IIRC, could I make 10000-in/2-out? 20:34:38 Block size is limit to get on chain 20:35:35 But what about relay/mempool? 21:25:23 Well realistically how many can you fit in a tx? It's like 700 bytes per input, and 2-in2-out is 2500 bytes, and tx max weight is 299400 bytes. 21:26:09 ~426 21:31:58 No 800 bytes per input, ~326 max inputs 21:32:18 373* 21:35:51 wait max tx changed, now 149400 bytes, so 185 inputs 21:46:38 Consensus enforced max tx size? 22:15:45 ~Half the block size max. 22:44:38 It's half the default penalty free zone