The authors reached back out to me and said:... (full message at <libera.ems.host/_matrix/media/v3/do…0fbe5928dd720bcb83b491b0f9d23486340>)

kayabanerve:

Thanks for the update

i can never make this meet cos i have a math study course conflict

If there is something in particular you'd like to discuss, it's perfectly fine to announce in advance you'll be around at such time to discuss such subject, and anyone who wants to be around to discuss it then is welcome.

The same kind of time on another day is likely prefered for timezone reasons.

Or just write your comments on whatever issues you want to comment on, if you're not looking for discussion, just giving feedback/opinion.

Great job on the P2Pool payout efficiency upgrade, sech1! In preliminary data I am already seeing an impact on mean empirical effective ring size. Last week it was about 13.5 . So far this week it is about 14.25. (Ideal is 16.)

It will take a few weeks for the majority of the impact to appear because of how the decoy selection algorithm selections historical outputs. So I will wait a bit to post charts.

I am using the definition of Empirical effective ring size = Consensus-enforced ring size minus Number of coinbase outputs in each ring on the blockchain.

Ideal is not 16, you have to account for ~720 coinbase outputs that appear on the chain every day in any case

so it's close to 16, but not exactly 16

16 minus epsilon. Asymptotically 16 :)

Just a reminder for observers of the channel what the max is.

720 coinbase outputs is about 1-2% of all outputs, given ~20k tx/day

so ideal should be 16*0.99 = 15.84? If my math makes sense

The above is because miners are deemed to always/mostly consolidate, rather than actually spend ?

s/spend/use without consolidation/

Big pools make payouts once every few hours, or just once a day. If on average they find multiple blocks between payouts, they have no option but to consolidate.

Yes "In most transactions, p2pool outputs can be ruled out as the real spend because p2pool miners need to consolidate their payouts in transactions with a large number of inputs. Furthermore, the miners' addresses are in plaintext on the p2pool side chain, observable by Monero privacy adversaries." monero-project/research-lab #109

(quoting myself)

And yes, p2pool miners almost always consolidate

on that Rucknium working on producing that data regarding p2pool identifiable consolidations

will re-import all p2pool history around and build the output index table for fast lookups

DataHoarder: Thanks!

Meeting 3hr

is there a special room for the meeting?

No, should start here now

This is the room. ⏰

Youre in it, meeting should start momentarily

UkoeHB usually starts it.

I will wing it. Meeting time! monero-project/meta #815

Say hi everyone

Hi

Hello

Hey

Hello

Howdy

Updates: What is everyone working on?

hello

me: have preliminary script to collect all RingCT rings. So far I have used it to check how the P2Pool payout efficiency upgrade has improved effective ring size: github.com/Rucknium/misc-research/t…ree/main/Monero-Effective-Ring-Size

This can be used to check the effect of Mordinals/NFTs on effective ring size if and when I parse tx_extra for Mordinals' designated tag

I’ve been working on adding k-anonymity to the monero block explorer to give users more privacy.

isthmus has closed his work-in-progress CCS to help with computational speedup of OSPEAD due to not enough labour bandwidth. I am seeking other forms of help now.

I'm working on the transaction_history for the seraphis_wallet which will be a layer above the "seraphis_engine".

I have it working for blocks at the moment but need to add a range search to Lmdb to allow for transaction hashes. Hyc is helping me with that

What is k-anonymity?

I explain here moneroexamples/onion-monero-blockchain-explorer #284

Thanks

ah crap got distracted, hi

The deadline for MoneroKon submissions is April 3rd: cfp.monerokon.com/2023/cfp

Tl:dr instead of a user requesting a single tx hash which the block explorer can confidently assume belongs to the requesting ip address. They will provide the first 5 characters of the hash and the explorer will return all possible k matches. Hence, k-anonymity

i just started looking into the new rangeproof a bit and try to understand it

hi

hi

To use that, I will just need some HTML with a form and the necessary JavaScript to issue to that newly k-anonymity capable block explorer?

Rucknium: (diego is here on hand for when bp++ peer review funding is to be discussed)

ye

