<j​effro256:monero.social> @Rucknium can we put preliminary Carrot audit discussion on the agenda for tomorrow please? I don't expect any decisions this week, but just a general discussion of where we're headed with that

<r​ucknium:monero.social> jeffro256: Sure. What is the current link for the Carrot document(s)?

<s​needlewoods:monero.social> I think it's this one github.com/jeffro256/carrot/blob/master/carrot.md

<r​ucknium:monero.social> MRL meeting in this room in one hour.

<r​ucknium:monero.social> In two hours I mean

<r​ucknium:monero.social> Meeting time! monero-project/meta #1070

<j​effro256:monero.social> howdy

<r​ucknium:monero.social> 1) Greetings

<c​haser:monero.social> hello

<v​tnerd:monero.social> Hi

Hello

<j​berman:monero.social> *waves*

<b​oog900:monero.social> hi

<r​ucknium:monero.social> 2) Updates. What is everyone working on?

<k​ayabanerve:matrix.org> 👋

<v​tnerd:monero.social> Got stuck with some LWS stuff, but back on hackerone stuff

<j​effro256:monero.social> me: done getting first proposals back for Carrot audit quotes. DM me if you want to see the proposals and/or my comparison. Also just adding finishing touches and preparing for an implementation PR

<r​ucknium:monero.social> me: Some double spend probability analysis for the N blocks lock discussion. Some analysis of issues in the Chainalysis video. Finishing up analysis of node tx relay logs for black marble source detection (preview: it was made very difficult after a code fix in 2019).

<j​berman:monero.social> me: fcmp++, implemented trimming the tree on reorg/pop blocks, implemented multithreaded tree building, moving to the key image migration next

<r​ucknium:monero.social> 3) Stress testing monerod. monero-project/monero #9348

<r​ucknium:monero.social> AFAIK there are no new updates about stressnet

<r​ucknium:monero.social> 4) Research Pre-Seraphis Full-Chain Membership Proofs. Reviews for Carrot. github.com/jeffro256/carrot/blob/master/carrot.md

<k​ayabanerve:matrix.org> I'll raise the question of a consensus rule vs output index binding.

<k​ayabanerve:matrix.org> jeffro256: did you form an opinion on which side you prefer?

<0​xfffc:monero.social> ( apologies for being late. Hi everyone )

<j​effro256:monero.social> I think I prefer the consensus rule again since implementing output index binding causes an extra round for collaborative protocols anyways, *and* adds the round to normal wallet workflows.

<k​ayabanerve:matrix.org> Sorry, how does output index binding add a round to the normal wallet workflow?

<j​effro256:monero.social> As long as this rule is well documented, I don't see it being an issue. And anyways, it should be best practice for collaborative protocols to commit-and-reveal their transaction components anyways to prevent any accidental interdependence

<k​ayabanerve:matrix.org> The amount commitment doesn't need to bind to the input context. If we share the amount commitment with the key images, there's no complexities to the flow there.

<k​ayabanerve:matrix.org> Unless I'm missing something, sorry if I am.

<j​effro256:monero.social> You have to do your amount commitment derivations for all enotes first, then sort them within the transaction and assign `output_index`, and then complete the enotes. Whereas without ouput index binding, all enotes are completely derived in parallel and only sorted at the end

Ah, you are talking about internal wallet "workflow"

<k​ayabanerve:matrix.org> I'll drop it even though I truly hate the idea of using consensus rules to solve the burning bug.

<j​effro256:monero.social> The amount commitment binding to the input context isn't the complication, it's the `output_index` being dependent on a component inside the enote that complicates things for wallet code

<j​effro256:monero.social> I did the whole rewrite of Carrot for binding to `output_index` instead of relying on the consensus rule, and it was pretty hairy I gotta say

<k​ayabanerve:matrix.org> Can I bully you by pointing out there's a random chance TXs will fail naturally if we use a consensus rule due to the minimized amount of entropy

