16:01:36 MRL meeting in this room in one hour. 17:00:34 Meeting time! https://github.com/monero-project/meta/issues/932 17:00:44 1) Greetings 17:00:50 hi 17:01:01 Hello 17:01:03 hi 17:02:44 2) Updates. What is everyone working on? 17:03:29 me: adding to LWS unit tests in preparation for adding "chain hardening" to LWS 17:03:57 having fun with fail2ban and monerod logs 17:04:10 not sure its worth do chain hardening - there's really no way great to determine if we've been forked away for instance 17:04:26 me: OSPEAD, as normal. Want to remind everyone while the CCS next steps post-theft are being discussed, the MAGIC Monero Fund is accepting proposals as usual: https://monerofund.org/apply 17:04:29 but the unit tests are worth it (the core scanner has yet ot be unit tested) 17:05:04 vtnerd: What is chain hardening? 17:05:47 verifying the hashes and PoW work in LWS itself. LWS currently (like wallet2 in monero) assumes the info from the daemon is valid 17:06:10 you can currently send blocks/txes with no connection to each other (as evident by the tests I just wrote) 17:06:26 you can verify just about everything, but could still be on a forked chain 17:07:00 Thanks. Is this related to the vulnerability reported by tevador this year? And would the proposed changes to RandomX help? 17:07:03 so this would be the usecase of user A connecting to user B's LWS server (so 3rd party LWS)? 17:07:23 the use case would be someone pointing LWS to a daemon they don't control 17:08:10 it may always be a bad idea, so I'm mixed on adding the feature to LWS. Depends on how much it wrecks the codebase to add it 17:08:57 yeah the only "solution" ive thought of is just connecting to multiple servers to get a consensus, sorta like electrum does 17:09:35 3) Discussion. What do we want to discuss? 17:09:38 yes, that should help with verifying the chain tip, etc 17:11:26 hello 17:13:07 hello. re: discussions, are the itinerary topics on the github issue still relevant? or is that just the same its been 17:13:28 Howdy sorry I'm late 17:13:38 because it still has the 10-block lock is an item of discussion 17:13:39 Still relevant, but no activity on them recently. 17:14:40 You can say "We should reduce/increase/eliminate the 10 block lock for X reason." 17:16:31 I have a question that jeffro256 might help with: With a new probability distribution, would it be a problem to revert the behavior of the wallet2 decoy selection algorithm to choose decoys starting from the 10 block lock instead of from chain tip? And eliminate the reallocation to a uniform distribution for the recent spend window? 17:16:53 So, similar to pre-September 2021 17:19:34 jberman: would probably know best since he implemented those changes. 17:20:04 Anything else to discuss? 17:20:12 https://www.getmonero.org/2021/09/20/post-mortem-of-decoy-selection-bugs.html 17:20:29 Heres the relevant blog post 17:22:36 I don't think removing the uniform spend window would be a problem as long as we can empirically verify that the curve by itself does enough to match REAL monero spends in practice, including the 10-block-lock 17:22:46 But in reality that might be hard 17:23:31 IIRC the process was: Moser et al. (2018) estimated the gamma distribution from chain time. The gamma with the estimated parameters had a mode somewhere between 0 and the 10 block lock. I think it looked like that since they estimated it on data when the 10 block lock was not required by consensus. So a few wallets produced transactions with ring members before the 10 block lock. 17:23:33 Think about how many users/services sit there and wait exactly the shortest amount of time available before they can spend 17:24:06 why not guarantee an upper and lower bound for decoy selection, that rolls window with chain progression? 17:24:08 They used BTC as a model 17:24:48 and compared against monero spends that could be determined 17:25:09 IIRC (and I'm pretty sure), they did not use BTC for the final parameters that Monero uses. They determined the real spend of many XMR transactions (about 60-80%?) and estimated from the real XMR data. 17:25:15 I think there has always been a 10 block limit 17:25:55 w​ho-biz: Could you explain your idea more? 17:26:05 Who-biz: would you be able to explain more , I'm not quite sure I understand 17:26:10 Jinx 17:27:15 I mean, we already have the 10 block limit. Why not make the lower bound of selection more uniform too? unless I'm missing something here, it would seem to level the playing field a bit for all auto-decoy-selection users 17:27:37 vtnerd: it was wallet enforced. became consensus enforced in 2019 ( I think) https://github.com/monero-project/monero/commit/a444f06e53b218cc8bd091e5283828beb3e7d9af 17:28:26 oh wait maybe i misread what u were sayin 17:28:48 BTC doesn't make sense as the data used to produce the gamma distribution parameters of Moser et al. (2018) since BTC usually (always?) has a monotonically decreasing empirical probability distribution, at least in the area close to chain tip. The gamma parameters that Moser et al. estimated produces a probability distribution function that rises first and then decreases (not monotonic). 17:28:52 Rucknium one thing that might be worth investigating is whether the recent spend window needs to be so wide 17:29:42 Because the recent spend window captures all spends from 10 blocks or less by is spread out 15 blocks wide which might not be realistic 17:29:45 My plan is to eliminate the concept of recent spend window. 17:30:28 But if there is a really good reason to keep it, then we could. 17:30:44 Like if I'm sitting there waiting for the 10 block lock to go away it doesn't make sense that I'd somehow skip 30 minutes after it unlocked 17:31:08 I somehow didn't realize moo added this consensus change later. regardless, the early data would then be skewed because wallet2 was following the rule 17:31:33 Having the pre-10 block part of the distribution re-allocated as a uniform distribution is a good first approximation, but it creates an unnatural discontinuity. A drop off where the uniform distribution ends. 17:32:59 adding to consensus was a good idea. pleased to see this also. I recall 2018 this could be easily worked around by simply changing a constant 17:33:00 Look at page 3: https://www.overleaf.com/read/ndbtkwrbrdjq 17:33:49 Who-biz what do you mean by "uniform" and " lower bound" and "autos decoys selection" here? 17:34:25 At about output index 1,000 there is a drop in the probability. (It's different when you are at different block heights.) 17:35:17 Oh I agree that the recent spend window could be made much better and smooth in with the gamma curve 17:36:27 jeffro256: "uniformity" I don't mean distribution. I mean that the decoys should be selected from the same window of outputs (timewise) for all users, and reducing this variation would probably help strengthen privacy 17:36:54 "lower bound": I mean introducing a "select outputs more recent than x utxos ago" or "x blocks ago" 17:37:17 However i don't think we should remove all conditional code that handles decoy selection during the 10 block locked window since that rule itself will create weird discrete artifacts that we should anticipate 17:37:21 "auto decoy selection": not manually selecting your ring members, and not blacklisting certain outputs. default wallet settings 17:37:48 w​ho-biz: Do you mean that a specific decoy selection algorithm should be required as a consensus or tx relay rule instead of wallet software choosing it? 17:38:02 Correct 17:38:39 Or at least an enforcement of valid bounds for selection of decoys, if you still want to allow some implementation-specific legroom 17:39:06 I think it's a good idea. There is an MRL GitHub issue about it: https://github.com/monero-project/research-lab/issues/87 17:39:18 nice, will read 17:41:31 oh, good :) glad this has been discussed. worth pursuing imo. 17:41:34 maybe off-topic: i've been thinking about air-gapped data transmission solutions for a while and due to the CCS incident i've been working on stuff again 17:41:56 specifically data over sound - mapping audio frequencies to bytes such that devices with speaker/mic can transmit data 17:42:09 hinto: Great to hear :) 17:42:29 signed pgp messages, or monero tx's could be signed like this - in around 2min~ from rough calculations 17:42:55 there's already a c++ impl of this including some reed-solomon error correction https://github.com/ggerganov/ggwave 17:43:02 almost like a TCP over sound 17:43:22 Doesn't this just turn it back into a hot wallet with an unconventional "wire"? 17:43:36 i'm not sure if i should pursue this though, the target is extremely niche 17:44:24 The threat model is the same as Bluetooth or WiFi yeah? 17:44:44 jeffro256: the flow would be: hot wallet -> plays raw_unsigned_tx over audio -> cold_wallet parses audio data into tx, signs it -> cold_wallet play signed_tx -> hot wallet broadcasts to network 17:44:55 the thread model is basically nothing, since the spend key would never leave the cold machine 17:45:18 it would be physical security at that point 17:45:36 hinto: any idea as to range of sound->data reliability? 17:46:21 Why not use an Ethernet cable to talk between machines ? 17:46:27 the c++ impl has 8-16 bytes per second with error correction 17:46:30 if it is less distance than wifi/bluetooth... slightly different but in concept jeffro256 is making sense 17:46:32 which would take around 2min for a 40kb unsigned monero tx 17:46:33 who-biz: why would sound be better than usb? in either case there is some risk of bug 17:47:17 er, actually more than that, my impl seems to be around 20-30 bytes per sec 17:47:19 or hinto: sorry wrong person 17:47:49 there's been concerns with any physical connection, e.g usb/sd card/wire 17:47:55 qr codes are also viable but annoying to use practically 17:48:19 Why is sound different ? 17:48:33 yes, but the threat model is identical: the reader on the airgapped machine has a vulnerability that can be exploited 17:49:02 and Im not certain that an audio algorithm would be simpler than a usb implementation (although perhaps not) 17:49:24 qr codes might an improvement, but its splitting hairs there too 17:49:33 it would boil down to the safety of the audio input -> byte software 17:49:37 the electrical signal thing is likely just a red herring 17:50:01 yes, which is the same for usb? you have the same exact threat 17:50:14 usb in general is spooky since it can it is a just a bus that can do anything 17:51:00 That's the exact same threat model as USB/Ethernet/WiFi/Bluetooth but those mediums tend to be a little bit more well studied 17:51:55 yeah Im not convinced that the audio technique is trivial in terms of implementation, but perhaps less than a full usb stack 17:51:59 Its a bus that can do anything only if the code interfacing with it let's it do anything 17:52:14 you can still compile the linux kernel without many usb features, reducing the attack surface greatly 17:52:28 If you have a hardened USB controller then it won't let the USB do anything 17:52:38 jeffro256: the usage would be on a cold device 17:53:51 I think he understands the situation, just pointing out the same thing I am. That if you have two-way communication then there's always a chance of lost funds 17:54:07 If you have a constantly listening mic and speaker ready to receive and transmit instructions and byte data then your wallet is no longer "cold" 17:54:48 yeah the proble is complex reading/writing and two-way comms 17:54:54 *problem 17:55:40 There would be a physical confirmation by the user on the airgapped device, right? 17:55:44 to be fair, the audio -> byte code would be maybe a few hundred lines 17:56:09 Rucknium: of course, not always listening - you would init the back-and-forth 17:56:40 i would be shocked if somewhere were to create an exploit over this that somehow made your cold device spill secrets 17:56:46 someone* 17:57:39 few hundred lines seems optimistic, you'd probably need checksums and some other stuff too 17:58:43 hinto: I assume you are aware of the animated QR code projects: MoneroSIgner, Anonero, Feather. 17:59:28 yes - i pushed for monerosigner actually 17:59:36 trying to make qr codes work is very hard 17:59:44 I guess, and in both cases you still are probably interacting with complex audio/video drivers, no? 18:00:24 it just feels better because theres no physical "lines" connecting things 18:00:40 yes, i guess so 18:01:04 I support these projects if people like them, Im just not certain I would bother using them 18:01:07 And if you want to make it portable you have to rely on your distros (or homemade) method of distributing firmware 18:02:25 jeffro256: i'm not sure what this means - the native audio stack would be used 18:05:32 I guess because you seem like you want to reduce stack complexity, which is always good, but this might actually increase it: its USB stack vs mic stack + speaker stack + digital transmission layer on top of analog mediums 18:06:27 How easy is it for malware to hitch hike on a USB and activate itself on another device when plugged in? 18:06:52 Dont get me wrong, the idea would be intriguing. It be fun to bring back dial up modem noises for monero wallets :) 18:07:13 lol that's the first thing i thought of too 18:07:58 again i'm not advocating for it - just have been messing around with this as an "alternative" 18:08:57 Rucknium: surprisingly most cases of usb "attacks" are `.inf` script files that windows auto-runs by default on plug-in 18:09:06 i think ubuntu has this enabled by default as well 18:09:36 We can end the meeting here. Feel free to continue discussing :) 18:10:05 There's some HID abuse that you can do with USBs: https://shop.hak5.org/products/usb-rubber-ducky 18:11:23 crafted usbs fall under compromised physical security - which at point you're always screwed 18:11:30 Ubuntu will always ask you before it runs 18:12:27 Whichever user is currently logged in , I believe it runs as that user 18:13:50 So we're sure, Moser et al. (2018) says, "For Monero, we split the data by 0-mixin transaction inputs as well as the 1+ mixin inputs for which we can deduce the real input... 18:14:00 "Based on these observations, we set about fitting a parametric model to the combined Monero data. We heuristically determined that the spend time distributions, plotted on a log scale, closely match a gamma distribution. We used R’s `fitdistr` function to fit a gamma distribution to the combined Monero data from deducible transaction inputs (in log seconds). The resulting best- fit distribution has shape parameter 19.28, and rate parameter 1.61." 18:16:08 `fitdistr` performs maximum likelihood estimation of the distribution parameters. 18:18:07 Moser et al. (2018) do compare the Monero spent output age distribution with BTC's. In Figure 11. 18:18:57 "While the Bitcoin spend-time distribution appears to have a somewhat similar shape, the distributions are quite different (i.e., the Kolmogorov-Smirnov distance is approximately 0.3)." 18:19:40 Just the 10 block lock on wallet2 txs could create that KS distance IMHO.