Rucknium: I'd like to nominate two topics for tomorrow's meeting.

- I had a look at hyc's reorg data. as far as the data is representative, it gives cause for optimism with regard to reducing the lock time. monero-project/research-lab #102#issuecomment-1577827259

- earlier this week here I/we wondered where exactly the bottlenecks are on the path to global membership proofs, and whether there is someone who is not yet involved in the effort but whose help could prove meaningful.

kayabanerve: you were right it is RSA based.

The search time tradeoff comes with a massive increase in address and key size, as expected

chaser: Thanks. They are on the agenda: monero-project/meta #846

Meeting 40mins

Meeting time

1. greetings

hello

hi

Hi

Hello

Howdy

hello

Hi

2. updates, what’s everyone working on?

Me: slowly putting together monerokon presentation. I’m considering taking a long break after monerokon to properly reset.

me: OSPEAD

zeroconf webhoooks (LWS), otherwise and p2p-encryption / bp++. both are coming along slowly, but some progress is being made

There is a 90% probability that MAGIC will have something to announce about EAE attack research this week

I examined the long-term reorg data provided hyc

me: adding support for separation of coinbase/non-coinbase output distributions directly into BlockchainLMDB for issue #109

Rucknium[m]: Is it bad....

No

The announcement will be "please, community, fund this research so we know how bad it is"

And how it could be defended against.

3. discussion

I truly wonder how it can be defended against other than churning

yeah, it's an art for now

chaserene: it sounded like you have some things you want to discuss today

Increasing the ring size could help

yes. I wondered where the bottlenecks are exactly on the path to global membership proofs

But it would need to probably be in the thousands of decoys

and whether involving new people and expertise could accelerate progress on it

Maybe ask Bailey if he wants to do this for trustless global membership proofs: Bailey & Miller (2023) "Formalizing Soundness Proofs of SNARKs" eprint.iacr.org/2023/656

<xmrack[m]> "moneroresearch.info..." <- UkoeHB: did you have a chance to read this paper/ have any thoughts on the concept?

Rucknium implied it's mostly a math problem for now, to which I answered that even hiring mathematicians and academics could be an option

Maybe me manage to summon kayabaNerve, because he was so far a main force behind this push

That would also help us figure out what the state of the security proofs are in these papers

kayabanerve: What are the bottlenecks to implementing trustless global membership proofs in Monero?

tevador has also been pretty active in the issue: monero-project/research-lab #100

Rucknium[m]: thanks, that's a point to start at. there are all these researchers on whose efforts Monero is built, but I sense some kind of divide between their world and ours

chaser: IMHO, if you want this to happen, you should contact Bailey

Well, theory and implementing are by very nature quite different already, seems to me

I don't want to do it since I have a lot on my plate already. And cryptography isn't something I know

xmrack[m]: not yet

Sometimes there is a divide since what researchers come up with cannot be practically implemented in Monero (or any other usable system). I guess the idea is that research will eventually fix the problems that an unimplementable idea has.

For example, that paper that xmrack linked that wanted to have address sizes in the kilobytes

Or these papers that want a partitioning decoy selection algorithm. Those are a little closer to being practical, but with disadvantages.

Rucknium: I'm no cryptographer either. I'll take a look at the paper to have at least a basic understanding and see if I can formulate how Bailey can help in this

i would just like to pop this invitation in from QuarksLab (if anyone was interested)- "We can schedule a new presentation of our activities and convictions in the next few days if that suits you, for example: June 8th between 14h and 16h / 13th afternoon /15th between 3pm and 5pm" if someone wants to "know how they could help the project", i am also going to poke the bp++ author again for an update on the final version of the pap

That's why MAGIC says that we would fund actionable research on Monero: monerofund.org/apply_research

plowsof11: that sounds valuable to me

(I wrote it)

Rucknium[m]: That's not necessarily completely infeasible, you already have to copy/paste XMR addresses, and a couple kilobytes can still fit on a QR code

And it needs "A plan to work with Monero's developers and/or researchers to integrate the results of the research into Monero's protocol or ecosystem."

