The 100 rings in this data which each have 15 ringmembers which are from 16-output transactions, do they correspond with the 100 rings which each have a single 2-output transaction?

I guess it doesn't matter. Deterministic decoy selection of some kind would resolve these oddities and fingerprints

Consensus-level deterministic decoy selection*

blankpage: I noticed that, too. I am pretty sure "yes". I think these are Mordinal transfer transactions. Mordinal transfers choose the 15 deadbeef ring members from this 16-output transaction: xmrchain.net/tx/9f24912088a2d4460e2…03b2369b9434bab9c07cc89746de4481940

I could double check soon.

Makes sense. No need to check really as it doesn't tell us anything which we don't already know, namely that allowing nonstandard decoy selection is just as bad as when we used to allow nonstandard ringsizes from a fungibility point of view.

Yes. It can be as bad as allowing zero-decoy rings. The Mordinal transfers are effectively zero-decoy rings.

MRL issue about decoy selection enforcement: monero-project/research-lab #87

Agreed. The non-deterministic decoy selection is something long known about as a problem.

hi! so I am reading the PayMo paper and I have a question that I think is more "monero" than "paymo". Basically, suppose Alice and Bob each both have a share of a secret spend key (say x_a, x_b, and x = x_a + x_b). Now, I want to sign a transaction. How would one need to modify CLSAG so that each party needs to participate in the signing process but only Bob learns the final signature? I tried to find literature but was unable

to. If anyone could point some directions that would be appreciated :)

neromm[m]: you could do multisig where Alice sends her partial signature to Bob and Bob only computes his own partial signature privately

the code inside this function demoes a comprehensive multisig with clsag github.com/UkoeHB/monero/blob/f63e3…nit_tests/multisig_signing.cpp#L321