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.

s/lake of/lack/ - lol

TheCharlatan here are some repos sarang shared with me: github.com/crate-crypto

How have you found the monero-rs work, TheCharlatan?

I'm trying to get better at Rust :)

sarang: this is a good tut: youtube.com/watch?v=U1EFgCNLDB8

I saw some other resources too, but Derek Banas is good at doing quick language tuts (typically under an hour)

although I would skip to 20 mins as the first 20 mins of that is pretty basic

fun fact: you can have multiple cli wallets open concurrently

atoc afaik the point hash algorithm is not the same. Their MLSAG implementation uses Ristretto's hash from bytes: github.com/crate-crypto/MLSAG/blob/master/src/transcript.rs#L57 , which is not the same as monero's.

sarang, don't have an opinion on it yet.

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

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.

miners, pool, escrowed marketplaces, and exchanges, all have bad heuristics

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.

I think it can be done without conveying any information

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

I noticed you said "sharing some secret scalars amongst participants" :)

That seems to contradict "without conveying any information".

they are just masks that get added or subtracted to the commitments

conveys barely any info how about that lol

basically it indicates which input signatures and outputs belong to each participant, that's it

and it's only known amongst the participants

Well, that's bad, no ?

It means it gives an incentive to some creepy spy to join coinjoin groups.

And they get lots of info about real spends.

dont bitcoin coinjoin participants already get the same info?

I don't know.

Well, they do, since they don't have ring signatures.

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

but if all are malicious, it's obvious anyway regardless of method

That could be enough...

If you're interested about this, there's a lot of chat about this from... I dunno, a year ago ?

I had a mostly working PoC, but I abandoned it due to this flaw.

I can do a short writeup about my thoughts

sarang has some witty name for it IIRC, which should help grep logs if one remembers what it was...

It would be a most excellent find :)

mojoin

The idea was to simplify things a bit by assuming limited information is passed to a designated dealer about the input/output mappings

It hasn't been formalized beyond that brief informal writeup

MLSAGs can be easily replaced with CLSAGs for this purpose

ah trusted dealer problem, didn't think that far ahead damn

The dealer doesn't learn anything about signing indices though

since you clearly own X inputs and outputs, so how the hell do you send them to others without revealing the quantity?

another way might be arbitrary sub-coalition trees, so only pairs or small clusters of participants know the input/output groupings

At any rate, we never determined a way to keep everything secret from all players without some trust designation

koe: also note that the range proof needs to be produced collaboratively as an aggregate to avoid distinguishability

and that carries particular trust requirements as well

This is worked into the mojoin idea

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?

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

obviously idk about bulletproofs, maybe there are more strict requirements

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

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

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

im reminded of PyBitmessage where messages are sent to a message board, and reverse traceability is hard

the biggest problem is it could be quite slow

if any participant is not online

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)

there would be some leakage if subaddresses are used, since any participant can test rKs for suspected recipient address (unavoidable given efficient janus method)

ok that's enough out of me, lmk if anyone thinks this is workable (e.g. bulletproofs ??)

atoc there is also 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.

Redid the mojoin description in Markdown for easier GitHub viewing: github.com/SarangNoether/skunkworks/blob/mojoin/mojoin.md

hey wouldn't it be simpler to just to a range proof on the sum of output amounts instead of each one?

You need to know that each output is guaranteed not to be big enough to overflow

But to answer your question, yes, it would be simpler :)

wouldn't it be implied? since it takes like 2^72 outputs to overflow

If they're of the expected amount size

That's the point of the proofs

to assure that this is in fact the case

what am I thinking youre right

If one output is enormous and another is small, the sum could overflow and appear small but reasonably valid

but then you've broken it

For non-join operations, aggregate rangeproofs are super small and fast anyway

yeah that's the whole point of range proofs from the beginning lmao.. my brain likes to jump places without looking

And FWIW there _is_ an MPC for Bulletproofs, but it comes with particular requirements

anyway, is possible or not possible to collaborate on a bulletproof range proof?

One nice thing about the MoJoin dealer trust is that it falls into place with the Bulletproofs trust requirements

Yes

yes to both? impossible!

?

oh, heh

Yes, it is possible to jointly construct an aggregate rangeproof without revealing private commitment data

is that not enough for the n-way channel proposal?

The proof appears identical to one aggregated by only a single player

It takes 3 rounds and you either need full communication between all players, or dealer trust and 1-to-n communication rounds

I haven't found an exploit that could arise if the dealer is malicious, though

I was thinking, you can mask how many players there are by imagining each output has its own identity

But the SHVZK assumption requires it for the proofs to work

so the addition of a dealer just speeds things up?

Allows for simplified communication, yes

With no trust, it's n-to-n comms for each round

With trust, it's 1-to-n comms

Ok good to know

One player can do the final inner product compression with no trust requirements at the end

The n-to-n is so each player can separately compute the F-S challenges using everyone's partial proof data

If you can trust the dealer to compute the challenge correctly, the dealer can just send the challenges to everyone

but then players can't check them

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

So you lose the assumption of honest verifier

IIRC the original concept leaked some particular commitment data

Not sure exactly

This has the advantage of leaking only the mappings, but nothing within particular rings

ok, Ill do a writeup with all my thoughts and indicate the dealer vs n-way approaches

Yeah, I'd love to hear other ideas

will incorporate your doc suggestions as well

Not sure if you were here earlier, but I re-formatted that writeup in markdown

it rendered poorly in github

the monerologs.net has it

No other changes

cool

What’s the limit on number of inputs? I’ve seen 1000+ before IIRC, could I make 10000-in/2-out?

Block size is limit to get on chain

But what about relay/mempool?

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.

~426

No 800 bytes per input, ~326 max inputs

373*

wait max tx changed, now 149400 bytes, so 185 inputs

Consensus enforced max tx size?

~Half the block size max.

It's half the default penalty free zone