my update: did a refactor of the seraphis scanning framework to better support async backends, right now working on integrating checkpoint caches into the seraphis enote store

Do any other XMR block explorers have k-anonymity? This seems like a great privacy improvement for the general user

plowsof: IMHO, we should discuss that first since tx_extra is potentially unlimited discussion: repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/358

rbrunner: yea javascript will be needed, unfortunately, to filter all the data returned

It should be super straightforward from the frontend perspective

xmrack[m]: What about the compact filters approach that Neutrino uses?

I see, thanks

plowsof11: it looks like the bp++ paper is still not updated

xmrack: IMHO, timing is still an issue with 5-character hash prefix.

after 3+ months wait - the bp++ paper has not been updated, and my lines of communication with the author have dried up. correct UkoeHB

depending on how "Range Proofs with Constant Size and Trustless Setup" performs, we could maybe skip bp++ and just use this instead?

plowsof11 I thought blockstream hired him, maybe worth reaching out

You would only get about one tx per week with 5 character prefix I think. Most people look up recent txs

atomfried[m]: it sounds like that new paper is missing a proper security model

I suggested that we return to the CCS after 3 months if there was no paper update. It has been three months

ah

UkoeHB: yes, thats not included in the paper, maybe it was not in the paper due to a pagelimit

Rucknium: timing data should have no effect on this. All data is sent to the client, then the client loops through the data and pulls out the block/tx they want

The authors of the constant size rangeproofs (needs a shorter name!) will be at the meeting next week yes?

The 5 character prefix is subject to change. I need to run benchmarks to see what acceptable bandwidth looks like

move bp++ peer review to funding as is vote? or

blankpage: Good point. Maybe the next step will be clearer once we discuss that paper with the authors

For example we could ask "do you have a security model?"

blankpage: yes they mentioned they were busy today but will be here to answer questions next week

Do we know how far vtnerd is with their BP++ implementation already?

move bp++ peer review to funding as is vote? or wait for next week after constand sized range proofs meetings?

Paper authors sort of vanishing make me a bit nervious ...

Or the CCS is rewritten as "research, implement & audit next generation range proofs" so that it covers b++ and/or the new thing

(Putting up for funding leaves time to raise the money so we are ready when/if. Can always repurpose the funds for alternative solution)

i think its a simple case of : he is now employed / busy on other things, i can make a last attempt to contact blockstream before next weeks meeting?

Blockstream's focus is BTC. They probably don't particularly want to help Monero FWIW

i have this feeling too

blankpage: sounds good to me - anybody against?

xmrack I guess the consideration is whether the block explorer has a powerful heuristic by guessing that the intended query is the most recent of the returned set of k.

Don't have clear and focussed CCS a better resonance than such "this or maybe this"?

I would not be in favor of a CCS that is so vague on what the task is and who would accomplish it

Usually it does not take long to fund a CCS, I would say. We probably won't bump against a wait of, say, a month or so.

Considering the "open ended" nature of this stuff, is MAGIC maybe a better fit?

Well, it's only open ended if we don't bring with us the patience to wait until we have a clear direction :)

xmrack: the problem you're trying to solve is known as "private information retrieval", or PIR, and it's been around for a while. You need homomorphic encryption to make a block explorer that truly knows nothing about what the client is asking for. Such an explorer exists for Bitcoin in an experimental state: btc.usespiral.com I know the developers and can get you in touch with them so that you can make a similar

one for XMR.

Blockstream uses rangeproofs BTW for confidential amounts on their "liquid network". Idk if they are jumping into this new rangeproof though.

rbrunner: has nothing to do with patience

blankpage: ahhhh I see, I thought you meant side channel timing data like packet times. Guess newest heuristic could be true especially singe I will need to scan the mempool. I will work with Rucknium to figure it out

It uses lattice-based cryptography.

*since

rewrite the ccs = back to the drawing table for quotes from multiple companies

So for now plowsof @plowsof:matrix.org: sounds like do nothing

Alex | LocalMonero | AgoraDesk: sounds interesting

Alex|LocalMonero: could this also work for light wallets?

atomfried[m]: Probably but it's way more complex due to homomorphic encryption constraints.