<k​ayabanerve:matrix.org> ... Hm. I wonder that the exact odds of that are. I'm unsure it's as high as 2**64 because there's a pool of n outputs. It may actually be something we as humans would naturally stumble onto...

<j​effro256:monero.social> You can bully me lol but what do you mean about the minimized amount of entropy?

<k​ayabanerve:matrix.org> We're only using 16 bytes for entropy during the derivations?

<k​ayabanerve:matrix.org> If two outputs happen to have the same entropy, they'll trigger this consensus rule and cause a failure? You need to derive entropy and do a uniqueness check prior to doing the full derivations?

<j​effro256:monero.social> Is 16 max outputs enough for that effect to be noticeable (assuming we sent all to the same address anyway)? I mean I guess it's technically lower than 128 bits so....

<k​ayabanerve:matrix.org> Because I think at best this is a 1/2**64 chance, but the fact it's any 2 of the n outputs in a transaction may reduce that further to the point yes, we do actually need code for that.

<k​ayabanerve:matrix.org> I assume the check the entropy is unique before deriving is simple enough to implement tbf.

<j​effro256:monero.social> I don't think it's as low as 2**64 since the result space isn't 128 bits, its 256 bits

<k​ayabanerve:matrix.org> ... except it only has 16 bytes of entropy?

<k​ayabanerve:matrix.org> I'm looking to collide the preimage, not the hash.

<k​ayabanerve:matrix.org> Can we move on to whatever other topics we have on the agenda today by at least acknowledging checking the entropy is unique is a viable solution if this is a problem? We can discuss statistics/implementation/how that complexity compares to other complexity later?

<j​effro256:monero.social> Yes and 2**64 is the expected value assuming you get as many samples as you want, no? The real probability for a preimage collision in a 16-out tx (assuming your machine's entropy is good) is 1/(2**128-1) * 1/(2**128-2) * 1/(2**128-3) * ... * (1/2**128 - 15)

<r​ucknium:monero.social> jeffro256: You wanted to talk about Carrot reviews, right?

<j​effro256:monero.social> Oops formatting. Yeah, we can move on. I will look into it for sure

<j​effro256:monero.social> github.com/jeffro256/carrot/blob/master/carrot.md

<j​effro256:monero.social> So I solicited quotes from different auditing firms for the Carrot specification. For all of them, I requested that the general specification be reviewed to find any glaring vulnerabilities, but more concretely, to create security proofs for the security properties in Section 9 (except for Janus resistance). My first question: is this the best way to go about scoping the Carrot au<clipped messag

<j​effro256:monero.social> dit in term of what the community needs?

<k​ayabanerve:matrix.org> Oh gosh, you may be right this isn't what I was thinking yet is properly defined as a multi-target collision where each new entropy is checked against all existing entropy. That'd be 2**k / n (where n is the amount of already sampled entropy). Sorry if I did botch that.

<k​ayabanerve:matrix.org> Your definition for auditing seems reasonable to me *though I haven't reviewed every line item in that section*.

Why the exception for Janus resistance?

If that can be explained in some simple terms :)

<k​ayabanerve:matrix.org> I ask the same question but without the "if" 👀

<j​effro256:monero.social> I got some feedback that Janus attack resistance might be slightly harder to prove, which might raise costs

<j​effro256:monero.social> I asked for a less formal review of Janus resistance, but that can certainly be upgraded if desired

Well, lately donors were extremely generous. At least some of them, it seems. Maybe if do all that effort, spending some more might still be worth it

<j​effro256:monero.social> It does take up a good chunk in the number of steps in the enote scan process, so it might be worth reviewing more formally just because of that complexity

<j​effro256:monero.social> Okay I will inquire into that and report on it when that information becomes available

<j​effro256:monero.social> Second note: The most expensive firm which responded had a quote 5x higher than the cheapest firm. On the one hand, they valued their man-hours at about 2.5x higehr rate than the cheapest firm, so they were likely going to be more expensive regardless. However, they also estimated the number of man-hours required to be 2x than the cheapest firm. One of these firms is probably misg<clipped messag

