meeting 2hr monero-project/meta #646

Today I cannot make the meeting, so here is a summary: I've phased out merchant wallets in favor of a unified key hierarchy. This is better for UX (users won't have to decide which type of wallet they need) and also for privacy (all wallets have unlinkable addresses by default).

There are now 7 different wallet tiers: gist.github.com/tevador/50160d160d2…e02eb3d17024#46-wallet-access-tiers

thanks tevador :) it's looking good, I just left some comments

I've also slightly changed the key derivation function by padding the secret key to the hash block length. This should be more secure. A new recoverable signature scheme for addresses is documented in chapter 3.4.

I'm now working on a different address encoding scheme based on some feedback. The address prefix will be more human-readable. Also all addresses will contain a signature, making them somewhat longer (about 188 characters), but this leads to an overall more robust and simpler design.

Those tiers seem to multiply like rabbits

meeting time: monero-project/meta #646

1. greetings

hello

Hi

Hi there

hi

2. updates: anyone working on stuff they want to mention? tevador gave his update just before the meeting

me: nothing to really update here; I am revising my wallet architecture based on tevador's ongoing work

I am doing chain analysis work on BCH with the `igraph` R package. The packages is fast and fairly memory efficient. I think that it could be used to answer some Monero transaction graph questions that people sometimes muse about.

Have a quick example for such a question?

Basically, questions about how intertwined the Monero "transaction graph" is, and how quickly a new output is intertwined.

I am starting on the effort to get merchant input on Seraphis address schemes, but I think I should wait until the "menu" becomes stable.

7 entries and counting

You mean this from earlier in the log, right? gist.github.com/tevador/50160d160d2…e02eb3d17024#46-wallet-access-tiers

I've been working on subaddress support in monero-lws, I hit a point where I feel it makes sense to submit a proposal for lightwallet servers generally to support subaddresses in a clean way. planning to submit it today

rbrunner: Given a particular output (i.e. vertex/node) of a particular age, what proportion of the Monero transaction graph can be reached from that vertex/node?

In other words, what is the anonymity set of that output?

I see

4.5 key hierarchy is also golden in Tevador's linked gist. My, we will have so many secret keys, they build hierarchies :)

cool jberman[m] thanks :)

rbrunner: I think this hierarchy will be final, there isn't much more you can extend it to do (if anything).

Comforting, in a way. I hope well get all this complexity properly under control, that's all I worry.

It's fascinating of course, functionality-wise

How high we will tower over other coins with these capabilities?

Once I pause my BCH work again, I will return to making the OSPEAD technical specification more layperson-friendly and then publicly release it. If anyone wants to give input on the draft, just let me know and I will send it your way.

3. discussion; any discussion items? perhaps from the agenda? questions about JAMTIS maybe?

jberman[m]: awesome! TheCharlatan has an open pull request integrating lws in farcaster (he wrote a client lib in rust github.com/TheCharlatan/monero-lws-rs)

Those lightwallet servers will also have to catch up to JAMTIS or whatever will get built?

Guess so, implementing some of those tiers

UkoeHB: About your proposal to relax the 10 block lock: It seems that people do not compromise on ring signatures in order to enable quick spending. So somehow we need to figure out how to keep ring sigs but eliminate the 10 block lock.

Which is what makes it an open research question.

We might want to clearly separate a jamtis address and its optional associated data like recipeint ids, invoices, etc. This would avoid the problems users have with integrated addresses, where people see two distinct addresses that are the same under the hood.

The CRC can still encompass the whole address.

there may be other ways to accomplish quick spending such as batched chained payments or multiple outs on a single tx

the whle address + remainder.

re keeping ring sigs, or we eliminate them :)

it's about time we prioritized that

I don't have a lot of optimism, but let me know if you have any ideas.

any fingerprintability should be a priority to eliminate for us right?

Right, we have quite a number of people freaking out a little when the integrated address is not equal to the "base" address they see e.g. on their ledger

I'll remind everyone that MRL is not systematically monitoring the academic literature about Monero, and solutions to our problems like the 10 block lock may lie in that literature. I still have the moneroresearch.wtf domain name, which hopefully will be Where To Find Monero Research in the future.

ring sigs are cans of worms in that regard with open vulns

Rucknium[m]: i'd say MRL should and has had that in its mandate - to stay up to date on the lit