Hardware wallets will surely thank us for 2KB addresses or so ...

Rucknium: yes, this is a much more promising avenue for this than CCS

I dunno, I'm already freaked out by the Jamtis address lengths

plowsof: Are those UTC times?

rbrunner: 2kb….. thats cute. They propose 37kb addresses

:)

oop

I have no idea, i will get the times / tell them UkoeHB wants to attend (hopefully it is not just a sales rep reading a generic pdf)

A presentation from them seems interesting to me

great, ill pass this on and get times / more info

Thanks plowsof11

while we're waiting for kayabanerve or tevador to pop in, I want to put this forward: visualization of hyc's long-term reorg data monero-project/research-lab #102#issuecomment-1577827259

done by me, wholly non-quantitative, but has a few interesting insights

I wanted to bring this up so people can chew on it: is there any downsides to the #109 idea of when spending non-coinbase outputs, only selecting non-coinbase decoys? I have a couple in mind, but I don't want to bias ideas that people may have.

Nice work chaser

jeffro256[m]: Wouldnt an obvious downside be that when a coinbase output is spent it’s guaranteed to be the true spend?

chaser: Thanks for the parsing of the log files. I think we could probably reduce the 10 block lock to 5 blocks. Probably. We would want to do more analysis and thinking about it.

namely,

* reorgs correlate w/ hash power

* reorgs relative to hashpower decreased a lot after Carbon Chameleon, and even more after Fluorine Fermi, and I wonder if you guys have a guess why

You could say if the real spend is a coinbase, then all ring members are coinbase outputs

chaser: I think sech1 helped improve network connectivity and reduced the probability of re-orgs

@xmrack Yes that's biggest one, when miners want to spend outputs it reveals their true spend. This isn't such a big issue for me though, since 1) 90% of miners are either p2pool or trad pool miners so miner spends are already public information or 2) if it's a solo pool miner, they can churn once to a normal output (wallet code would do this default ideally)

Rucknium[m]: a-ha

There was also the changes that ooo implemented which allowed for more p2p connections to stay alive and healty

Rucknium: I would lean toward a more conservative reduction (8?), see how it performs in prod, and reassess whether to keep it, go higher or go lower. I agree with hyc's notion about unknown unknowns earlier in that thread. a reduction would invite more attackers who so far have been outpriced

chaser: I think this was the PR from sech1: monero-project/monero #8675

^^^^^

Rucknium: nice, thanks

If an attacker has enough hashpower to reorg 5 blocks, then Monero has bigger problems than the privacy issue with re-orgs

I agree that when the system changes, you could see the incentives change, so attackers could change behavior. But 5 blocks...?

jeffro256: thanks

Before PR #8426, a lot of connections were getting dropped and stagnating. Afterwards, alive connections went up on average by about 30%

jeffro256: what do you think of Rucknium idea to have coinbase outputs create rings using only other coinbase outputs. This way we stick to our ethos of private by default

chaser: The 10 block lock can only be changed by a hard fork. Stepping it down gradually would take years

jeffro256[m]: from a meta point of view, a special rule for coinbase spends doesn’t solve the root problem which is inadequacy of ring signatures. Setting a precedent could have long term effects… which is an ambiguous complaint.

xmrack[m]: My PR actually does this currently, but it doesn't take into account amounts which reduces the effectiveness

Rucknium[m]: yeah, I know. I can imagine attackers who aren't willing to attempt the whole thing with 10 blocks, but will come out of the shadows with 5. but of course I can't prove it would play out that way

UkoeHB: Yes, but this is a clear cut rule which raises the effective ring size for free in terms of on-chain data, and just a tiny overhead for RPC servers

Obviously nothing is better theoretically than just increasing ring size, but look at the impact in practice, especially with p2pool

You could use the formula for 51% attack success probability to determine the hashpower for an occasionally successful 10 block reorg vs. 5 block reorg with minority hashpower