<j​effro256:monero.social> uided on the effort required, or they understood the scope to be of different depths. At any rate, I need to sync with them on that to see where the man-hour discrepancies lie.

It's easy to ask other people's money shall get spent, but I would feel better if all components there get equal treatment

<k​ayabanerve:matrix.org> Can we get two quotes? With/without?

<j​effro256:monero.social> Yes, I will ask

<j​effro256:monero.social> At what point does the marginal utility of a formal security proof get outweighed by its cost?

<c​haser:monero.social> such a difference makes me want to know the firms. I know it's been decided to be withheld, but still.

<k​ayabanerve:matrix.org> Depends on the cost :D get us numbers jeffro

<r​ucknium:monero.social> Janus only affects privacy, right? Just so I understand right

<k​ayabanerve:matrix.org> I'll personally pay at least an extra $10 for this so we can set a floor there

<j​effro256:monero.social> lmao

<r​ucknium:monero.social> AFAIK FCMP++ is spending a little below expected budget for the research side, so it's probably worth it.

<k​ayabanerve:matrix.org> Janus is where someone has two public addresses and confirms they are held by the same entity

<r​ucknium:monero.social> *puts 10 USD in my willingness-to-pay privacy calculator*

<j​effro256:monero.social> Yeah Janus affects off-chain privacy: the ability to correlate two Monero addresses to the same user. The attack needs to be actively started by sending funds

<r​ucknium:monero.social> It is not a theft risk nor a counterfeiting risk.

<k​ayabanerve:matrix.org> The legitimate worst case is linking an anonymous profile to a doxxed one.

<r​ucknium:monero.social> AFAIK Seraphis-Jamtis was supposed to eliminate the Janus attack. So it would be good if Carrot does too

<k​ayabanerve:matrix.org> Nope

<k​ayabanerve:matrix.org> Nor a DoS

<r​ucknium:monero.social> I thought one of the variants eliminated it?

<k​ayabanerve:matrix.org> This is the same technique as JAMTIS AFAIK.

<r​ucknium:monero.social> Oh. You were responding to my previous message

<k​ayabanerve:matrix.org> Nope was it to not being a theft risk, sorry for the confusion.

<k​ayabanerve:matrix.org> Obviously, jeffro256 to confirm, yet an unproven Carrot presumably is as good at stopping Janus as an unproven Seraphis JAMTIS? Same guts on this matter?

<j​effro256:monero.social> Yeah btw Carrot should have feature parity with Jamtis except for 1) subaddress lookahead tables are still required 2) no fancy probabilistic light wallet servers, and 3) the key exchange is *slightly* slower

<j​effro256:monero.social> It doesn't use the same technique, but they both should have cryptographic strength at blocking Janus attacks AFAIK

<k​ayabanerve:matrix.org> Oh. My bad, sorry.

<j​effro256:monero.social> Jamtis does a third Diffie-Helman key exchange and binds to that in the amount commitment, while Carrot basically does an HMAC and stuffs it in the space where Jamtis address tags would be

<r​ucknium:monero.social> I think MRL wants to get quotes for both with/without Janus.

<j​effro256:monero.social> What should the upper limit of our budget be for Carrot in general? 40K, 50K, 60K USD? For transparency, the highest quote I received was for 100K USD, which I think is likely too high for this work in the depth that we need it

<j​effro256:monero.social> This is with *less formal* Janus review, but it's still defined to be in-scope

<c​haser:monero.social> 20K (the cheapest offer) definitely sounds too low, so 40K minimum?

How many offers did you receive so far?

<k​ayabanerve:matrix.org> Are we including proof review, not including proof review, or not doing proof review?

<k​ayabanerve:matrix.org> Can you DM me all the groups you reached out to thus far?

<r​ucknium:monero.social> One entity needs to write the proofs and another has to review, right? This would only be for writing them, right?

