15:17:06 <Rucknium> MRL meeting here in 1.75 hours
17:00:54 <Rucknium> Meeting time: https://github.com/monero-project/meta/issues/884
17:01:02 <Rucknium> 1) Greetings
17:01:04 <Rucknium> Hi
17:01:07 <m-relay_> <j​effro256:monero.social> Howdy
17:01:12 <rbrunner> Hello
17:03:01 <vtnerd> hi
17:03:56 <Rucknium> 2) Updates. What is everyone working on?
17:04:53 <m-relay_> <j​effro256:monero.social> Implementing my Jamtis F-R privacy changes
17:05:26 <m-relay_> <j​effro256:monero.social> https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024?permalink_comment_id=4665372#gistcomment-4665372
17:06:04 <Rucknium> 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.
17:06:46 <m-relay_> <j​effro256:monero.social> How do risks change with different block lock levels?
17:07:05 <Rucknium> That's what I was calculating
17:07:17 <m-relay_> <j​effro256:monero.social> Oh okay ;)
17:07:19 <Rucknium> The answer may surprise you :P
17:07:43 <Rucknium> I want to get to that in the discussion part of the meeting
17:08:36 <vtnerd> 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)
17:09:07 <vtnerd> its looking to be much easier than noise to get in the existing tcp/server code (since it already supports ssl)
17:09:28 <m-relay_> <j​effro256:monero.social> Awesome
17:09:41 <rbrunner> "Easier" sounds great, yeah
17:09:41 <vtnerd> 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
17:10:29 <vtnerd> yeah the noise code had to buffer messages before the noise handshake completed, or be implemented in the tcp server directly like ssl is
17:11:39 <Rucknium> Thanks, vtnerd
17:11:44 <Rucknium> 3) Discussion
17:11:57 <m-relay_> <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
17:13:09 <m-relay_> <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
17:13:47 <Rucknium> compdeec: Thanks. I am about halfway through it. Stopped to run some of my own simulations about some issues you raised :)
17:15:04 <rbrunner> I wonder a bit that jeffro256 is already implementing his Jamtis changes
17:15:10 <rbrunner> Isn't it a bit early for that?
17:15:23 <m-relay_> <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
17:15:27 <Rucknium> jeffro256: Do you want to discuss your Seraphis Find-Receive privacy proposal?
17:16:07 <rbrunner> Or is this more in the sense of "rapid prototyping" to see where it really leads?
17:20:22 <m-relay_> <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
17:20:23 <m-relay_> <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
17:20:23 <m-relay_> <j​effro256:monero.social> ze increase from 196 to 244 characters and light wallet scanning on the client side is slightly slower
17:20:56 <m-relay_> <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
17:20:56 <m-relay_> <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
17:20:57 <m-relay_> <j​effro256:monero.social> ize increase from 196 to 244 characters and light wallet scanning on the client side is slightly slower
17:22:42 <rbrunner> So if you already implement, maybe you will soon be able to quantify that "slightly slower"?
17:22:48 <m-relay_> <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
17:23:22 <m-relay_> <j​effro256:monero.social> Yes, I def interested too see what the IRL performance difference is
17:23:37 <Rucknium> 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?
17:23:42 <vtnerd> 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
17:24:12 <m-relay_> <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
17:25:38 <m-relay_> <j​effro256:monero.social> If can make an extremely accurate guess about incoming enotes to the same public address without actually knowing the address
17:25:42 <m-relay_> <j​effro256:monero.social> *it
17:26:24 <Rucknium> That's multiple tx sent to the same address, right? What if just one?
17:27:04 <m-relay_> <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
17:27:57 <m-relay_> <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
17:28:48 <m-relay_> <j​effro256:monero.social> That's a good question. This proposal doesn't touch on sender privacy at all, just receiver
17:30:59 <m-relay_> <j​effro256:monero.social> But that dummy-request ring problem can be fixed by changing your telegraphy yeah?
17:31:29 <Rucknium> What is telegraphy?
17:32:23 <m-relay_> <j​effro256:monero.social> Which information you send/reciver to/from server
17:32:39 <m-relay_> <j​effro256:monero.social> And which servers
17:33:35 <Rucknium> 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.
17:36:30 <vtnerd> no, it will typically leak the real spend
17:36:57 <vtnerd> or not wait, it won't nevermind, sorry for the noise
17:37:21 <vtnerd> the problem is that the light-wallet-server spec currently does the ring selection for the wallet
17:37:33 <Rucknium> Depends on how much the server knows about which outputs the user owns, right?
17:37:46 <vtnerd> so currently the light-wallet-server can compute the real spend (since it generated the dummy ring)
17:38:05 <vtnerd> no, the spec needs to be updated because currently it does the dummy selection for the client
17:38:16 <rbrunner> That will probably change, seems to me, with the typical Seraphis/Jamits light server knowing much less
17:39:15 <vtnerd> most likely this will change. the downside is that these clients will receive a large blob of integers to handle
17:39:30 <vtnerd> I recall that being one of the reasons why the server does it, the server typically has more ram and processing
17:39:39 <rbrunner> Maybe even "light server" or "light wallet server" will have to step back for more apt terms, like "view tag selector" (just brainstorming)
17:39:52 <rbrunner> or "view tag checker"
17:40:07 <rbrunner> because there is not much more left, for the minimal such server, right?
17:42:51 <m-relay_> <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
17:42:51 <m-relay_> <j​effro256:monero.social> ng performance too much
17:43:30 <m-relay_> <j​effro256:monero.social> Would also be used by full wallets
17:43:50 <vtnerd> yeah, it doesnt really change so caching would work
17:44:19 <Rucknium> About how much data is it?
17:44:58 <rbrunner> I hope nobody seriously plans to put substantial new work into wallet2, e.g. to implement such a cache alread today ...
17:45:17 <m-relay_> <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
17:45:27 <m-relay_> <j​effro256:monero.social> Uhhh I think like 3 MB?? I used to know off the top of my head
17:45:46 <vtnerd> I recall it being 6mb or so, moo would remember
17:46:22 <m-relay_> <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
17:46:39 <Rucknium> And it just scales up with number of blocks, not total tx volume, right?
17:46:53 <m-relay_> <j​effro256:monero.social> Yes
17:48:45 <rbrunner> 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 :)
17:50:40 <rbrunner> 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)
17:53:12 <Rucknium> 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.)
17:53:19 <Rucknium> Any other discussion?
17:55:27 <m-relay_> <j​effro256:monero.social> Guess I’ll just wait then ;)
17:56:28 <m-relay_> <j​effro256:monero.social> All hail Monero CEO
17:56:34 <rbrunner> :)
17:56:46 <rbrunner> Would be much more boring with me as that CEO
17:57:07 <rbrunner> Good it won't happen
17:57:53 <Rucknium> 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." https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=191
17:58:40 <Rucknium> I wondered why some of those attack success probabilities in the table were so high.
17:58:59 <m-relay_> <j​effro256:monero.social> Thank you I’ll take a look at that for sure
18:00:58 <Rucknium> 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?
18:01:54 <Rucknium> Let's end the meeting here. Thanks everyone.
18:03:07 <m-relay_> <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
18:04:09 <m-relay_> <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
18:04:33 <Rucknium> 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?
18:06:53 <m-relay_> <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
18:08:29 <Rucknium> 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.
18:09:42 <Rucknium> Anyway, 1-conf is probably the right case to focus on.
18:11:13 <m-relay_> <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 ?
18:13:40 <Rucknium> 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.
18:15:00 <m-relay_> <j​effro256:monero.social> Okay sorry I thought you were talking about general double spend attacks
18:15:21 <m-relay_> <j​effro256:monero.social> So to answer this, yes I believe
18:15:25 <Rucknium> I'm sorry that I wasn't clear :)
18:17:10 <m-relay_> <j​effro256:monero.social> If you reorg the top N , then you can delay txs , but you couldn’t  invalidate anything
18:17:16 <m-relay_> <j​effro256:monero.social> Well you could invalidate what is in the mempool
18:18:50 <Rucknium> I wonder what the code would actually do in that scenario.
18:19:44 <Rucknium> If nodes would delete txs in the mempool that it had already "validated" based on the old honest chain.
18:20:18 <m-relay_> <j​effro256:monero.social> That’s a good question for mooo or sech
18:21:39 <Rucknium> When there is a hard fork there is a little message in the log "Validating txs in the tx_pool for v16"
18:23:30 <Rucknium> 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.
18:24:15 <m-relay_> <j​effro256:monero.social> Yeah at any rate it *shouldn’t* affect your analysis
18:24:22 <Rucknium> 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.
18:25:57 <m-relay_> <j​effro256:monero.social> Vtnerd might also know
18:27:27 <m-relay_> <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
18:28:26 <Rucknium> Rephrase "tx is dropped for validation purposes" please
18:31:06 <m-relay_> <j​effro256:monero.social> Nvm  .. it didn’t really make sense
18:31:18 <moneromooo> What question exactly ?
18:32:45 <slave_blocker> https://github.com/slave-blocker/rant/blob/main/konferenko.pdf
18:32:53 <slave_blocker> :]
18:33:29 <m-relay_> <j​effro256:monero.social> moneromoooo: on a reorg, are all txs in the mempool re-evaluated ?
18:33:59 <Rucknium> 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.
18:34:14 <Rucknium> Is that tx removed from nodes' mempools or not?
18:34:52 <moneromooo> It's not removed. If now invalid, it'll stay in the txpool but not be mined.
18:35:07 <moneromooo> It might become valid again if the chain switches back.
18:35:20 <Rucknium> Thanks :)
18:39:19 <m-relay_> <j​effro256:monero.social> I didn’t even think about that possibility. Very interesting thanks
18:40:47 <Rucknium> I think an assumption of these double spend attack success probabilities is that "honest" miners do not attempt to mount a counterattack.
18:41:22 <Rucknium> i.e. honest miners start building on the longer, attacking chain once it has been broadcast.
18:42:20 <Rucknium> 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.
18:43:45 <Rucknium> 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.
18:45:50 <sech1> Honest miners use unmodified monerod, and by default it will just switch to the longer chain. They'll start mining on the longer chain
18:48:20 <Rucknium> 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.
19:00:24 <Rucknium> 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".
19:01:05 <Rucknium> But if it's not the default configuration to do it, they wouldn't do it in a real scenario