endogenic: Sure, but you need the resources to do it. We don't have the resources at the moment.

sure we do

we dont have the researchers to do it

MRL isn't an entity, if you want to read papers then go do it

indeed

is there a pubmed equivalent for math/crypto ??

If one wanted to have a look, is there a go-to web address?

Usually one uses adaptor signatures for parallel composition of txs (independent outputs), and tx chaining for serial composition (dependent outs)

arxiv has a number of preprints.

"pre" being importand here.

So the bleeding edge?

By resources I meant researchers. But last time I said "human resources" people didn't like that term.

:)

Lol

You... you... consumer...

And don't get me started on human capital...

ok it seems like we are out of topics, how about we end the meeting here?

thanks koe

rbrunner: It's not just cryptography that "may be" useful to Monero is being published. People are writing on Monero specifically and we aren't checking what they are saying, which is both an opportunity and a threat vector

See scholar.google.com/scholar?as_ylo=2021&q=monero

i mean, so would moneroresearch.wtf simply have the results of that google scholar output? maybe curated a bit to weed out stuff?

The rough idea is yes, basically that. Curated and commented, categorized. Mostly for "internal" use, but we can direct potential new researchers there too.

tevador: new architecture diagram irccloud.com/pastebin/pXIH9Mfj

My idea is RPC can wrap the WalletManager

When would be a good time to consider (can? should?) using ristretto? Do any of the upcoming changes lend themselves to such an additonal change?

Now is probably a good time to consider it, if ever. The amount of work to implement and audit it would be significant though.

i do want to follow up regarding the DAA discussion from a few weeks ago

if time permits

go for it

I'd be curious about the overall performance changes with ristretto. The equality check is faster. I am assuming the current key image check would be replaced by some part of ristretto.

I think overall the effect would be small, since tx verification/construction is dominated by membership proofs and range proofs.

Rucknium[i]: Thanks for the Google Scholar link. The Monero-mentioning entries there seem to be spaced roughly about 5 days apart

Right. Which illustrates the scale of the problem/opportunity.

ha, ironically i had a meeting that I forogt about so I had to rush to that.

I think the level of work required to really explore the DAA and properly test solution will require a great deal of effort. I think the wise thing for me to do now is finish up this publication im working on before switching gears to this effort

im not a fan of multi tasking or piecemealing my work: I think it leads to mistakes (especially if it is technical)

my estimate for working on the DAA, start to finish, complete with testing, is about 1 year full time (40 hours/week at 75% efficiency)

i base that on my past experience working R&D programs in control systems

did you check out github.com/zawy12/difficulty-algorithms ?

there has already been a lot of research on it by an electrical engineer

also github.com/zawy12/difficulty-algorithms/issues

I did, and I dont think this work is rigorous enough relative to the importance of the problem.

it isnt something I would personally feel comfortable publishing without disclaimers. testing and prototyping is different, however

moneromooo: the associated address data are not at all like the payment id. Sending to the wrong payment id (or none) means the payment won't be recognized by the recipient. The jamtis address metadata are only informational for the sender and don't affect the resulting transaction.

additionally, the invoice addresses will have the same ID displayed to the user as the non-invoice variants

UkoeHB: I think the performance benefit of ristretto could be noticeable because we wouldn't need to multiply every group element by 8^-1 in proofs

OK. I'm not sure why you are telling me that.

That is, I don't see the link to what I said.

tevador: not really, I'd wager it's less than 5% overall

most of tx verification cost is scalarmultKey in the membership proof (unless you have very small ring size)

ristretto would mean we lose supercop (ASM implementation), sounds like an overall performance loss

moneromooo: then can you clarify the issue?

selsta: we only need the encoding/decoding part from ristretto, everything else can stay the same I think

Alice buys stuff from Bob. Bob gives Alice an adress containing the price for that stuff. Alice sees a different address because her software "unwrapped" the address Bob gave. Alice freaks out.

So, I think Alice would not freak out if the two addresses had an exact same prefix, with a clear demarcation where the extra data begins (eg, a / character or similar).

I still don't understand what you mean by "Alice sees a different address"

She compares both addresses and notices they're not the exact same.

Why would the software display a different address?

The software will display something like h8eug-w77qs-aaf7m-ww63i-hn33c as the recipient ID, which is independent of the address metadata

Because people would program it to do that -_-

it's literally impossible to "unwrap" a jamtis invoice