<j​effro256:monero.social> rbrunner: 4

Ok, might be enough to learn about "reasonable" regarding amounts by comparing them

<j​effro256:monero.social> We could do a review of the written proofs. I wonder how much value that would bring given that Monero addressing schemes are already relatively well understood

<j​effro256:monero.social> A review of the implementation code is definitely more important in my opinion

<r​ucknium:monero.social> We have two more agenda items. jeffro256 , do you have everything you need until the next meeting?

<j​effro256:monero.social> I think so yes. I told the firms that we would have a discussion where the representatives could pop into the meeting and discuss pros/cons of their proposal. Would next week be a good time for that?

<r​ucknium:monero.social> That sounds great.

<r​ucknium:monero.social> 5) 10 block lock discussion monero-project/research-lab #102 github.com/AaronFeickert/pup-monero-lock/releases/tag/final

<r​ucknium:monero.social> kayabanerve at last meetng suggested that the N block lock should be set so that the mining pool with the highest hashpower share (currently about 30%) should have a 1% or less probability of success of re-orging the chain N blocks deep through a double-spend attack.

<r​ucknium:monero.social> If you thought users liked the 10 block lock, they're going to love

<r​ucknium:monero.social> the 20 block lock

<r​ucknium:monero.social> I used Theorem 1 of Grunspan & Perez-Marco (2018) "Double spend races" to produce this table: gist.github.com/Rucknium/da1e57b1864aca477dfa3b4e02e86e26

<r​ucknium:monero.social> The formula assumes that the adversary keeps mining on the attacking chain for an infinitely long period of time if they don't succeed after N blocks. That's usually not economically rational.

<r​ucknium:monero.social> Grunspan & Perez-Marco (2021) "On Profitability of Nakamoto Double Spend" considers scenarios when the attacker breaks off the attack after falling behind the honest chain. I plugged in a few numbers. The results don't change much with this economic rationality formula because of the parameters we're working with. The attacker already accepts a 99% probability of failure.

<r​ucknium:monero.social> If a 20 block lock is considered too long, then you can change the assumptions. Lower the hashpower share of the attacker or increase the acceptable attack success probability.

<r​ucknium:monero.social> Or just say that only benign re-orgs will be considered for the N block lock analysis

The cell with 0.86739 is the one, right, row 20, column 0.3

<k​ayabanerve:matrix.org> Sorry, what are the cells?

<r​ucknium:monero.social> Right

<c​haser:monero.social> nice work Rucknium, I'll read it with more active attention after the meeting. I want to say that looking at current hash rates of pools is an insufficient metric IMHO. the economic feasibility of a related attack depends on the depth N. if N is lowered, more hash power may come online from the sideliness to carry out an attack, because they are no longer priced out.

The table in that gist

<r​ucknium:monero.social> Probability of attack success

<k​ayabanerve:matrix.org> I understand the row and column definition. I'm unclear what the cells are.

Percentages of success?

Yeah, Rucknium does not fail to surprise :)

<c​haser:monero.social> essentially, a dark forest scenario.

But so far what this does *not* hint at IMHO is that 10 is already overlay cautious

<r​ucknium:monero.social> chaser: I agree. However, 30% is already very high for a hidden adversary. Just 20% more and the attacker can execute a malicious re-org for any confirmation wait time.

<k​ayabanerve:matrix.org> 10% of hash power over 5 years makes a 10-block reorg likely, if I'm interpreting this correctly?

<k​ayabanerve:matrix.org> I'd consider that secure and not call for further raising the lock

<r​ucknium:monero.social> Years? The sequential numbers down the rows are the number of blocks that an attacker could re-org in a single attack attempt

<k​ayabanerve:matrix.org> 100/c, where c is the cell value, for the amount of attempts. Then I said 20 minutes per attempt as the goal is a 10-block reorg (which is 20 minutes of time).

<k​ayabanerve:matrix.org> That value, for a 10% attacker, is roughly 5 years.

