MRL meeting here in 1.75 hours

Meeting time: monero-project/meta #884

1) Greetings

Hi

<j​effro256:monero.social> Howdy

Hello

hi

2) Updates. What is everyone working on?

<j​effro256:monero.social> Implementing my Jamtis F-R privacy changes

<j​effro256:monero.social> gist.github.com/tevador/50160d160d2…ment_id=4665372#gistcomment-4665372

Me: Did some more simulations about the ring member dependence issue. I think I have a conclusion on it. Calculating numbers for risks with different N for the N block lock on spending outputs. Reviewing preliminary results from compdec on EAE attacks and similar.

<j​effro256:monero.social> How do risks change with different block lock levels?

That's what I was calculating

<j​effro256:monero.social> Oh okay ;)

The answer may surprise you :P

I want to get to that in the discussion part of the meeting

I pivoted from p2p-noise to p2p-ssl, hopefully will have something working by next week. The first version should allow fingerprint "pinning" (server authentication)

its looking to be much easier than noise to get in the existing tcp/server code (since it already supports ssl)

<j​effro256:monero.social> Awesome

"Easier" sounds great, yeah

I made the decision after talking to few other people privately, there wasnt much push for noise and the benefits are small given that I scaled things back from the original plan anyway

yeah the noise code had to buffer messages before the noise handshake completed, or be implemented in the tcp server directly like ssl is

Thanks, vtnerd

3) Discussion

<c​ompdec:matrix.org> I'm a bit late, but here now. I shared a rough draft of some EAE results, and I'll be adding a couple more sections for friday

<j​effro256:monero.social> Honestly yeah SSL E2E encryption is probably better anyways for uniformity with other networks... I'm glad that's being worked on

compdeec: Thanks. I am about halfway through it. Stopped to run some of my own simulations about some issues you raised :)

I wonder a bit that jeffro256 is already implementing his Jamtis changes

Isn't it a bit early for that?

<c​ompdec:matrix.org> Cool. It's going to take a while to parse, there are a lot of ideas in a lot of different directions

jeffro256: Do you want to discuss your Seraphis Find-Receive privacy proposal?

Or is this more in the sense of "rapid prototyping" to see where it really leads?

<j​effro256:monero.social> Yeah so the basic idea behind the Jamtis changes is that ex extra pubkey is added to the address, so that senders can do 2 different DH operations to a given address. The keys for each DH op are used to recompute view tags and nothing else. Only when you combine access to both private keys can you calculate the main sender-receiver secret, decrypt address tags, and recompute one-t<clipped mes

<j​effro256:monero.social> ime addresses. The pros of this scheme are threefold: 1) light wallet servers can't strongly identify incoming enotes to known public addresses, 2) can't strongly identify incoming enotes sent to the same address twice and 3) can generate receive addresses for you AND calculate view tags without learning any additional balance recovery information. The cons are that the address si<clipped mes

<j​effro256:monero.social> ze increase from 196 to 244 characters and light wallet scanning on the client side is slightly slower

<j​effro256:monero.social> Yeah so the basic idea behind the Jamtis changes is that an extra pubkey is added to the address, so that senders can do 2 different DH operations to a given address. The keys for each DH op are used to recompute view tags and nothing else. Only when you combine access to both private keys can you calculate the main sender-receiver secret, decrypt address tags, and recompute one-t<clipped mes

<j​effro256:monero.social> ime addresses. The pros of this scheme are three-fold: 1) light wallet servers can't strongly identify incoming enotes to known public addresses, 2) can't strongly identify incoming enotes sent to the same address twice and 3) can generate receive addresses for you AND calculate view tags without learning any additional balance recovery information. The cons are that the address s<clipped mes

<j​effro256:monero.social> ize increase from 196 to 244 characters and light wallet scanning on the client side is slightly slower

So if you already implement, maybe you will soon be able to quantify that "slightly slower"?

<j​effro256:monero.social> I started implementing it now just to get the ball rolling since it requires a non-trivial amount of effort. I'm received almost all positive responses thus far, but if it's decided to not do it, then I'll just drop the code

<j​effro256:monero.social> Yes, I def interested too see what the IRL performance difference is

In the status quo Seraphis proposal, if the light wallet server doesn't know the address that the receiver gave to the sender, then the server doesn't have the "strongly identify" capability in the first place?