IMHO, more programmer-cryptographers like koe and kayabanerve should give opinions about what to do about the BP++ paper

And wait for the new rangeproof paper authors next week

xmrack[m]: eprint.iacr.org/2022/368

👋

Homomorphic encryption allows you to perform operations on encrypted data without decrypting it. Such as checking an address for txs.

Just finished reading up

The downside is that its very space-inefficient nowadays.

sounds good, we can TBD next week, thanks for attending Diego Salazar

ye

Homomorphic encryption is quite bleeding edge AFAIK...meaning users may get cut

BP++ is beyond me. I can't encourage deployment without review from people its not.

Rucknium[m]: PIR block explorers are probably the least dangerous production battleground to test this tech out.

My one candidate is sarang. I would hold off until this constant time proof has an initial eval. That means source access + benchmarking + a security proof.

Alex | LocalMonero | AgoraDesk: You're probably right.

Currently, I believe the authors didn't make a CSRP sec proof. I have heard commentary the applicability is a bit... Hand waved.

I look forward to hearing more from the authors on the matter. They didn't respond to me, yet someone else. I believe they'll be here next week?

xmrack: github.com/ahenzinger/simplepir is currently the fastest PIR server I know.

I don't think BP++ has a security proof either. Does it?

If CSRP doesn't have a sec proof, I'd move forward with BP++.

I believe ++ has a proof, yet also a TODO somewhere in the paper?

I don't believe that TODO is relevant to us but I can double check now.

yeah might as well stop waiting on BP++

TBC, without a publication for and proof of CSRP, it's interesting but a non starter.

I'm willing to wait a week to hear back from the CSRP authors, as I do believe they're interested in attending next week's meeting...

kayabanerve: Thanks for your input

the peer review is step 1 of <many> , entire project is being delayed imo

BP++, 8.1, proving and verification time is incomplete. 9, proofs, is not.

xmrack: Are they trying to attend the meeting next week?

Yes

Just triple checking :)

I'd call to hold off on any decisions until after then.

But BP++ should be moved forward with.

kayabanerve: "moved forward with"?

And while I don't want to force a topic change, I do have a question for tevador of larger interest.

Rucknium: There's no reason to hold off on it currently, other than potential greater interest in this constant sized proof.

xmrack[m]: Ideas for doing k-anonymity client side without JS, use fragment hash CSS styling of page via targeting stackoverflow.com/questions/3655278…ent-identifier-hash-in-the-url-refe but the hard part would be sending the user to the proper page (maybe abuse max length on fields) JavaScript

could be needed to redirect user to results page, but not on the filtering part. Maybe good for linking to the page by other places

If the CSRP becomes a non-factor, we should conduct peer review on it.

kayabanerve: Go ahead and change topics

tevador: I don't believe an indirect curve cycle is possible due to the fact we need to do an ECC op *and* membership. Do you have any thoughts on this?

To be clear, the proof needs to substract the blinding factor, then prove the unblinded point is a member. tevador found an efficient indirect cycle, letting us stay on Ed25519, but the indirect cycle *can't* do ECC ops unless it rebuilds a calculator on the arithmetic level.

*binary level

Completely infeasible

So that means we'd need to do ECC ops on the tower, and then use that unblinded point on the cycle. I'm unsure we can efficiently do that since we have to maintain ZK.

We can trivially prove the ECC op on the tower, get the output point, and move that to the cycle. It just wouldn't be ZK.

... It may be possible with a Pedersen commitment? And then we'd have to prove two EC ops on the tower and open the commitment in the cycle?

Anyways. I wanted to get tevador's thoughts in this and if I wasn't missing anything, move the discussion back to switching curves, despite the potential avoidance noted by tevador.

... Doesn't seem like we'll get a response this meeting 😅 My thoughts/updates on the SNARK design discussion have been made available. I don't have anything else to say as part of it right now :) Thanks for the opportunity Rucknium:

Meeting is over :)

Thanks for hosting Rucknium, and all in attendance 🙏

Thanks Rucknium ❤️

Thanks Ruck, Koe, and Kaya