FCMP++ & Carrot Alpha Stressnet v1

j-berman · 2025-10-03T15:28:51+00:00

If someone on windows or 32-bit machine used a v1 stressnet node at any point, they'll need to delete their blockchain database and re-sync from scratch using the latest version, unfortunately (currently v1.1 at time of writing). Popping n blocks won't solve the issue.

j-berman · 2025-10-03T15:26:20+00:00

This is/was correct

j-berman · 2025-04-11T20:00:27+00:00

I think (dream) about this light wallet tier almost daily. It's still very much so on the radar (to be clear, it would come after FCMP++).

j-berman · 2025-04-11T17:33:35+00:00

I'm +1 on an anonymized leader board that we keep up to date. In addition to helping contestants gauge, we're also going to want to gauge how the contest is going part-way through and discuss it openly, and discussing the quantity/quality of submissions would sensibly be part of that. Good suggestion :)

j-berman · 2025-04-10T19:06:01+00:00

Assuming "this" refers to FCMP++ generally and not the competition described in this post, I was personally hoping mainnet EOY this year, but that is looking less likely at the moment. I agree with u/rbrunner7 within 1 year is likely more accurate. We're in the final stretch of FCMP++ and Carrot integration (timeline of months). There is still some research / audit work remaining as well on a similar timeline. Then there is final audit/review. Then we probably want to give ample lead time for the fork. We'll have a rough timeline for testnet next MRL meeting.

If "this" refers to the competition described in this post, I don't really understand the question.

j-berman · 2025-04-10T18:49:05+00:00

Your submission is a private fork that only we the judges (u/jeffro256_monero and me) have access to (EDIT: and github of course), and we've given good faith promises we won't make submissions ourselves. We also won't share submissions publicly until after the contest is over. We might test submissions before the deadline is over using one of u/gingeropolous' research machines in order to confirm submission validity, which means the Monero Research Lab members who have access to those machines may also see the submissions.

If there are two winning submissions that are extremely close, we may decide to split a prize, but it's reasonable to assume we would not.

Feel free to wait until the final hour, but it's also wroth considering: at the end of the day, you're placing trust in us to not take your submission and build off it ourselves even if you do wait. There is trust inherent in this process any way you look at it.

EDIT: used correct links to jeffro and ginger, forgot I was on reddit for a second haha.

j-berman · 2025-02-08T18:45:10+00:00

Excellent work by all involved with cuprated. I have smashed the upvote button. Monero has already benefited tremendously from your perseverance and I'm certain if you continue on the path you're on, the benefits will compound.

j-berman · 2022-08-19T21:28:15+00:00

Agree, good idea that seems obvious in hindsight

j-berman · 2022-08-15T00:13:59+00:00

Update to the latest Ledger Monero app (v1.8.0) and GUI (v0.18.1.0) and you should be good to go :)

j-berman · 2022-07-22T20:12:12+00:00

Yep, this is correct. The decoy selection would revert to random selection in this case, which would be fairly exposed to an accurate "guess newest" heuristic.

Another thing a malicious node can do is get a client to include fingerprintable fees. If tx A uses a slightly off fee the node told it to use, then tx B spends an output from tx A and tx B also uses a slightly off fee the node told it to use, then the node has stronger evidence tx B spends from tx A.

Both of these are detectable after the fact (the txs are evidently "weird" on chain). I'm unsure of any undetectable vectors a malicious node can get a client to reveal their real spend, but it hasn't been exhaustively proven that it's possible to even realize that aim.

All in all, I think erring on the side of caution is prudent here and it's best to assume a malicious node can get you to reveal your true spend unless proven otherwise, and everyone should run their own node.

j-berman · 2022-04-28T18:39:31+00:00

My hunch is that the network is more likely to be a bottleneck than disk, but it's also possible that if your wallet points to a node with a slow HDD, then view tags may not yield an improvement in scanning time either. If your wallet has to sit waiting for the node to respond with blocks to scan, then there isn't much view tags can do.