are we assuming full chain membership proofs with this proposal? the light-wallet server can frequently compute the real spend because the client has to ask for dummies in a ring signature

<j​effro256:monero.social> My hypothesis is that I/O dominates the processing time anyways, so my changes won't really affect much, but I could be wrong

<j​effro256:monero.social> If can make an extremely accurate guess about incoming enotes to the same public address without actually knowing the address

<j​effro256:monero.social> *it

That's multiple tx sent to the same address, right? What if just one?

<j​effro256:monero.social> If you successfully recompute view tags, then decrypt an enote get the exact same address tag as another enote, both are almost guarantee to be owned by the user, barring intentional sender shenenigans

<j​effro256:monero.social> If there's just 1 enote sent to a public address, and that address is not known, then the light wallet server gets no extra information

<j​effro256:monero.social> That's a good question. This proposal doesn't touch on sender privacy at all, just receiver

<j​effro256:monero.social> But that dummy-request ring problem can be fixed by changing your telegraphy yeah?

What is telegraphy?

<j​effro256:monero.social> Which information you send/reciver to/from server

<j​effro256:monero.social> And which servers

If the remote node model is used for light wallet servers to request candidate decoys, it should be fine, right? Just get the output age distribution.

no, it will typically leak the real spend

or not wait, it won't nevermind, sorry for the noise

the problem is that the light-wallet-server spec currently does the ring selection for the wallet

Depends on how much the server knows about which outputs the user owns, right?

so currently the light-wallet-server can compute the real spend (since it generated the dummy ring)

no, the spec needs to be updated because currently it does the dummy selection for the client

That will probably change, seems to me, with the typical Seraphis/Jamits light server knowing much less

most likely this will change. the downside is that these clients will receive a large blob of integers to handle

I recall that being one of the reasons why the server does it, the server typically has more ram and processing

Maybe even "light server" or "light wallet server" will have to step back for more apt terms, like "view tag selector" (just brainstorming)

or "view tag checker"

because there is not much more left, for the minimal such server, right?

<j​effro256:monero.social> Luke and I have both talked about, but haven’t gotten around to, caching the RCT enote distribution on the wallet side . It only ever extends, save for reorgs, isn’t that much to store persistently, but it’s a lot to transmit all at once. It’s the perfect candidate for a persistent cache. I think that’s within scope for a light wallet client to do (until FCMPs) w/o hurti<clipped mes

<j​effro256:monero.social> ng performance too much

<j​effro256:monero.social> Would also be used by full wallets

yeah, it doesnt really change so caching would work

About how much data is it?

I hope nobody seriously plans to put substantial new work into wallet2, e.g. to implement such a cache alread today ...

<j​effro256:monero.social> Yes, this will definitely affect sender privacy but thankfully, can be done sort of efficiently by the client side and doesn’t rely on any Jamtis/Seraphis details AFAIK

<j​effro256:monero.social> Uhhh I think like 3 MB?? I used to know off the top of my head

I recall it being 6mb or so, moo would remember

<j​effro256:monero.social> Well the exact same technique could be applied to wallet3 so that effort wouldn’t be lost unless we significantly changed the decoy selection algorithm

And it just scales up with number of blocks, not total tx volume, right?

<j​effro256:monero.social> Yes

You still lose some time with reviews, merge conflicts, etc., if you put something into wallet2 first. That horse should be dead by now, in effect, if you ask me :)

With me as the CEO of Monero we would probably have a hard feature freeze now on wallet2, to move full steam ahead towards Seraphis/Jamtis. (Old boomer grumbling)

I'll save N block lock for next meeting. By then I think I will have a writeup (unless I find additional surprising things that I have to convince myself of.)

Any other discussion?

<j​effro256:monero.social> Guess I’ll just wait then ;)

<j​effro256:monero.social> All hail Monero CEO

:)

Would be much more boring with me as that CEO

Good it won't happen

jeffro256: If you want the main part of the analysis, look at Table 1, Page 10 of Rosenfeld (2014) "Analysis of hashrate-based double spending." moneroresearch.info/index.php?actio…n=resource_RESOURCEVIEW_CORE&id=191

I wondered why some of those attack success probabilities in the table were so high.

<j​effro256:monero.social> Thank you I’ll take a look at that for sure