<r​ucknium:monero.social> If you allow the attacker to attack over and over again, the necessary block lock to prevent all attacks would be huge

<k​ayabanerve:matrix.org> *I'm perfectly aware that's not the proper formula, I just wanted an offhand estimate of how long an adversary with 10% would need before they stumble onto a successful reorg.

<j​effro256:monero.social> Is that the probability of attack success that a single, given block at the top of the chain will get reorged by the largest malicious mining party in some finite timeframe?

<c​haser:monero.social> Rucknium: that would be new-entrant hash power, so essentially +100% on top of what we have now. I 'm honestly not sure if that's low or high, but also consider that Monero is non-ASIC, so there is a lot of hardware out there that can be repurposed to support a reorg attack.

<k​ayabanerve:matrix.org> I'm not asking about preventing all locks. I'm curious how long it takes before they stumble onto it. I can't reasonably argue an adversary would pay for 10% of the hash power for *years* just to perform a DoS here.

<k​ayabanerve:matrix.org> But there may be value to an adversary in having a large amount of hash power for days, or weeks, to perform even just a DoS.

<r​ucknium:monero.social> jeffro256: The first row is just probability of re-orging one block with a single attack. The model assume that the attacker gets a head start of one block. The attacker is basically constantly mining until they get that one-block head start

<r​ucknium:monero.social> If people are wondering "How secure is PoW, really?", then you can read Budish, E. (2022). "The Economic Limits of Bitcoin and Anonymous, Decentralized Trust on the Blockchain." moneroresearch.info/index.php?actio…n=resource_RESOURCEVIEW_CORE&id=101

<j​effro256:monero.social> What is a single attack "attempt"? How long does it take for this attacker to give up on a failed attack?

<r​ucknium:monero.social> Budish recently released an updated draft a few months ago

Maybe after much back and forth with will find out, in a few weeks, that - surprise - 10 blocks are just *perfect*

<r​ucknium:monero.social> jeffro256: In this model, the attack continues forever. If the attacker "loses" the race to the N blocks, he/she can still win later because of random block arrivals

<r​ucknium:monero.social> In the second paper Grunspan & Perez-Marco (2021). "On Profitability of Nakamoto Double Spend."

<r​ucknium:monero.social> they consider the attacker breaking off the attack if he/she loses the first part of the race

<r​ucknium:monero.social> But anyway, I put some number in that Grunspan & Perez-Marco (2021) formula and didn't see much difference

<k​ayabanerve:matrix.org> So if they 'start a new attempt' to reroll a 1% chance, it's of no difference to continuing the existing attack?

<k​ayabanerve:matrix.org> I'm not surprised by that statement, but the numbers in the table don't mentally click for me to be in line with that statement

<r​ucknium:monero.social> "it's of no difference to continuing the existing attack" What do you mean?

<r​ucknium:monero.social> The traditional 6 block confirmation time for bitcoin comes from the slightly incoirrect original formula from Staoshi where the attacker has 10% hashpower share and less than 0.1% probability of success. See Table 1 of Grunspan & Perez-Marco (2018) moneroresearch.info/index.php?actio…n=resource_RESOURCEVIEW_CORE&id=192

<r​ucknium:monero.social> Satoshi*

Interesting

<r​ucknium:monero.social> I want to get to the Chainalysis video. Maybe we can digest this info later, discuss the video now

<k​ayabanerve:matrix.org> If I have 10% of the hash power and want to do a 10-block reorg, what period of time do I need to maintain 10% of the hash power before I successfully pull off such an unlikely event?

<k​ayabanerve:matrix.org> That's the question I've been trying to get to, but sure, we can circle back lager

<k​ayabanerve:matrix.org> *later

<r​ucknium:monero.social> Ok I can try to answer for you later. It's not difficult to compute because the attempts are independent

<r​ucknium:monero.social> 6) Chainalysis capabilities video

<r​ucknium:monero.social> Sometimes I read papers about attacks that seem a little contrived. I think "Is anyone listening? Does anyone care?" Now I know that Chainalysis is listening and caring.