So you're assuming that all software will display a canonical form, and therefore it'll be OK ?

OK.

the key K3 will change if you modify anything in the address

basically, you need 3 keys K1, K2, K3 to construct a tx. Address contains K1, K2 and K3 is calculated based on the hash of the address contents

what happened with integrated addresses was that wallets would display the base address with the payment id separate so people would freak out

that wounds like bad wallet design

sounds*

afaik ledger still hasn't fixed this to this day

not sure if the GUI did :D

Which may instill a bit of humbleness into any assumptions how fast we will have an ecosystem supporting something so multi-faceted and multi-functional as JAMTIS

If after so many years proper UI/UX for integrated addresses is not yet here, LWS servers just NOW get a PR to support subaddresses, MyMonero to this day does not fully support subaddresses ...

And now we have a proposal on the table with 7 tiers. Really, I am in awe, it's pure genious, but oh all the additional complexity.

I know, know, I start to repeat myself :)

Then we better add this quick to leave people more time to get it done ^_^

Good idea ...

Maybe we need WOW to go ahead, and we iron out kinks based on their experiences.

Not all of the tiers have to be implemented in software from the beginning. But the scheme supports those access levels if they are deemed useful in the future to implement.

I am hoping a more modular design will make it easier to implement different pieces ad hoc and third-party. It should mostly be a matter of porting things around, instead of needing to grok wallet2 first.

<rbrunner> "And now we have a proposal on..." <- Something to keep in mind: scope creep. More isnt better if you cant execute. I always tell people to be mindful of this and work programs in an iterative fashion. For example: get the most important features first, then the next most, so on and so forth. There are plenty of examples of failed efforts due to this. The Librem 5 is an example.

And by contrast, the PinePhone is an example of good project management

It's still better to have a design that supports more rather than less because we're unlikely to have a second chance to do a complete overhaul of addresses. When the proposal is complete, I will also add a "minimal implementation" specs that can ignore all of the extra features.

I agree, it's a good chance, and I don't doubt that much thought went already into this, and will continue to go into.

But on the other hand the project has grown to massive proportions, don't you agree?

Modularity is a big plus, and may enable to pull this off. Just let us learn from similar things, in a broad sense, that ran into problems.

seraphis is a massive project

Take USB 3 / 3.1 / 3.2 / Thunderbolt whatever.

Despite best intentions, massive consumer confusion, big growing pains, things that are not compatible (yet) etc.

The "implement what tiers you like" angle does sound a lot like that.

True, Seraphis is massive, but I think from UkoeHB's "address schemes" table to JAMTIS is quite a jump. Or do I mis-interpret? Might be, I confess.

Maybe with good project management, in addition to the without-a-doubt brilliant technical work so far, this will work.

However, if I look at Monero's track record there so far, with "loose consensus" and all ... er ...

Well :)

Maybe define a minimum viable functionality and then hide all the other, more advanced stuff, until the minimum is properly implemented :)

I think it's important to fully define the entire API, otherwise there may be painful/infeasible refactors down the road.

the entire core API*

Anyway, I am more than a little bit out of my league as far as the whole technology and crypto is concerned, I may well overestimate the problems now.

Or the refactors simply don't happen, right, see wallet2 ...

Today there was a thread on Reddit where somebody seriously argued BTC has big advantages over XMR because it's almost guaranteed that BTC won't change. Interesting.

Alright, enough rumbling from me for today. 'Night :)

I guess you can never make everyone happy. Some people will complain about missing features, some people will complain about too many features.

my recommendation is to make sure you have a clearly defined task list and labor estimate for each activity, specific time lines arent as important

i meant to send that an hour ago

my bad, pulled in too many directions

regardless, im not a crypto or CS guy, but any big undertaking needs a solid plan of execution with clear goals. Do not skip this step and if anyone needs my help or wants to run something by me I cam set aside some time

jesus my typing is bad - digital keyboards are too small for my hands

<rbrunner> "Today there was a thread on..." <- That is a trade off between pradictability and adaptability. Change is good if it is useful for survival and sustainment. For its own sake not so much.

<UkoeHB> "selsta: we only need the..." <- Wouldnt you also need the ristretto equality check and hash to point algo?

Here is libsodiums ristretto implementation: github.com/jedisct1/libsodium/blob/…ed25519/ref10/ed25519_ref10.c#L2746