Do we agree that if the lock on spending outputs is N (i.e. N is 10 now), then an attacker has to re-org N + 1 blocks, since that would include the spent output and the tx with that output in its ring, which has 1 confirmation?

Let's end the meeting here. Thanks everyone.

<j​effro256:monero.social> To be effective, It depends on the policy of the receivers. If a receiver takes 0-conf then you don’t have to reorg anything

<j​effro256:monero.social> But if you do reorg N + 1 blocks, then you’ll start screwing up txs that have dependencies on those transactions

You have to re-org N blocks if the receiver has a 0-conf policy. But, yes. What should be the main assumption?for the writeup? 1 conf or 0 conf?

<j​effro256:monero.social> No you don’t have to reorg anything to perform a double spend attack against a merchant who accepts 0-conf, you just have to change which txs in the current mempool get accepted into the next block

Right, if you control they keys for the original spent output. If it's just a sabotaging attack where you don't have the keys, then that tx can be included in a later block.

Anyway, 1-conf is probably the right case to focus on.

<j​effro256:monero.social> Oh okay I see what attack you’re talking about. A reorg attack where txs are completely invalidated and have to be reconstructed, yeah ?

Yes. There are multiple motivations that an attacker could have. IMHO, the sabotaging attack is what makes Monero unusual. It's a proposed reason for having the lock since other coins don't have a lock. They let the receiver choose their risk level.

<j​effro256:monero.social> Okay sorry I thought you were talking about general double spend attacks

<j​effro256:monero.social> So to answer this, yes I believe

I'm sorry that I wasn't clear :)

<j​effro256:monero.social> If you reorg the top N , then you can delay txs , but you couldn’t invalidate anything

<j​effro256:monero.social> Well you could invalidate what is in the mempool

I wonder what the code would actually do in that scenario.

If nodes would delete txs in the mempool that it had already "validated" based on the old honest chain.

<j​effro256:monero.social> That’s a good question for mooo or sech

When there is a hard fork there is a little message in the log "Validating txs in the tx_pool for v16"

Doesn't matter, I guess since those tx could not be put in later blocks. They would just stay in the tx pool until they were removed normally after a few days.

<j​effro256:monero.social> Yeah at any rate it *shouldn’t* affect your analysis

Which actually would be worse for a typical user since they would see their tx in the mempool, not realizing that they would have to reconstruct it.

<j​effro256:monero.social> Vtnerd might also know

<j​effro256:monero.social> Doesn’t that happen to everyone (even those with txs in “confirmed” blocks) affected regardless? 1) tx leaves wallet 2) tx is dropped for validation purposes

Rephrase "tx is dropped for validation purposes" please

<j​effro256:monero.social> Nvm .. it didn’t really make sense

What question exactly ?

:]

<j​effro256:monero.social> moneromoooo: on a reorg, are all txs in the mempool re-evaluated ?

moneromooo: A user constructs and broadcasts a tx with a ring member from 10 blocks ago. Someone with a lot of haspower then broadcasts an alternative chain that re-orgs 10 blocks deep. The user's tx cannot be included in this attacking chain that is now the consensus chain.

Is that tx removed from nodes' mempools or not?

It's not removed. If now invalid, it'll stay in the txpool but not be mined.

It might become valid again if the chain switches back.

Thanks :)

<j​effro256:monero.social> I didn’t even think about that possibility. Very interesting thanks

I think an assumption of these double spend attack success probabilities is that "honest" miners do not attempt to mount a counterattack.

i.e. honest miners start building on the longer, attacking chain once it has been broadcast.

instead of truing to build on the old honest chain. I think that's what makes some of the attack success probabilities high. The attacking chain only needs to outrun the honest chain once, then be broadcast.

If the attacker fails to succeed in N (or N+1) blocks, it can keep attacking, raising the probability that it creates a longer chain later by chance.

Honest miners use unmodified monerod, and by default it will just switch to the longer chain. They'll start mining on the longer chain

sech1 Yeah. I was trying to understand all the advantages the attacker has. IIn a usual double spend attack scenario, the attacker can also choose the time of the attack. They can wait until they actually mine the first block of their attacking chain, which gives them a +1 advantage over the honest miners who have not yet produced that next honest block.

Honest miners who paid themselves in the coinbases of the part of the honest chain that was re-orged would have an economic incentive to mount the "counterattack".

But if it's not the default configuration to do it, they wouldn't do it in a real scenario