Is there any security risk to search for a specific prefix (on moneroaddress.org)

Mainly concerned if the wallet generation is random enough

Switched to vanity-monero because its apparently way quicker, anyone ever heard of it?

I've seen it before, but never used either

What's wrong with just using the official wallet in offline mode to generate a seed?

Oh right, you want the prefix

I don't even know why, I'm not gona use it for exchanges and sub addresses are way more practical for payments

meeting ~3.5hr monero-project/meta #654

whoops, meeting time monero-project/meta #654

1. greetings

hello

Salutations.

Hi there

Hi

hello :)

Hello

Hi

Excited to be on my first meeting. Hope you guys solve a lot of things haha

2. I suppose we can do updates; what has everyone been working on?

the big topic today is probably monero-project/monero #8157, but we can get to that in a few minutes

Yeah, that was what I was busy with ...

me: I finally resumed coding my PoC, right now I am in the middle of implementing core jamtis components.

Been working on updating view tag code thanks to rbrunner 's review. He caught some good stuff

me: Recruiting work. And the MAGIC Monero Fund had its first meeting earlier this week. We will do weekly meetings initially.

btw good news: this PR is on track to being merged monero-project/monero #8052 , this comment might be interesting to some: monero-project/monero #8052#discussion_r791165516

compared to the past, we are right now pretty low on new research ideas (a lot of things being implemented: seraphis + jamtis + semantic reforms, view tags)

should we move on to rbrunner's post?

Personally, I have a huge amount of code to write still, so that will be my main focus for the next month or two.

From experience with IT projects I expect any project as I described it to be a marathon, certainly not a sprint

I think if really takes off it will take the whole year, basically

Consensus takes time.

By the way, I also made a post on Reddit, for more visibility: old.reddit.com/r/Monero/comments/sc…t_left_behind_make_sure_our_wallets

I want to call attention to a specific thing rbrunner pointed out in my view tag PR ​that I'm still looking into: I introduced a serialization change that could cause issues for users before the hard fork, specifically to the struct `tx_construction_data`, which is used when passing around unsigned tx's. I'm trying to understand its full ramifications, but I don't really see a way around it at this point

I had no time yet to answer, but I am hopeful it's a complete non-issue, thanks to the hardfork

Thankfully

do hardforks typically invalidate stuff in files?

Indirectly. I think every possible transaction in the old serialization format that this breaks is invalid anyway: Too small a ring

wrong proofs, not BP1

*BP+

Nobody will blame poor jberman[m] :)

I will look closer at this anyway. Stay tuned. Anyway, the review is nearing it's close, from my point of view.

makes sense; contractually, it makes sense to always start fresh for 'partial txs' when crossing a hardfork boundary

the issue in this case is that it could cause issues for users who upgrade software before the hard fork (i.e. introduce incompatibility across software even before the fork height).

I think it's worth keeping in mind something like that view tag issue in the context of this larger wallet transition. We want to avoid breaking changes like this when making updates in the future, and this proposed major rewrite toward a wallet3-like variant keeping stuff like this in mind I think would actually *reduce* the plausibility for future breaking changes, even if it causes pain in the shorter term to people who built

around wallet2

Ah, right, it will start to serialize that way before the hardfork already ... hmmm ...

imo one problem we have is munging old formats with each update, instead of having separate, versioned structures

if you had to add a new 'v15' structure, that would be way easier to deal with

or v16, whatever we are on

Yeah, one can dream :) Such things certainly are to be discussed for something like "wallet3". At least there.

However such versions can heighten the pain on the implementation side

the Monero side I mean

agreed UkoeHB , some structures use this versioning scheme with `VERSION_FIELD` which I think makes sense to add in this one so long as we have this opportunity

anyway, I don't think this is something that needs a lot of discussion in this meeting, more investigative dev grunt work is needed I think. just wanted to highlight it and point out its relevance to the larger change. fine with omving on

thanks jberman[m]

The reactions to my post have been mixed so far, especially of course on Reddit. But so far nobody with weight spoke out against it, in the way of "no need", or "does not make sense", IMHO