<r​ucknium:monero.social> In other words, this gives us a lower bound on the resources they have put into attacking the privacy on Monero users.

<c​haser:monero.social> I watched it and I wasn't too surprised. the edge they have will be mostly curbed by FCMP++. on top of that the main assets for them are weaknesses in transfer-layer privacy, which they formed by running swarms of their own nodes.

<r​ucknium:monero.social> Some interesting things: There are a few abbreviated variables attached to transactions that the presenter doesn't explain. Any ideas what those could be?

<c​haser:monero.social> I felt that the recent further looking-into into D++ is a worthy direction.

<j​effro256:monero.social> A lot of government provided IP address information was used in the analysis. Makes monero-project/monero #8996 a bit more important than I originally anticipated

<j​effro256:monero.social> chaser: agreed

<c​haser:monero.social> Rucknium I can't recall the abbreviations, could you give a time stamp?

<r​ucknium:monero.social> They have the time difference between when one of their nodes observed the txs relayed for the first and second time. If they don't have network topology info, the first-spy estimator is best. I wonder if they are trying a topology-based estimator. It may be possible to take the time delay data they display, put it into a complex statistical model, and get an estimate for the numb<clipped message

<r​ucknium:monero.social> er of malicious nodes they are running.

<r​ucknium:monero.social> chaser: About 19:00

<r​ucknium:monero.social> "Transaction features box"

<k​ayabanerve:matrix.org> Wallet trees would mean a passively malicious node doesn't learn any additional info on the outputs spent.

<c​haser:monero.social> 10/+ is probably decoy count?

<r​ucknium:monero.social> IMHO, fee uniformity should be a near-term research priority. Fees were at the top of their tx indistinguishably list.

<r​ucknium:monero.social> chaser: The `K,E` part

<k​ayabanerve:matrix.org> The fundamental technique can be done with outputs today, it'd just use a lot more wallet storage.

<c​haser:monero.social> I was just about to say this. discretized fees, here we go again!

Well, cough, with Seraphis we would get these, if I remember correctly ...

<b​oog900:monero.social> I _think_ it's the details of the extra field

<r​ucknium:monero.social> IMHO, at a minimum it makes sense to charge fees based on the number of inputs/outputs and any extra tx_extra info instead of the exact number of bytes.

<b​oog900:monero.social> K being a public key, E being an encrypted payment ID and AK being additional public keys

<j​effro256:monero.social> rbrunner: we can do discretized fees in RingCT if we just restrict the `txnFee` field to only so many values by validator rule

<r​ucknium:monero.social> It's really hard right now to even confirm that a wallet has standard fees since txs have variable-length integers that make tx sizes slightly different.

<c​haser:monero.social> boog900 I think so too

<j​effro256:monero.social> boog900: yeah I remember them mentioning "key order" as a feature which, yeah, might be what this

<k​ayabanerve:matrix.org> Yes buy that shouldn't be fingerprintable Rucknium

<j​effro256:monero.social> IIRC a long time ago one could tell which transactions were cold signed because they had 2 tx pubkey fields in `tx_extra` instead of 1

<k​ayabanerve:matrix.org> The Monero wallet deals with that in a way. As long as everyone doing custom fee code matches that way, it's not distinguishable

<r​ucknium:monero.social> There are so many wallets that dont do that

<k​ayabanerve:matrix.org> I just want to clarify AFAICT, this is to force alt wallets in line, not to resolve fundamental issues

<k​ayabanerve:matrix.org> Extra field presence/ordering has been a topic for a while, someone has a data set

<r​ucknium:monero.social> And I have no function that I can input a Monero tx in and get the standard wallet2 fee

<k​ayabanerve:matrix.org> Heard. I do support this work TBC.

<r​ucknium:monero.social> The "problem" with discretized fees is that it doesn't fix nonstandard fees that are very far from "standard", which is a lot of them