That path has a clear slippery slope. Say you make it a wallet rule, well now you have implementation variance. In response, we get pressure for a protocol rule. After that might come balance splitting (coinbase/non-coinbase), which is a wallet nightmare. What if some other use-case clearly divides the global money supply? The coinbase precedent will encourage going down the same route again.

IMO the 10-block lock must stay unchanged. Tweak wallets to auto-create change like Monerujo did, if purchase convenience is an issue

A more useful problem to tackle is speeding up IBD further. we've discussed methods a few times already but nothing's come of them.

IBD = initial block distribution?

allow nodes further than N blocks behind to use summary/checkpoint hashes, generated the same way as the hardcoded ones,

yes

D = downuoad

^ yes

10-block lock is a safety factor of at least 2.5, which is a good value. Idk if we can justify a lower safety factor.

yeah, decreasing that is playing with fire

Here's that minority attack formula: worldscientific.com/doi/abs/10.1142/S021902491850053X

UkoeHB: I get the concern, but I don't think I buy this slippery slope argument since there is already a hard protocol difference between coinbase and non-coinbase outputs (coinbase outputs appear in special transactions in the block and have amounts encoded in tx prefix even when version > 1).

Safety factor of 2.5? Is that in the github issue somewhere?

hyc: I agree speeding up IBD is good, but not sure how it's related to the problem caused by the 10-block lock

Well, 5 blocks are still 10 minutes, which won't make all people happy anyway.

chaserene: not related. IMO the 10-block issue needs to be dropped and forgotten.

let the wallets deal with the UX.

Rucknium[m]: with a typical reorg depth of 2-3, we get a safety factor of at least 2.5

Rucknium[m]: I think he means that all the reorgs we see are 2-4 blocks deep

With years between 4 block reorgs, right?

decreasing the 10-block lock is foolish, if not totally reckless.

PocketChange and similar solutions probably reduce privacy. Consolidating pocketchange can improve guessing probability of real spends.

I don't know, those reaorgs don't have a clear date to them in the logs

you will just have to estimate based on the logfile names

and perhaps the line numbers in each logfile

Rucknium[m]: I suppose this is the same problem we have from churning

Maybe some similarities with churning

jeffro256[m]: I’m not convinced, you can use any distinction to make an anonymity puddle. Whether the cause is a protocol rule or a user behavior, the result is the same in terms of privacy.

PocketChange consolidation is basically this problem: Borggren, N., & Yao, L. (2020). "Correlations of multi-input Monero transactions." moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=57

yeah, understood

There is a warning in wallet2 when you spend two real spends that are close to each other in age...and both old, IIRC

<Rucknium[m]> "PocketChange and similar..." <- yes, I really didn't like how the Monerujo dev didn't mention at all the privacy tradeoff

in their announcements

We are approaching the end of the meeting, are there any last-minute questions or comments on other topics?

If coinbase outputs are not excluded from rings, then ring size should be increased to compensate for the number of black marbles that coinbases create

Maybe "proportion" is a better term than "number". Since coinbase outputs are included in proportion to their prevalence in recent blocks

since we want to increase ringsize to N=128 or more anyway, just do that

The formula would be...something...to nominal ring size be equivalent to effective ring size at a particular (lower) ring size.

This issue with coionbase outputs was brought up months ago and there were no strong objections. I asked what the next step were...and nothing

Doesn't matter if ring size is 128, there's still X% of ring members which are coinbase when spending non-coinbase. Why not remove those ring members for free?

So there is a problem with the decisionmaking process here

jeffro's work is a sunk cost, of course. We don't have to do it just because the sunk cost was expended

Removing is not "free", you rise the complexity of the system overall, and the codebase

<UkoeHB> "jeffro256: I’m not convinced..." <- You could say the same thing about pre-RCT decoy selection selecting outputs of the same amount. It creates puddles, but that's alright because the alternative is that cross contamination reduces effective rign size

The protocol becomes one wart more, to put it aggressively ...

*gets

Of course, further research and analysis can uncover issues that were not considered before

This is an unavoidable curse of ring signatures. This overall problem was written when the Cryptonote paper was released