I guess in any case I will go on and try to speak directly with some key people, e.g. wallet devs

I see it as strengthening Monero

Hopefully some interested parties can split the work in smaller chunks. Albeit I share the concern and importance of getting the ball rolling as soon as possible, the tone may somewhat make developers and researchers dubious of jumping in, since for outsiders, it might look like way too much to undertake with no substantial cues in. rbrunner

Touching base with wallet devs is a good first step. Appreciate you making the post all the way.

Thanks

Will be interesting to get them to look so far ahead.

For outsiders it looks different in quite fascinating ways, as can be seen by the comments on Reddit.

I think I shared the post with m2049r from Monerujo yesterday. :)

Nice

By the way, what's the current think, will Tevador code anything for that Seraphis wallet PoC, or is that your show only, UkoeHB?

Is there precedent? Has another chain done a forced address format upgrade? (Or course BTC has had optional address format upgrades.)

I believe tevador is writing test vectors and stuff in python. All the core PoC will be me though

Ok, simplifies discussions as soon as results are visible :)

I never heard of such an address update, but maybe that does not mean much.

And I think that particular aspect is one of the easier ones, in the grand scheme of things.

Still needs a good migration strategy, of course

As does wallet file migration, and many other things

I guess Zcash has made obsolete some of its shielded pools, so that's a bit of a precedent I suppose.

Anyway, I am afraid we won't be able to look much to precedents to see "how it's done"

or how it's not done of course :)

It does need a good migration strategy which why raising this is very important

This is something even I as a "crypto noob" can probably research

well, I appreciate your effort rbrunner :) otherwise all my research and code might stagnate and die lol

You are welcome. We will avoid that, would be a terrible pity

+1

before the meeting ends, does anyone have any comments/questions about any topic?

Reminder: dev meeting on Saturday, 1700 UTC. #monero-dev monero-project/meta #652

ah thanks

Right. Make that hardfork happen.

...only if more people push it along. ;-)

Review, review, review :)

sorry for being quite unresponsive lately UkoeHB. I've started the review of #7877, more changes than I remembered.

UkoeHB: Same day, same time for next MRL meeting, correct?

oh sweet thanks h4sh3d

yes Fungibility

we seem to be done, so I'll call the meeting here; thanks for attending everyone

Thanks

A delayed quick report: I've been working on making my tooling more accessible, where QT5 doesn't work. Here are some screenshots, showing how I use Python for this purpose. I will write a full report at the end of the month anyway with more information.

Btw I realized something. Seraphis enotes don't need to include a hash of the 'output index' (unless I am mistaken), which means you can create an isolated enote sending money to yourself (or someone else), then chain a tx on top of that enote. At a later date the enote can be incorporated in a full destination set (which includes a change enote as needed), then the destination set can be funded (add tx inputs), then

the funded destination set can be converted to a full tx (add membership proofs for inputs). Overall, this means tx chaining is even more flexible than I originally thought.

Right now we need an output index because multiple outputs can share a single tx pubkey. Without the index, outputs to the same destination address will have the same one-time address (etc.).

But with Seraphis, I will enforce 1 enote pubkey per output, except for 2-out txs where the change enote will share with the other output.

nice

Is there any way of visualizing and retrieving information from the blockchain file (data.mdb) without using the monero software? Would it be possible for example to use dbeaver or something similar?

Some (not much) of it, with mdb_dump. But most of the information will not be easy to understand (ie, C structs).

But mdb_dump only can give you hte list of spent key images for example.

Only usable for very simple table formats.

dangerousfreedom: You may want to check out

dangerousfreedom: I've been using this to get chain data into PostgreSQL: github.com/coinmetrics/haskell-tool…b/master/docs/coinmetrics-export.md

Rucknium[m]1: jinx

dangerousfreedom: this is what data it has: github.com/neptuneresearch/monero-n…tes/blob/main/coinmetrics-export.md

I also have some SQL stuff on my github that you can run on that database to get more info from tx_extra and ring members.

what data did you want...

** what data did you want?

Nice. Thank you neptune and moneromooo . I want the ring members and unused key images. I will check it, thanks ;)