14:16:18 <Rucknium[m]> >  Is it the case that if I were to make a, say 1 XMR transaction that has only one input ring. Can I infer that the other transactions that I share a ring with are also around 1 XMR.
14:16:55 <Rucknium[m]> No. It used to be like that before RingCT. Before 2017, rings had to be composed of ring members with the same (transparent) denominations.
14:19:13 <Rucknium[m]> Today, there are some special rules about "unmixable" pre-RingCT outputs that have to get ring members from pre-RingCT transparent denominations. The special rules probably affect fewer than one in 1,000 transactions today. Probably closer to one in 10,000 
14:21:07 <Rucknium[m]> I would defer to jeffro256 or another C++ developer about exactly what information is exchanged. I will try:
14:24:43 <Rucknium[m]> Monero devs figured out how to hide as much information from a potentially malicious surveillance node. The process exchanges a lot of information to hide what information only the wallet knows. In summary, the node sends the wallet a bunch of information about outputs from the blockchain data. The wallet knows what its real spend is. It takes the output information sent from the node and selects its real spend (it has to do
14:24:44 <Rucknium[m]> that) and 15 decoys. It sends back to the node the ring signature. The node doesn't know which of the ring member is the real spend.
14:25:55 <Rucknium[m]> This system doesn't completely eliminate all surveillance risks. Some of those risks are mitigated by wallet software automatically disconnecting from nodes that appear to be trying surveillance tricks.
14:27:00 <Rucknium[m]> Wallets select decoys since they need to hide information about which outputs are decoys from the nodes they are connecting to.
14:29:27 <Rucknium[m]> This process is a major difference compared to how bitcoin and most transparent blockchains construct transactions. A bitcoin wallet can construct a tx without needing any knowledge of what the state of the blockchain is. Since a Monero wallet needs to select decoys, it needs to have updated information about the outputs so it can select decoys. Therefore, it must connect to a node to construct a transaction.
14:30:38 <Rucknium[m]> Exception: We have observed some transactions that just re-use very old outputs as ring members over and over again. The real spend it identifiable trivially. This is not how transactions are supposed to be constructed, but there is no protocol-level rules that prohibits this.
14:37:27 <gingeropolous> i wonder what the system cost would be for a node to check if a transaction is constructed using a ring that is 15/16 similar to an existing transaction
14:43:14 <Rucknium[m]> gingeropolous: IIRC about 1.5 years ago there was a discussion in #monero-dev:monero.social  about it. The initial conclusion was that it would be too costly.
14:44:17 <gingeropolous> yeah to scan through the whole blockchain for matches
14:46:43 <gingeropolous> but i thought the database was superfast
14:53:35 <Rucknium[m]> isthmus already did that: https://libera.monerologs.net/monero-research-lab/20211124#c50834
14:54:10 <Rucknium[m]> There is speculation that gate.io is responsible for those txs
15:00:44 <moneromoooo> gingeropolous: probably not too high. For every tx, you make 16 rings, each made by removing one of the ring members. Save the hash of it. Then, when you get a tx, do the same, but lookup the hash instead of writing it.
15:01:27 <moneromoooo> Takes 512 bytes per tx.
15:02:12 <moneromoooo> So maybe 1 GB to store this for 2 million txes, which is the OOM we have now.
15:02:40 <moneromoooo> You could store truncated hashes to save. 16 bytes might be enough.
15:03:51 <Rucknium[m]> IMHO, probably just better to enforce a standard decoy selection algorithm as part of node tx relay rules. It would prevent these specific types of privacy-damaging ring constructions and many others.
15:40:36 <gingeropolous> well sure. but the enforcable DSA seems to be a thing of .....
15:41:00 <gingeropolous> and something something the best getting in the way of better or however that phrase goes
16:03:01 <Rucknium[m]> gingeropolous: Could you explain? I think we have known how to do an enforceable DSA for years now.
16:05:56 <Rucknium[m]> I think the proposal is in here. Just a modification of ring binning: https://github.com/monero-project/research-lab/issues/84
16:07:00 <Rucknium[m]> From what I understand, enforcement of a DSA can be done with these steps:
16:08:35 <Rucknium[m]> 1) Hash something in the tx. Convert the hash to 16 values drawn from a uniform(0,1) probability distribution.
16:09:44 <Rucknium[m]> 2) Transform those uniform-drawn values by the inverted cumulative distribution function of the DSA that you are enforcing.
16:12:17 <Rucknium[m]> 3) You will get 16 values along the set of eligible outputs. You need just one of them to line up with the real spend. Just choose one of the 16 (maybe one close to the real spend) and add or subtract from the output index values to have one of them line up (the MRL issue uses the term "rotate" I think). Add or subtract that same value from all the 16 values you got.
16:12:50 <Rucknium[m]> You may have to do that add or subtract step to the uniformly selected values. Would need to check on that.
16:13:48 <Rucknium[m]> All of the steps are verifiable by nodes, but nodes don't know which of the 16 values line up with the real spend.
16:14:19 <gingeropolous> right. i feel like it always gets almost there, but then people are like "no we shouldn't do it because of failure conditions"
17:06:29 <jeffro256[m]> <compdec[m]> "I see, so this distribution is..." <- Yes it’s simply a distribution of the number of tx outputs per block