Everyone has accepted this problem

Maybe "everyone" is a bit much :)

There are some protocols that ignore these ring signature problems, e.g. Zano and Mobilecoin. I hope Monero does not become one of them

What I mean is Monero was born with this problem. By trying to improve Monero, you accept that the system is imperfect

Ah, ok, I see

jeffro256[m]: overall I’m not against it being a wallet feature, but we should keep in mind the trade offs and dangers

We are past the hour so I’ll call it here, thanks for attending everyone

Agreed, thanks for letting me bounce ideas off you

just a note on reducing the 10-block lock - you should expect to see a nonlinear, hysteresis effect. not many multi-block reorgs because everyone knows attacking the 10-blocks is too hard.

but as that number comes down, the feasibility of attack will make reorg frequencies increase beyond the rates we see now

That's a good point that I didn't think about

hyc: yes, I agree that this is what would happen. the unknown that is the hash power at the sidelines

that's why I'd support only a very minor reduction, to slowly map out tde terrain that's right now unseen

What would be cool is to have a way to sign an incomplete transaction, missing only the decoys, and send that to a trusted daemon. Upon a reorg X-block-lock deep, the daemon can reconstruct the complete transaction by filling in the decoys and broadcast that transaction instead. Doesn't solve the key image leak problem, but it would increase availability, making those attacks against the network less fruitful

jeffro256[m]: with seraphis you can delegate membership proofs

Absolutely based, that also fixes cold signing transaction with old decoys

chaserene: the problem with mapping out the terrain is when you reach the limit you've just tanked a $3billion network

For long term storage

hyc: And a psychological effect like that could be very discrete. You would not necessarily see any signs of breakage until you lower it by just one block and then deeper reorgs pop up left and right

hyc: fair enough

jeffro256[m]: yes, the discreteness of it probably makes it especially to do it safely

* hard

Its a wallet side ux issue that exists as long as we use rings

Or even full membership proofs, depending on the implementation

I describes an easy to implement wallet sideux feature that gets around it (lockd funds) in probably 99% of cases with minimal privacy reductions from consolidstionsb

ofrnxmr: I'm interested in reading it, where did you publish it?

I think the safety issue would go away if txns referenced outputs by their 32byte hash instead of their 8byte output index

twitter

then most txns remain valid even after a reorg, as long as they're still mined in the new chain too

hyc: the safety issue is that a malicious double-spender can remove their own enotes from the ledger, invalidating txs that reference them as decoys

ah, right

i didnt receive a transactions. can someone help me?

Monero please and thanks

Or #monero-support:monero.social

Rucknium @rucknium:monero.social: There's a few disagreements on how to move forward and a lack of available development

kayabanerve: what do you mean by "available development"?

chaser: Have you implemented SNARKS yet?

That's what I mean :p

Few people here can and no one has published work yet.

I will ask chaser: and Rucknium @rucknium:monero.social: to not contact Bailey at this time though.

I don't believe Bailey is an appropriate fit to contact, unless you just want to contact any researcher in the field. Then sure, they're intelligent, knowledgeable, and security focused. Great.

They have no direct relation to our needs though. The Curve Trees authors would be a much better choice.

kayabanerve: I haven't implemented any of them yet. I suppose that means none of the existing circuits are a fit for Monero?

I'd also ask y'all don't reach out to them though. I've already done so with some replies. I'm still weighing how I want to move forward there, and will sync with the Monero community when I have a path worth discussing.

(Or sure, you can be independent and do so. I just don't want to reach out twice and potentially be a bother. That doesn't justify me monopolizing them)

To be very blunt, and I'm sorry if I'm too rude as I do, if you're asking that question you shouldn't be reaching out to anyone to organize anything.

I don't hold that against you. It just reiterates few people can discuss this at this time, and that limits bandwidth. I appreciate you trying to add bandwidth though.

If you do want to try to help, I'd say reading the entire issue, top to bottom, is sane (unlike the TX extra issue which isn't worth the time).

