<r​ucknium:monero.social> MRL meeting in this room in one hour.

<r​ucknium:monero.social> Meeting time! monero-project/meta #932

<r​ucknium:monero.social> 1) Greetings

hi

Hello

<g​ingeropolous:monero.social> hi

<r​ucknium:monero.social> 2) Updates. What is everyone working on?

me: adding to LWS unit tests in preparation for adding "chain hardening" to LWS

<g​ingeropolous:monero.social> having fun with fail2ban and monerod logs

not sure its worth do chain hardening - there's really no way great to determine if we've been forked away for instance

<r​ucknium:monero.social> 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: monerofund.org/apply

but the unit tests are worth it (the core scanner has yet ot be unit tested)

<r​ucknium:monero.social> vtnerd: What is chain hardening?

verifying the hashes and PoW work in LWS itself. LWS currently (like wallet2 in monero) assumes the info from the daemon is valid

you can currently send blocks/txes with no connection to each other (as evident by the tests I just wrote)

you can verify just about everything, but could still be on a forked chain

<r​ucknium:monero.social> Thanks. Is this related to the vulnerability reported by tevador this year? And would the proposed changes to RandomX help?

<g​ingeropolous:monero.social> so this would be the usecase of user A connecting to user B's LWS server (so 3rd party LWS)?

the use case would be someone pointing LWS to a daemon they don't control

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

<g​ingeropolous:monero.social> yeah the only "solution" ive thought of is just connecting to multiple servers to get a consensus, sorta like electrum does

<r​ucknium:monero.social> 3) Discussion. What do we want to discuss?

yes, that should help with verifying the chain tip, etc

<h​into.janaiyo:matrix.org> hello

<g​ingeropolous:monero.social> hello. re: discussions, are the itinerary topics on the github issue still relevant? or is that just the same its been

<j​effro256:monero.social> Howdy sorry I'm late

<g​ingeropolous:monero.social> because it still has the 10-block lock is an item of discussion

<r​ucknium:monero.social> Still relevant, but no activity on them recently.

<r​ucknium:monero.social> You can say "We should reduce/increase/eliminate the 10 block lock for X reason."

<r​ucknium:monero.social> 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?

<r​ucknium:monero.social> So, similar to pre-September 2021

<j​effro256:monero.social> jberman: would probably know best since he implemented those changes.

<r​ucknium:monero.social> Anything else to discuss?

<j​effro256:monero.social> getmonero.org/2021/09/20/post-mortem-of-decoy-selection-bugs.html

<j​effro256:monero.social> Heres the relevant blog post

<j​effro256:monero.social> 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

<j​effro256:monero.social> But in reality that might be hard

<r​ucknium:monero.social> 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.

<j​effro256:monero.social> Think about how many users/services sit there and wait exactly the shortest amount of time available before they can spend

why not guarantee an upper and lower bound for decoy selection, that rolls window with chain progression?

<v​tnerd:monero.social> They used BTC as a model

and compared against monero spends that could be determined

<r​ucknium:monero.social> 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.

I think there has always been a 10 block limit

<r​ucknium:monero.social> w​ho-biz: Could you explain your idea more?

<j​effro256:monero.social> Who-biz: would you be able to explain more , I'm not quite sure I understand

<j​effro256:monero.social> Jinx

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

<g​ingeropolous:monero.social> vtnerd: it was wallet enforced. became consensus enforced in 2019 ( I think) monero-project/monero a444f06

<g​ingeropolous:monero.social> oh wait maybe i misread what u were sayin

<r​ucknium:monero.social> 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).

<j​effro256:monero.social> Rucknium one thing that might be worth investigating is whether the recent spend window needs to be so wide

<j​effro256:monero.social> 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

<r​ucknium:monero.social> My plan is to eliminate the concept of recent spend window.

<r​ucknium:monero.social> But if there is a really good reason to keep it, then we could.

<j​effro256:monero.social> 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

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

<r​ucknium:monero.social> 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.

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

<r​ucknium:monero.social> Look at page 3: overleaf.com/read/ndbtkwrbrdjq

<j​effro256:monero.social> Who-biz what do you mean by "uniform" and " lower bound" and "autos decoys selection" here?

<r​ucknium:monero.social> At about output index 1,000 there is a drop in the probability. (It's different when you are at different block heights.)

<j​effro256:monero.social> Oh I agree that the recent spend window could be made much better and smooth in with the gamma curve

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

"lower bound": I mean introducing a "select outputs more recent than x utxos ago" or "x blocks ago"

<j​effro256:monero.social> 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

"auto decoy selection": not manually selecting your ring members, and not blacklisting certain outputs. default wallet settings

<r​ucknium:monero.social> 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?

Correct

Or at least an enforcement of valid bounds for selection of decoys, if you still want to allow some implementation-specific legroom

<r​ucknium:monero.social> I think it's a good idea. There is an MRL GitHub issue about it: monero-project/research-lab #87

nice, will read

oh, good :) glad this has been discussed. worth pursuing imo.

<h​into.janaiyo:matrix.org> 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

<h​into.janaiyo:matrix.org> specifically data over sound - mapping audio frequencies to bytes such that devices with speaker/mic can transmit data

<r​ucknium:monero.social> hinto: Great to hear :)

<h​into.janaiyo:matrix.org> signed pgp messages, or monero tx's could be signed like this - in around 2min~ from rough calculations

<h​into.janaiyo:matrix.org> there's already a c++ impl of this including some reed-solomon error correction github.com/ggerganov/ggwave

<h​into.janaiyo:matrix.org> almost like a TCP over sound

<j​effro256:monero.social> Doesn't this just turn it back into a hot wallet with an unconventional "wire"?

