Meeting 2.5hr

meeting time monero-project/meta #697

1. greetings

hello

hi

howdy

hola

Bonjour

Hi

hi

2. updates, what is everyone working on?

me: more seraphis stuff (I implemented binned reference sets, next up are the 16/2 jamtis address index discussion/possible implementation, then discretized fees)

a) I have made some progress with decoy sel. algo analysis and summarized both the results and the strategy here:

In short: We'll be performing statistical analysis with Rucknium and jberman and I'm preparing it from the technical level.

b) I had a great chat with ArticMine and endor00 about the next (parallel) task of simulating the behavior of the system (fee and block size) in case of a sudden increase of transactions. I know how it all should work now.

Working on estimating the effect (if any) of minexmr's increase in its pool fee from 1.0% to 1.1% on April 1st. The most obvious statistical model, to me, is a test for a structural break in the time series. Input about that is welcome. I've started to collect the data using neptune's SQL tables.

I think this research question maybe a bit touchy. I am going to calculate the statistical power of the test. If the test cannot detect a fall (or rise) in minexmr's share of blocks of less than 1-2%, then I will probably just share the results here rather than on Reddit since I think it is hard for laypeople to distinguish between the two statements "There was no effect" and "The data and circumstances were such that no effect

could be detected".

added support for view tags to the block explorer + monero-lws, and helped out with monero-python (both on adding support for view tags [ty plowsof ] and on helping patch a vulnerability reported by kayabaNerve that allows a sender to get a recipient to blindly trust an arbitrary amount in a tx)

thanks guys

3. discuss larger jamtis address tags (and address indices)

Does anyone have comments/questions about it (other than me)?

Question: What is a MAC?

I came up with an adjusted CBC (chained block cipher) mode for blowfish that seems like it will work for non-block-size-multiple ciphertexts.

Also, is this related to the "probability of a collision" calculations you and I discussed a few months ago?

Rucknium[m]: when encrypting something, you can add a small piece of data at the end. When decrypting, if you re-create that end piece (the MAC), then there is a very high chance that decryption succeeded (i.e. the deciphered text isn't gibberish).

Typically MACs are like 16 bytes. In the case of jamtis address tags, the MAC just acts as a filter when deciphering (very similar to view tags).

Since it acts as a filter, it can be small (1-2 bytes).

If someone has a better name for the address tag MAC, I would be happy to accept it lol

Rucknium[m]: re: probability of a collision, can you remind me what that was about?

jberman[m]: It was only for when it scans it itself, which likely wasn't happening, but definitely a crit patch :)

oh, the seraphis squashed enote hash? this is different

Also, just to ensure my understanding is correct, MAC here is comparable to BTC's 6 character/4 byte Bech32 checksum, right?

kayabaNerve: in practice it's just some zero bits appended to the plaintext, and then you check if those bits are zero after deciphering

I won't advocate for using a BCH code, as they're nifty yet literally no one bothers using them to detect where errors are and you're never supposed to auto correct anyways.

Yeah. Bech32 uses a constant of... 1? And then Bech32m uses a constant which doesn't allow malleability via 0 padding

So where is this being proposed as used?

kayabaNerve: gist.github.com/tevador/50160d160d2…ment_id=4144862#gistcomment-4144862

Afaik MACs are not for error correction, but to just detect decryption errors or tampering. Without a MAC, someone could manipulate the cyphertext and change the result

Thanks

if you scroll up, I made a comment on monday summarizing the situation

@UkoeHB did you get to do more benchmarking/can you comment further on how it would impact scanning time? I'm not exactly clear on it from the comment/explanation. considering the MAC is larger, would we expect the increase in byte size to actually reduce scanning time?

jberman[m]: I will work on that today

increasing the size from 8 -> 18 will increase the blowfish ciphers from 1 to 3, but increasing the mac from 1 -> 2 bytes will reduce the cost of filter-failures by 1/256 (failures require at least one expensive EC op)

Thanks for the details. This all makes sense to me. There's definitely no use case for BCH here (I assumed this was for addresses, not understanding the distinction of addess tags, sorry)

For today, the more important question is the address index size (7 bytes or 16 bytes).

right now we have 8-byte address indices (typically split into 4 byte address index and 4 byte account index)

so increase from 8 to 16? or decrease to 7?

yes

the main goal of 16 bytes is robust random address generation

i would check first if 16 bytes are even practical RAM wise

I like it. It does relate to collisions in that it enables you to randomly generate an address without worrying about a collision. Whereas today you either need to maintain state of provisioned subaddresses, or use integrated addresses. Maintaining state across wallets is not so simple in all circumstances and integrated addresses have a suite of downsides that have been discussed at length

ok, if you want to use it like jberman[m] says it might make sehse

selsta: what do you mean by RAM? I would just use a uchar array (wallets can interpret the index as they want)

16-byte indices is equivalent to baking the integrated address piece into addresses (adding 8 bytes)

UkoeHB: i meant if someone generates all possible addresses, but that might not be necessary if someone wants to to just randomly generate addresses

imo all future wallets should primarily use random address generation (only the 'account'/'grouping' bits would be controlled)

how would restore work in this case?

currently they are generated sequentially and during restore there is a lookahead

selsta: you may want to read up on jamtis gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024

yea, it's better if I stay out of this discussion lol

addresses would have an 'address tag' (ciphered address index), and on-chain outputs would have encrypted address tags

it avoids the need for a lookahead, allowing you to decrypt to know exactly which address was used

i'm not fully up to date on the proposal

during scanning, you decrypt then decipher the address tag to get the index, then try to recreate the spend key

that's a nice improvement compared to the lookahead

the address tag contains a mac so you don't spend a ton of time recreating test address keys

recreating spend keys*

the reason we are discussing a size change is because these address tags are stored on-chain (chain cost)

worth pointing out that 10 bytes per output would probably be more significant if the idea to have all tx's use 16 outputs was implemented: monero-project/research-lab #96

suppose so

to me it seems that encouraging users to use random addresses all the time (as opposed to address re-use) to prevent out-of-band associations is worth it (the blockchain cost), if the alternative is complex enough to lead to wallets not doing it

well the question is if you can still do random addresses with much smaller indices (5 bytes in a 7-byte index that has a 2-byte account index)

and im all for future-proofing when possible

some wallets can't even protect it (e.g. you have a wallet on 1 machine, same seed wallet a different machine, and these 2 wallets don't communicate with each other e.g. you use GUI on desktop and same seed in a mobile wallet)