There are circuits and proofs which are a fit. We need implementations.

kayabanerve: okay, noted, and don't worry. I appreciate both your contributions and your honesty

narodnik has commented on this work. So have I. There's mutual interest with Firo. jberman @jberman:matrix.org: has bullied me ad infinitum to do it.

I'm planning to present, at Monerokon, on this topic, and with it, sync everyone on status. While private/closed doors/black box of me, I'd personally appreciate the opportunity.

To at least start that process now, Curve Trees requires a modified BP, which there isn't a formal protocol for nor security proof of. I realized this about a month ago and reached out to the authors asking if they'd be interested in doing so.

kayabanerve[m]: sounds great, looking forward to that

They replied with the underlying statements necessary to use Bulletproofs to prove, yet not a protocol using Bulletproofs to do so (though they do have a modified PoC which one can be extracted from).

They aren't interested in further work on it at this time, from my understanding.

Or rather, they weren't planning to do further work at this time. I've been personally considering explicitly offering funding to do so, as they may be interested if they have the opportunity, yet I'm unsure that'd be optimal at this time. I need to sync with a few people who may be willing to pick it up themselves.

And because I haven't done such syncing, I don't feel a need to get everyone's opinion. If anyone has contributing opinions, I'd love to hear them. I just know this aspect is semi-needed (there is a much simpler workaround with much worse performance), so from my perspective, moving forward requires either making the alternative's performance acceptable OR finding someone to do the work. I'm uninterested in trying to organiz

authors, or trying to find and organize funding for distinct researchers, when I may be able to arrange for that work to be done myself via another angle.

If the other angle doesn't pan out, then we have to evaluate how much worse worse performance is and discuss community organization of research/fundraising. I would absolutely bring that up, likely initially involving MAGIC. I just haven't brought it up since we're now all spending time on it when it's just another few messages I have to follow up right now.

(Though yes, there's now reason since others are trying to move forward, which I appreciate :) Just clarifying I have been moving forward. there's just angles and intricacies. I should have a proper summary/path for the community by my self-imposed deadline of Monerokon)

And if I didn't have such a deadline, yes, I would've commented much earlier. I'm not trying to prevent other people from hopping in. Solely trying to get some bones down so we don't waste time when we move forward, since I have a definitive time to make such bones or fail to do so.

I think that's all very valuable, thank you for sharing 🙏

(There is also a variety of other research aspects. That's my primary WIP rn)

Further cc: kowalabearhugs- monerobull: tevador:, and I'm already privately syncing with narodnik and a few other parties.

Koe/vtnerd/others would likely also be interested. I just have no actionable reasons to draw them in now, nor am I considering drawing them in yet.

Llama summarize

Literally just I have been privately working on organizing SNARKS a bit more, have nothing worth discussing with the community at this time, and am requesting until Monerokon to present my findings on research and steps forward. That may involve MAGIC/the community coordinating research funding. You were pinged due to that aspect.

kayabanerve: You are still thinking of it as a software engineering problem instead of as a math problem

No security proofs yet? Can't move forward without them. At least, cannot go to mainnet without them

Rucknium @rucknium:monero.social: I literally said I contacted the authors to ask them about their work, and inquired if they'd formalize/prove it.

My entire commentary was about getting it proven.

I also said there was an alternate which wasn't so invasive, just with much less performance. If we can't get the former proven, I'd put forth proving the vastly inferior option.

If we can't prove either at this time, then we'd know the obstacles and leave them to be worked on. I never once suggested deploying unproven protocols. I solely discussed getting the protocols proven.

Thanks. Your summary makes it more clear what your plan would look like.

Sorry for being so defensive here. The reason I wanted to wait to post my conclusions, with an explicit path forward already clear, was to avoid these discussions/criticisms/concerns. I do plan to properly comment on the proofs, the protocols, the algorithms, the security of each component, and what they each need. Any in-development view would be partial, as my initial commentary here was. It's frustrating for me that as I

commenting, to prevent seeing wasted efforts, I now have these concerns raised.