<h​into.janaiyo:matrix.org> i'm not sure if i should pursue this though, the target is extremely niche

<j​effro256:monero.social> The threat model is the same as Bluetooth or WiFi yeah?

<h​into.janaiyo:matrix.org> 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

<h​into.janaiyo:matrix.org> the thread model is basically nothing, since the spend key would never leave the cold machine

<h​into.janaiyo:matrix.org> it would be physical security at that point

hinto: any idea as to range of sound->data reliability?

<j​effro256:monero.social> Why not use an Ethernet cable to talk between machines ?

<h​into.janaiyo:matrix.org> the c++ impl has 8-16 bytes per second with error correction

if it is less distance than wifi/bluetooth... slightly different but in concept jeffro256 is making sense

<h​into.janaiyo:matrix.org> which would take around 2min for a 40kb unsigned monero tx

who-biz: why would sound be better than usb? in either case there is some risk of bug

<h​into.janaiyo:matrix.org> er, actually more than that, my impl seems to be around 20-30 bytes per sec

or hinto: sorry wrong person

<h​into.janaiyo:matrix.org> there's been concerns with any physical connection, e.g usb/sd card/wire

<h​into.janaiyo:matrix.org> qr codes are also viable but annoying to use practically

<j​effro256:monero.social> Why is sound different ?

yes, but the threat model is identical: the reader on the airgapped machine has a vulnerability that can be exploited

and Im not certain that an audio algorithm would be simpler than a usb implementation (although perhaps not)

qr codes might an improvement, but its splitting hairs there too

<h​into.janaiyo:matrix.org> it would boil down to the safety of the audio input -> byte software

the electrical signal thing is likely just a red herring

yes, which is the same for usb? you have the same exact threat

<h​into.janaiyo:matrix.org> usb in general is spooky since it can it is a just a bus that can do anything

<j​effro256:monero.social> That's the exact same threat model as USB/Ethernet/WiFi/Bluetooth but those mediums tend to be a little bit more well studied

yeah Im not convinced that the audio technique is trivial in terms of implementation, but perhaps less than a full usb stack

<j​effro256:monero.social> Its a bus that can do anything only if the code interfacing with it let's it do anything

you can still compile the linux kernel without many usb features, reducing the attack surface greatly

<j​effro256:monero.social> If you have a hardened USB controller then it won't let the USB do anything

<h​into.janaiyo:matrix.org> jeffro256: the usage would be on a cold device

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

<j​effro256:monero.social> 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"

yeah the proble is complex reading/writing and two-way comms

*problem

<r​ucknium:monero.social> There would be a physical confirmation by the user on the airgapped device, right?

<h​into.janaiyo:matrix.org> to be fair, the audio -> byte code would be maybe a few hundred lines

<h​into.janaiyo:matrix.org> Rucknium: of course, not always listening - you would init the back-and-forth

<h​into.janaiyo:matrix.org> i would be shocked if somewhere were to create an exploit over this that somehow made your cold device spill secrets

<h​into.janaiyo:matrix.org> someone*

few hundred lines seems optimistic, you'd probably need checksums and some other stuff too

<r​ucknium:monero.social> hinto: I assume you are aware of the animated QR code projects: MoneroSIgner, Anonero, Feather.

<h​into.janaiyo:matrix.org> yes - i pushed for monerosigner actually

<h​into.janaiyo:matrix.org> trying to make qr codes work is very hard

I guess, and in both cases you still are probably interacting with complex audio/video drivers, no?

it just feels better because theres no physical "lines" connecting things

<h​into.janaiyo:matrix.org> yes, i guess so

I support these projects if people like them, Im just not certain I would bother using them

<j​effro256:monero.social> And if you want to make it portable you have to rely on your distros (or homemade) method of distributing firmware

<h​into.janaiyo:matrix.org> jeffro256: i'm not sure what this means - the native audio stack would be used

<j​effro256:monero.social> 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

<r​ucknium:monero.social> How easy is it for malware to hitch hike on a USB and activate itself on another device when plugged in?

<j​effro256:monero.social> Dont get me wrong, the idea would be intriguing. It be fun to bring back dial up modem noises for monero wallets :)

<h​into.janaiyo:matrix.org> lol that's the first thing i thought of too

<h​into.janaiyo:matrix.org> again i'm not advocating for it - just have been messing around with this as an "alternative"

<h​into.janaiyo:matrix.org> Rucknium: surprisingly most cases of usb "attacks" are `.inf` script files that windows auto-runs by default on plug-in

<h​into.janaiyo:matrix.org> i think ubuntu has this enabled by default as well

<r​ucknium:monero.social> We can end the meeting here. Feel free to continue discussing :)

<j​effro256:monero.social> There's some HID abuse that you can do with USBs: shop.hak5.org/products/usb-rubber-ducky

<h​into.janaiyo:matrix.org> crafted usbs fall under compromised physical security - which at point you're always screwed

<j​effro256:monero.social> Ubuntu will always ask you before it runs

<j​effro256:monero.social> Whichever user is currently logged in , I believe it runs as that user

<r​ucknium:monero.social> 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...

<r​ucknium:monero.social> "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-<clipped message

<r​ucknium:monero.social> fit distribution has shape parameter 19.28, and rate parameter 1.61."

<r​ucknium:monero.social> `fitdistr` performs maximum likelihood estimation of the distribution parameters.

<r​ucknium:monero.social> Moser et al. (2018) do compare the Monero spent output age distribution with BTC's. In Figure 11.

<r​ucknium:monero.social> "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)."

<r​ucknium:monero.social> Just the 10 block lock on wallet2 txs could create that KS distance IMHO.