10:57:46 Is there any security risk to search for a specific prefix (on moneroaddress.org) 11:00:02 Mainly concerned if the wallet generation is random enough 11:34:09 Switched to vanity-monero because its apparently way quicker, anyone ever heard of it? 11:36:26 I've seen it before, but never used either 11:36:43 What's wrong with just using the official wallet in offline mode to generate a seed? 11:36:54 Oh right, you want the prefix 12:05:05 I don't even know why, I'm not gona use it for exchanges and sub addresses are way more practical for payments 13:38:46 meeting ~3.5hr https://github.com/monero-project/meta/issues/654 17:03:17 whoops, meeting time https://github.com/monero-project/meta/issues/654 17:03:23 1. greetings 17:03:23 hello 17:03:28 Salutations. 17:03:33 Hi there 17:03:44 Hi 17:04:27 hello :) 17:05:16 Hello 17:05:20 Hi 17:05:44 Excited to be on my first meeting. Hope you guys solve a lot of things haha 17:06:02 2. I suppose we can do updates; what has everyone been working on? 17:06:25 the big topic today is probably https://github.com/monero-project/monero/issues/8157, but we can get to that in a few minutes 17:07:09 Yeah, that was what I was busy with ... 17:07:24 me: I finally resumed coding my PoC, right now I am in the middle of implementing core jamtis components. 17:10:49 Been working on updating view tag code thanks to rbrunner 's review. He caught some good stuff 17:10:58 me: Recruiting work. And the MAGIC Monero Fund had its first meeting earlier this week. We will do weekly meetings initially. 17:12:02 btw good news: this PR is on track to being merged https://github.com/monero-project/monero/pull/8052 , this comment might be interesting to some: https://github.com/monero-project/monero/pull/8052#discussion_r791165516 17:13:33 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) 17:15:00 should we move on to rbrunner's post? 17:15:50 Personally, I have a huge amount of code to write still, so that will be my main focus for the next month or two. 17:17:14 From experience with IT projects I expect any project as I described it to be a marathon, certainly not a sprint 17:17:36 I think if really takes off it will take the whole year, basically 17:18:05 Consensus takes time. 17:19:14 By the way, I also made a post on Reddit, for more visibility: https://old.reddit.com/r/Monero/comments/sczdrk/no_wallet_left_behind_make_sure_our_wallets/ 17:19:15 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 17:19:30 https://github.com/monero-project/monero/pull/8061#discussion_r789891757 17:19:58 I had no time yet to answer, but I am hopeful it's a complete non-issue, thanks to the hardfork 17:20:19 Thankfully 17:20:43 do hardforks typically invalidate stuff in files? 17:21:19 Indirectly. I think every possible transaction in the old serialization format that this breaks is invalid anyway: Too small a ring 17:21:26 wrong proofs, not BP1 17:21:29 *BP+ 17:21:59 Nobody will blame poor jberman[m] :) 17:22:45 I will look closer at this anyway. Stay tuned. Anyway, the review is nearing it's close, from my point of view. 17:22:45 makes sense; contractually, it makes sense to always start fresh for 'partial txs' when crossing a hardfork boundary 17:23:49 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). 17:23:49 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 17:23:49 around wallet2 17:24:55 Ah, right, it will start to serialize that way before the hardfork already ... hmmm ... 17:25:31 imo one problem we have is munging old formats with each update, instead of having separate, versioned structures 17:25:52 if you had to add a new 'v15' structure, that would be way easier to deal with 17:26:10 or v16, whatever we are on 17:26:24 Yeah, one can dream :) Such things certainly are to be discussed for something like "wallet3". At least there. 17:27:10 However such versions can heighten the pain on the implementation side 17:27:26 the Monero side I mean 17:27:32 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 17:31:15 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 17:31:44 thanks jberman[m] 17:31:57 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 17:33:18 I guess in any case I will go on and try to speak directly with some key people, e.g. wallet devs 17:33:25 I see it as strengthening Monero 17:34:41 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 17:35:08 Touching base with wallet devs is a good first step. Appreciate you making the post all the way. 17:35:23 Thanks 17:36:01 Will be interesting to get them to look so far ahead. 17:36:42 For outsiders it looks different in quite fascinating ways, as can be seen by the comments on Reddit. 17:36:45 I think I shared the post with m2049r from Monerujo yesterday. :) 17:36:56 Nice 17:38:15 By the way, what's the current think, will Tevador code anything for that Seraphis wallet PoC, or is that your show only, UkoeHB? 17:38:23 Is there precedent? Has another chain done a forced address format upgrade? (Or course BTC has had optional address format upgrades.) 17:38:51 I believe tevador is writing test vectors and stuff in python. All the core PoC will be me though 17:39:24 Ok, simplifies discussions as soon as results are visible :) 17:39:56 I never heard of such an address update, but maybe that does not mean much. 17:40:16 And I think that particular aspect is one of the easier ones, in the grand scheme of things. 17:40:29 Still needs a good migration strategy, of course 17:41:12 As does wallet file migration, and many other things 17:42:46 I guess Zcash has made obsolete some of its shielded pools, so that's a bit of a precedent I suppose. 17:43:33 Anyway, I am afraid we won't be able to look much to precedents to see "how it's done" 17:43:46 or how it's not done of course :) 17:43:46 It does need a good migration strategy which why raising this is very important 17:44:49 This is something even I as a "crypto noob" can probably research 17:46:40 well, I appreciate your effort rbrunner :) otherwise all my research and code might stagnate and die lol 17:47:08 You are welcome. We will avoid that, would be a terrible pity 17:47:27 +1 17:49:05 before the meeting ends, does anyone have any comments/questions about any topic? 17:50:40 Reminder: dev meeting on Saturday, 1700 UTC. #monero-dev https://github.com/monero-project/meta/issues/652 17:51:19 ah thanks 17:51:21 Right. Make that hardfork happen. 17:51:36 ...only if more people push it along. ;-) 17:51:49 Review, review, review :) 17:51:52 sorry for being quite unresponsive lately UkoeHB. I've started the review of #7877, more changes than I remembered. 17:51:54 UkoeHB: Same day, same time for next MRL meeting, correct? 17:53:50 oh sweet thanks h4sh3d 17:54:27 yes Fungibility 17:57:32 we seem to be done, so I'll call the meeting here; thanks for attending everyone 17:59:21 Thanks 18:27:48 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. 18:27:49 https://github.com/mj-xmr/tsqsim#example-outputs 19:33:37 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 19:33:37 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. 19:36:19 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.). 19:37:05 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. 19:50:27 nice 21:49:01 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? 21:54:11 Some (not much) of it, with mdb_dump. But most of the information will not be easy to understand (ie, C structs). 21:55:51 But mdb_dump only can give you hte list of spent key images for example. 21:56:11 Only usable for very simple table formats. 21:56:55 dangerousfreedom: You may want to check out 21:56:55 https://github.com/neptuneresearch 21:57:02 dangerousfreedom: I've been using this to get chain data into PostgreSQL: https://github.com/coinmetrics/haskell-tools/blob/master/docs/coinmetrics-export.md 21:57:08 Rucknium[m]1: jinx 21:57:53 dangerousfreedom: this is what data it has: https://github.com/neptuneresearch/monero-notes/blob/main/coinmetrics-export.md 21:59:13 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. 22:00:41 what data did you want... 22:01:20 ** what data did you want? 22:21:19 Nice. Thank you neptune and moneromooo . I want the ring members and unused key images. I will check it, thanks ;)