<k​ayabanerve:matrix.org> Explicitly giving each output its own key in a structured position? Sounds great

<r​ucknium:monero.social> A lot of wallets aren't even trying

<r​ucknium:monero.social> Reference: github.com/Rucknium/misc-research/tree/main/Monero-Nonstandard-Fees

<r​ucknium:monero.social> So we need....price control! :P

<k​ayabanerve:matrix.org> Bit shilly, yet getting exactly in line with wallet2 was a couple weeks of work for monero-serai. I fully understand how nontrivial it is

<c​haser:monero.social> kayabanerve isn't "force alt wallets in line" the way to solve the fundamental issue?

<k​ayabanerve:matrix.org> (shout out to jberman who actually did it)

<r​ucknium:monero.social> The price controls issue is what makes this hard. And the interaction with the dynamic block size, miner fee penalties, etc

<k​ayabanerve:matrix.org> Yes chaser. My comment was this isn't wallet2 that is fingerprinting users. It's alt wallets which are. Users can use wallet2 without worrying their personal running of the software will fingerprint them across TXs.

<r​ucknium:monero.social> A nice thing about discretized fees is it fixes an issue with an EAE attack that is even possible with FCMP++: If a user spends the whole balance, then the only difference that Eve sees is the tx fee, which are different for many txs.

<k​ayabanerve:matrix.org> That isn't to downplay the issue. that's to not have people concerned about its a protocol failure (rather than a shortcoming of it to handle lazy wallet devs)

<r​ucknium:monero.social> All wallet devs are lazy until proven otherwise :P