There doesn’t seem to be any opposition in this meeting (if tevador were here, there might be more pushback). I will do performance tests comparing 7/1 vs 16/2 jamtis address tags. If 16/2 doesn’t have perf issues, then I will implement it fully. Then we can/should revisit this question in the future (or if anyone appears with objections).

We are getting to the end of the meeting. Any last minute questions/comments on any topic?

It's very nice for a point of sale view-only collection wallet to not know anything about which subaddress index the spend key/owner's wallet is on

Dealing with this right now with HotBox :) Can only use integrated addresses for now.

I just wanted to talk about multisig audit shortly.

cryptogrampy[m]: do you think random generation would solve that?

selsta: ok

I don't think we have to audit multisig before the hardfork, but we definitely have to audit it before Haveno launches.

No objection

The problem is that there is no writeup of the cryptography and I don't think UkoeHB is interested in writing it down.

Any ideas what / how we could solve that?

Without writeup the auditors will probably waste a lot of time and maybe misunderstand something.

In other words, UkoeHB needs an intern lol

UkoeHB: i can understand that working on Seraphis is way more exciting lol

It’s also a time commitment

UkoeHB: For the HotShop usecase, I would want to generateRandomSubaddress() (outputs a fairly collision proof subaddress) to use for collecting payment. The payment collection device uses a primary and view key and has no contact with the spend key wallet. The spend key wallet currently has no idea that subaddress at index 100000000 was used at the end of the day, but it sounds like the address tags will help with this?

cryptogrampy[m]: seems like it will help

maybe luigi1111 is bored and wants to do an updated multisig writeup

Could coinstudent2048 help us?

Or would* since nothing is guaranteed

Was gonna tag coinstudent, also dangerousfreedom may be interested

I'm sure we could get funding for whoever wants to do this.

<UkoeHB> "well the question is if you..." <- my math might be off here, but 50% probability of a collision is on the order of low billions of subaddresses generated? Hardening numbers to answer this would be nice, just gotta plug into the birthday problem

UkoeHB: This was somewhat discussed in github issue on integrated address deprecation, but I think the address tags could be the last nail in the coffin needed to get rid of integrated addresses

Launching Haveno without audit could mean it's a matter of time until funds are stolen. At least with audit the chance is reduced.

I think MAGIC Monero Fund could pitch in some money to help the audit as well. The committee would need to approve the funds, of course.

Rucknium[m]: I talked do sgp_ and he also suggested MAGIC, so that is something we can consider once we have a writeup of the cryptography.

I mean, MAGIC could fund the writeup itself, too. However, MAGIC would have to KYC the recipient of the funds.

let's see if coinstudent2048[ or dangerousfreedom are interested first

This sounds good, also because of the KYC requirement. Audits are more official and formal than the usual development.

I mean KYC here won't hurt as much as it would for other efforts.

ok, that's it from my side

Thanks selsta and thanks everyone for attending

now that its after hours... regarding "ermagerd viewkeys", is it possible to make view keys expire?

probably, but it would be pretty difficult/annoying

MAGIC is supposed to fund audits and we've previously confirmed the Monero Fund would fund audits.

Just to chime in a bit late.

gingeropolous: Running the generic cryptography in my head quickly, yet premised on the current system, I believe only via shipping two keys in addresses with a time gate :/