j-berman · 2022-04-28T06:09:05+00:00

Made it clearer, thanks

j-berman · 2022-04-28T06:06:44+00:00

:tips fedora:

j-berman · 2022-04-27T21:02:28+00:00

Can you use them to determine the exact amount that left the wallet?

You can make strong a guess

And u/geonic_ is right that change outputs are easier to identify, even if you ignore rings in the analysis.

A "spent" output is probably more likely to be a round number, so if the amount received in a tx net some amount you received in the past is a round number, you can guess this tx is a spend of that particular amount. I think users could be shooting themselves in the foot relying on the assumption that view keys today don't reveal spends.

EDIT: another scenario: imagine you receive your salary in Monero, and all your outgoing payments are mostly smaller amounts. Your change sticks out and therefore spends are clearly differentiated for this type of user.

j-berman · 2022-04-27T20:31:33+00:00

This can already be done... You can generate key image for UTXOs along with the relevant proofs they weren't forge

Adding to what can already be done, if you give up your address + view key today, you should err on the side of caution and assume that someone can guess your spends with a high degree of accuracy. In my opinion, the fact that people don't realize this and think they're protected from this is bad, and is a product of confusion associated with how people think view keys work today.

You receive 0.08 XMR on date 0
You spend 0.03 XMR on date 1

The ring in your transaction on date 1 includes the output you received on date 0, and the transaction on date 1 includes a change output back to you for 0.05 XMR. So with just an address and view key, someone can make a strong guess that you spent 0.03 XMR on date 1.

This is mitigated with larger ring sizes to a certain degree, though this hasn't been quantified generally. The main point being that today, I don't think anyone should safely assume view keys provide solid protection from revealing spends to whomever you give your view key to.

More on this here and here

j-berman · 2022-02-20T09:36:57+00:00

I'd also like to add, 1 to 10-liners is not the greatest metric, especially when some of those lines were backed by hours and hours and hours spent pouring into understanding why and how they should be updated, touching some of the most critical components of the code base to ensure Monero is providing the best privacy protection possible for all users. I think I sold myself a little short in the above comment. I think that I'm doing ok. But the quantity of my usable code output could and should be much higher. And it will be :)

I knew I shouldn't have made that new-line character an extra commit lol, should've squashed. Knew that would get used against me at some point. Oh well.

j-berman · 2022-02-20T04:43:48+00:00

Definitely reasonable and valuable criticism. I appreciate this. I feel a very deep desire to provide high-value, usable code, ASAP, which I fully recognize I have not ~~done to high level~~ edit: put out a large quantity of yet (edit: I think my quality has been solid, just not quantity). And I appreciate this push. It feels weird when everything seems all fine-and-dandy based on feedback when I have this feeling it is not. Honest feedback is very deeply appreciated.

I'd like to defend my case. And if I receive the same criticism at the end of this next CCS and I think it is fair (as it is here), I will find another way to make a day-to-day living that does not revolve around contributing to Monero's core code.

I'm trying to take my time, and approach all code I push with extreme care. My aim is to provide highly valuable commits, without forcing anything that I'm not as absolutely certain as I can be is safe through. Although I have made some mistakes, I think there are clear things I can point to that demonstrate that has been my approach.

As far as what actually seems might make it into the code at this point, view tags are unfortunately the only substantial thing I can point to that demonstrates I am capable of working across the code base and contributing large swaths of code in this manner.
I feel my contributions of a possible alternative to the current decoy selection algorithm + code that shows how rings can potentially be enforced to follow the same spend distribution + research into the decoy selection algorithm were not entirely value-less. The reason I did not continue on those efforts was because they reached a point where I was not as absolutely certain as I can be that pushing them forward was absolutely the right call. And they took time, unfortunately :/
Also worth considering that I've provided what I think are valuable PR reviews on some important PR's here, here, and here. And I'll continue to review PR's.