<k​ayabanerve:matrix.org> I proved otherwise :(((

<c​haser:monero.social> kayabanerve got it.

<r​ucknium:monero.social> I mean, they take the shortest path to get something working, usually

kayabanerve, not til you publish monero-wallet to crates.io :^)

<r​ucknium:monero.social> More topics on the video?

<c​haser:monero.social> I'm very much on board with making as much of the fee function part of consensus as possible.

(kayaba: jk just releease me from needing to use serai as a submodule, señor)

<c​haser:monero.social> well, I have one but may be out of scope for the meeting

rucknium: re the video, would it be helpful to scrape more information from the presentation?

the information from the spreadsheets shown, that is

<k​ayabanerve:matrix.org> Sneurlax: Cargo.toml a git revision?

<r​ucknium:monero.social> This nice post by Stnby and Siren suggests that Chainanlysis may have taken advantage of old DNS configs to "hijack" "trusted" remote nodes: digilol.net/blog/chainanalysis-malicious-xmr.html

<c​haser:monero.social> what would cryptography that conceals in/out numbers look like? in/out arity was another factor they used.

<k​ayabanerve:matrix.org> Every TX would be n/n

With tons of fake stuff for simple txs?

<r​ucknium:monero.social> sneurlax: Yes, especially the relay timing info in `ms`. Later I could try to do something with that to estimate their number of spy nodes. I have been reading so many gossip protocol papers lately :D

<c​haser:monero.social> I hope something else we thought would be mathematically impossible will see the light of day

<k​ayabanerve:matrix.org> Zero-value ins/outs for padding

<r​ucknium:monero.social> chaser: You can bring it up

<c​haser:monero.social> (Rucknium: this is it, arity)

<c​haser:monero.social> tevador had an idea for discretized arity, I'll dig it up

<r​ucknium:monero.social> Oh, I forgot I had make another two tables

<r​ucknium:monero.social> Tabulation of Monero transaction inputs and outputs gist.github.com/Rucknium/d2c02f51a2d9f103a28caa8f51be7dbf

<j​effro256:monero.social> With dummy inputs, every single transaction could be a 2/2, and owners of funds can still split/consolidate funds to/from `N` TXOs in `O(log(N))` time

<r​ucknium:monero.social> The most import info is how many txs have 3+ inputs. At that point, consolidation heuristics might help adversaries narrow down which ring member is the real spend.

<k​ayabanerve:matrix.org> jeffro256: you're a horrible person for not at least giving us 4/4.

<r​ucknium:monero.social> About 7 percent of txs have 3 or more inputs. So the Chainalysis method of collecting info about who owns which outputs, then analyzing many-input txs, would usually only be applicable to about 7% of txs as an upper bound.

<r​ucknium:monero.social> Maybe you could try that consolidation analysis with txs with only 2 inputs. I don't know.

<r​ucknium:monero.social> Actually the probability hasn't been formally analyzed

<j​effro256:monero.social> lol every tx being 256/16 should cover most usecases, mempool handling code be damned

<j​effro256:monero.social> Wouldn't it be applicable to all txs since those 7% could (maybe, big assumption) be eliminated as decoys?

<r​ucknium:monero.social> For the false positive rate of analyzing tx uniformity defects in single-ring transactions, I developed an exact formula in github.com/Rucknium/misc-research/b…-spend-with-fungibility-defects.pdf

<c​haser:monero.social> Dummy transaction inputs (tevador): monero-project/research-lab #96

<c​haser:monero.social> increasing uniformity of number of inputs/outputs (my generalized take): monero-project/research-lab #114

<r​ucknium:monero.social> The formula is equation 12, a little complicated already

<c​haser:monero.social> IMHO restricting ins to 2^n (n>0) and outs to constant 2 could go a long way

<r​ucknium:monero.social> jeffro256: Do you mean with a chain-reaction analysis?

<c​haser:monero.social> ^ my gut instinct exactly

<k​ayabanerve:matrix.org> I can't endorse 2/2 compared to 4/4, personally.

<k​ayabanerve:matrix.org> 2/2 will be hours of delay and requires perfect precision w.r.t. output usage planning. It also will hit wallet UX.

<r​ucknium:monero.social> IMHO, there is not a developed theory about why diverse in/outs are inherently bad, except that allowing many inputs can help an adversary perform the consolidation analysis when ring size is finite. Nonstandard fees are inherently bad because the wallet produces them _every time_, so an adversary can link the txs easier. a wallet won't produce the same in/outs every time

<k​ayabanerve:matrix.org> *hours of delay at scale. 256 outputs take 8 hops or 2.66h as of right now. It's 1.33h with 4 which is still a massive hit compared to as many inputs as fit.

<c​haser:monero.social> Rucknium I agree that fee uniformity is a more pressing issue

<r​ucknium:monero.social> What comes to mind is that a txs with many inputs or many outputs is more likely to belong to a service. A miner or merchant consolidating txs with many inputs. An exchange sending txs out to many users in a single batch would use many outputs.

<c​haser:monero.social> well, these guys love giving visits to services

<r​ucknium:monero.social> If Monero requires 2/2 for all txs, then no one will have to worry about the privacy of those services since they won't exist. (this is a joke)

<j​effro256:monero.social> lol

<c​haser:monero.social> this behavior could be eliminated by restricting just outs to 2, with dummy if needed. the practicality issues are heavier with restricting ins

<r​ucknium:monero.social> We are at two hours. Marathon meeting. Thanks all for attending and working so hard to improve Monero. If you didn't see the video, Chainalysis praises Monero developers for their hard work lol

<c​haser:monero.social> let services send individual tx's. a service can afford forethought in output planning

<c​haser:monero.social> yeah, thank you all

<r​ucknium:monero.social> The meeting can end here. Feel free to continue discussing issues.

<j​effro256:monero.social> Thanks, everyone!

<c​haser:monero.social> updated draft, clocking an impressive 71 pages:

<c​haser:monero.social> Budish: Trust at Scale: The Economic Limits of Cryptocurrencies and Blockchains (July 2024)

<c​haser:monero.social> ericbudish.org/wp-content/uploads/2…s-of-Cryptocurrencies-July-2024.pdf

<c​haser:monero.social> a lot of complementary material here: ericbudish.org/publication/the-econ…imits-of-bitcoin-and-the-blockchain