Which I say as I think this is comparable to a similar problem I worked on regarding signing nonces which had that as the result...

Some criticism of Seraphis/JAMTIS view key capabilities:

> So with Seraphis upgrade coming out

I think OP missed the fact that the next hardfork will not include Seraphis

Also a bunch of comments from "concerned citizens" who missed the whole discussion on which viewkey capabilities to implement

seemed like a stretch and highly speculative, that's not even sure if its gon be for next year or even if an other protocol might be chosen instead, like heck, tryptich was still being considered not long ago till limitations were found so it wasnt a possibility no more

the whole post also seems to assume CEX would still be the ones that would lead the market while, haveno (or penumbra) is not even out yet and there is no way of knowing just yet the impact it can have on minimizing the power of those enforced regulations on CEX and how it would affect XMR then

for bitcoin there's the bip 119 controversy that if implemented then guessing it could affect atomic swap with xmr since the btc outputs could directly be blacklisted and allow only whitelisted addresses from CEX from a protocol level

i cant see that happening with just the view keys with seraphis tbh, in a scenario where bip 119 is a thing and DEX is widely adopted on XMR then sure the xmr/btc is kinda fucked but the kyc-free fiat on/off ramp would be the one that matters imo so shouldnt really affect the fungibility by cex enforcing view keys or whatever due to dex being used instead

Yes and I left my reply reddit.com/r/Monero/comments/ubvvql…ce=share&utm_medium=web2x&context=3

Basically, this can already be done. We have key images and already generate proofs when exporting them. Theoretical tyrannical govt is going to theoretical tyranny. It has no impact on the benefit of this functionality

The BIp119 controversy is over its functionality if it was done recursively, not it itself, with the note that funds can never leave the covenant. It'd effectively burn BTC from the supply and force colored coinage.

Yeah, the way that Seraphis view key discussion went makes me wonder who discusses in good faith there, with some gaps in knowledge, and who wants to stir up drama

Also, Seraphis does sep incoming/outgoing view, right?

Someone suggested that and I commented I'm pretty sure it does, as it at least did in the discussions from months ago, yet I'm solely assuming that wasn't dropped for some reason

*or at least have the option of separating them

Looks like it: gist.github.com/tevador/50160d160d2…17024#25-wallet-tiers-for-merchants

Another point that I've noticed in OP's post: they ask "Are view keys really that necessary?" Which suggest to me that they do not know that view keys are a byproduct of the whole stealth address system to hide user wallets on the chain

(Writing that up as right now)

Well, a single key CryptoNote like protocol would probably be possible in theory, no? With reduced flexibility of course, and looking quite differently.

Perhaps - but wouldn't it be pointless? The implication would be that the wallet address would necessarily be able to distinguish incoming transaction, so anyone with your wallet address would be able to scan the chain looking for your transactions. At that point, might as well stick with transparent addresses to simplify things

(right?)

reddit.com/r/Monero/comments/ubvvql…ce=share&utm_medium=web2x&context=3 <- proof he's arguing in bad faith

Er, the wallet address contains a public key, not a private key, so I don't think the address would reveal something :)

Looks like OP has cross-posted this topic in r/xmrtrader now that it has gotten a little traction. But I'm sure that's just a coincidence :)

If the government demands view keys, they demand view keys. If you remove view keys, they demand private keys. If you... they demand access to your laptop. If you.. they... Monero cannot solve every problem. This is already an 'issue' in the current protocol, when it's not even an issue. It cannot be changed without completely rebuilding the entire cryptography of it and the government then just mandates spyware on all computers.

The end.

Hello guys,... (full message at libera.ems.host/_matrix/media/r0/do…b4fad1b17db3d778e4ea91d9cc285e3847f)

<selsta> "let's see if coinstudent2048..." <- It would be nice to further work with cryptography, I believe the tools that I am creating in Python could quickly prototype a multisig scheme or something that you guys are planning to implement. I am not an specialist in cryptography though, I have some knowledge but I am far from being 'reliable', I still have a lot to learn. But it is definetly one of my future goals. I

would be happy to work with coinstudent2048if he wants to do it. I believe I can find some more time to do the required tasks if they are not too hard and it would be good to work with someone as it is an audit task.

dangerousfreedom: so basically the current multisig crypto design is spread over multiple documents and code comments

the goal would be to have a single document that can be audited

and then the code can be audited to see if it matches the design

that's how I imagine it at least

I would definitely be involved in review/editing

We mostly just need someone to do the write-up (the leg work :p)

Ok, I see. So there is something working in C++ already and you would like these functions to be as simple and documented as possible in just one file? Well, if that is so, I believe I could do it. But you can send me and CoinStudent a message with more details

I don't think you'd need to write any code, just describe the algorithms

And explain different parts

Good! Then I believe I can do it. I'm trying to explain things in a nice way but I dont know if I am succeeding. You tell me ( moneroinflation.com/ring_signatures_mlsag ) ;)

dangerousfreedom: this looks good to me :)