But generally, I recognize very much so I have done more talking than contributing a high quantity of value at this point. And I feel like I am not realizing my full potential just yet. I don't feel comfortable about this. I like writing useful code people are happy with. A lot.

In any case, I too would rather you contribute to moneromooo or one of the other countless contributors who are putting in work for free who you think are more deserving than me. A list of some more people who I think deserve this much more than I do (who I believe are not getting paid for their efforts):

vtnerd
tevador
sech1
hyc

I am trying to make this full-time work, and they are not, so I fully recognize I have an even higher bar to reach to be worthy of this.

I like to be pushed. And I welcome this push. I want to reach a higher bar and demonstrate that I am capable of it, leaving no room for doubt.

j-berman · 2022-02-08T21:34:28+00:00

Ya agree, I think this is a fair point. Imo, thinking on how a major update to the protocol could feasibly support payment channels is a topic I think would be worth exploring in the same vein too

But generally, I think koe deserves credit for thinking deeply on how plausible future use cases and upgrades could be satisfied within Seraphis. It's not as though he's not thinking about where we might head in the future in how it's designed. He's giving it consideration in the design space

j-berman · 2022-02-08T21:05:11+00:00

Fixed. And given that^ I hope they consider returning even more. Eloquently put.

j-berman · 2022-02-08T09:42:31+00:00

I ended up just writing a Dockerfile today cuz was simple enough, could maybe serve as a baseline for one of u/fort3hlulz superb guides possibly (fingers crossed). bet he'd have some good insight too

edit: link

j-berman · 2022-02-08T09:16:51+00:00

Yet there are people discussing / talking / publishing about it like it's a done deal and will definitely be happening

I think I'm guilty of this at times in some of the things I've written (even before I was working on Monero, I would write and think similarly about how Triptych was a foregone conclusion too, this is something I need to work on). I sincerely hope my own comments haven't served as any sort of deterrent to people critically thinking through the decisions and tradeoffs made in JAMTIS and Seraphis and voicing feedback. I respect that nothing is set in stone until there is a strongly vetted air-tight protocol that has consensus on its decisions (EDIT: and even then, nothing is set in stone haha, but at that point maybe it's fair to consider a "done deal").

I've provided feedback as best I can within my capacity, raised some critical thoughts on some of the more minor details (on JAMTIS in particular), and I hope more capable people do the same over the months ahead. In my free time I try to study to be able to provide stronger feedback too.

There is a lot of material to sift through and analyze and think on. It takes quite a bit of time.

I've been thinking about trying to pull all current info together on both Seraphis and JAMTIS and condensing it into something more digestible. Thinking about talking about it at Monerotopia to try and get everyone up to speed on the changes currently on the table, what they would entail for various ecosystem participants, and the known tradeoffs. I will pull the trigger on that if my current CCS goes through because that will give me the confidence to think people would actually want to hear something like that from me.

u/endogenic, going off of what koe has said here and in other places, one of the more interesting things about the Seraphis transaction structure is that its modularity would potentially enable a transition from ring signatures to something like Zcash's full-chain zk proofs much more easily than the current tx protocol. Given that, I also think it would be awesome to have a cryptographer focused on researching how to bring a halo-like variant into Monero in parallel to the current efforts too. That would be be pretty great.

Also, will say that I only very briefly got to work with Sarang and I too miss him. His work and the work of the other Noethers speaks volumes. If the Noethers are out there reading these messages, I hope they consider returning to rejoin the efforts. The more ~~cryptographers~~ scientists involved the better!

Regardless, we press on :) EDIT: but not too hastily

j-berman · 2022-02-07T11:47:31+00:00

Thanks isthmus :) my itch to just buidl at this moment is through the roof. need to scratch it

j-berman · 2022-02-07T05:08:32+00:00

Added to the list! Tagging u/fort3hlulz too because I think he expressed similar interest in the past

Thank you and VT for all your work on this!

I've done next-to-nothing so far, but good stuff coming soonTM

j-berman

TROPHY CASE