16:00:42 <m-relay> <r​ucknium:monero.social> MRL meeting in this channel in one hour
17:00:26 <m-relay> <r​ucknium:monero.social> Meeting time! https://github.com/monero-project/meta/issues/965
17:00:32 <m-relay> <r​ucknium:monero.social> 1) Greetings
17:00:58 <m-relay> <j​effro256:monero.social> Howdy
17:01:13 <vtnerd> hi
17:01:14 <rbrunner> Hello
17:01:43 <m-relay> <h​into.janaiyo:matrix.org> hello
17:03:13 <m-relay> <r​ucknium:monero.social> 2) Updates. What is everyone working on?
17:04:49 <vtnerd> I'm investigating whether ssl trust-on-first-use for wallet2/simplewallet can be added without destroying the codebase
17:05:21 <vtnerd> the goal is to have a user interactive warning if a daemon ssl cert changes
17:05:35 <m-relay> <j​effro256:monero.social> Getting back to seraphis development after writing the pool handling PR
17:05:51 <m-relay> <r​ucknium:monero.social> me: Got the list of possible nonstandard txs from isthmus 🙏 , based on custom unlock time and possible cached ring members. I will combine that list with my own list based on nonstandard fees and Mordinal minting/transfers. There is another statistical step after these initial filters to identify the wallet2 rings by their distribution.
17:06:13 <m-relay> <h​into.janaiyo:matrix.org> working on cuprate's db thread/actor system
17:07:18 <m-relay> <r​ucknium:monero.social> 3. Discussion. What do we want to discuss?
17:09:09 <m-relay> <j​effro256:monero.social> I wanted to revisit issue https://github.com/monero-project/research-lab/issues/78 and seriously  discuss removing the unlock time from future transactions
17:09:11 <m-relay> <r​ucknium:monero.social> hinto: When you are finished with cuprate's database, do you think it would be possible to directly read its contents without monerod? OK if not.
17:10:03 <m-relay> <r​ucknium:monero.social> I am in favor of prohibiting new txs with custom unlock time in the next network upgrade.
17:10:32 <m-relay> <j​effro256:monero.social> Regarding the unlock time, I went ahead and wrote a PR which would ban nonzero unlock times in the mempool : https://github.com/monero-project/monero/pull/9151
17:11:04 <m-relay> <h​into.janaiyo:matrix.org> do you mean without `cuprated`? Cuprate's db and `monerod`'s db won't be compatible, but i'm sure we could make a separate tool that can work with `cuprated`'s db
17:11:38 <m-relay> <j​effro256:monero.social> What DB format will cuprate use ?
17:11:43 <m-relay> <r​ucknium:monero.social> Yes, that's what I meant. Without `cuprated`.
17:12:23 <m-relay> <r​ucknium:monero.social> Don't change your design plans at all if it would not be possible with your intended path. Just wondering.
17:13:16 <m-relay> <h​into.janaiyo:matrix.org> in terms of format, it is just a regular `.mdb` file, it's just the schema/tables & byte encodings that will differ than `monerod`'s db
17:13:36 <m-relay> <h​into.janaiyo:matrix.org> and the other database backend we have planned doesn't use LMDB at all, i guess it is its own format
17:14:13 <m-relay> <j​effro256:monero.social> You have two different DB backends planned ?
17:15:52 <m-relay> <h​into.janaiyo:matrix.org> yes, one is basically a shim around LMDB, the other is an original rust db
17:16:12 <m-relay> <r​ucknium:monero.social> AFAIK, if I try to read monerod's database, I would get serialized C++ objects that only make sense to monerod. With cuprate would I get serialized Rust objects that only make sense to cuprated? It is ok if the answer is "yes".
17:17:31 <m-relay> <j​effro256:monero.social> Its even more specific than that, it's objects that only make sense to monerod on systems with the same ABI
17:17:42 <m-relay> <j​effro256:monero.social> but damn is it fast
17:17:52 <hyc> there's nothing C++-specific about the objects
17:18:17 <hyc> there are a bunch of 64bit and 256bit hashes
17:18:40 <m-relay> <h​into.janaiyo:matrix.org> i'm not sure about the more complex objects/types, but a lot of the things stored are language agnostic bytes
17:18:47 <m-relay> <0​xfffc:matrix.org> I thought we are saving the hashes, not the objects too.
17:19:02 <m-relay> <j​effro256:monero.social> Well you also know how your system packs the structs
17:20:17 <m-relay> <j​effro256:monero.social> IIRC most structs use the default compiler packing and not something like pragma pack 1
17:21:08 <rbrunner> Er ... I think the members get written one by one, each one after the other, never some struct as a whole
17:21:23 <rbrunner> I.e. 1 call for every value
17:21:29 <m-relay> <0​xfffc:matrix.org> If we store serialized objects, I think there will be some C++/compiler specific stuff that will be saved. But my points was I thought we are only saving the members
17:21:29 <m-relay> <h​into.janaiyo:matrix.org> yes rust structs are undefined, you can specify manual layout but i don't think any of our/monero-serai's type do that (yet)
17:21:57 <m-relay> <r​ucknium:monero.social> I'm basing my (maybe incorrect) knowledge of the database's contents on this answer: https://monero.stackexchange.com/questions/10919/understanding-the-structure-of-moneros-lmdb-and-how-explore-its-contents-using
17:23:51 <m-relay> <0​xfffc:matrix.org> https://github.com/monero-project/monero/blob/059028a30a8ae9752338a7897329fe8012a310d5/src/blockchain_db/lmdb/db_lmdb.cpp#L2530 
17:23:51 <m-relay> <0​xfffc:matrix.org> Lets look at the code to make sure.
17:23:57 <rbrunner> I am quite sure that any compiler packing questions don't play any role because we simply don't write out structs
17:24:43 <m-relay> <j​effro256:monero.social> rbrunner7: this isn't always the case. Some structs are sent in their entirety to the DB in their arbitrary layout: https://github.com/monero-project/monero/blob/059028a30a8ae9752338a7897329fe8012a310d5/src/blockchain_db/lmdb/db_lmdb.cpp#L835
17:24:51 <m-relay> <0​xfffc:matrix.org> https://github.com/monero-project/monero/blob/059028a30a8ae9752338a7897329fe8012a310d5/src/blockchain_db/lmdb/db_lmdb.cpp#L814
17:25:21 <m-relay> <j​effro256:monero.social> Jinx
17:25:27 <hyc> how is any of this detail important?
17:25:38 <rbrunner> Ah, ok, that's one level deeper than I was thinking
17:26:34 <m-relay> <r​ucknium:monero.social> Ok, maybe this detail isn't important. We can move on to discussing jeffro256 's topic on prohibiting new txs with custom unlock time
17:27:20 <rbrunner> If I remember correctly unlock time is still with us and not long gone solely because we just could not get our act together and afterwards find somebody coding their end
17:27:43 <rbrunner> "loose consensus" failed to materialize for once, and then the subject was dropped ...
17:27:46 <m-relay> <j​effro256:monero.social> It's not super important but it does make it slightly easier to write debugging tools, especially in languages that aren't c++
17:28:42 <m-relay> <r​ucknium:monero.social> rbrunner: Can you remember why loose consensus was not reached? Does anyone here support keeping it the way it is, even a little?
17:28:50 <m-relay> <j​effro256:monero.social> Im very much of the opinion to move forwards and ban nonzero unlock times obviously which is why I alreafy wrote the code
17:29:42 <rbrunner> Not sure, I don't remember it to that detail. Maybe also mixed in was sheer lack of enthusiasm, lack of somebody who took the lead
17:29:58 <m-relay> <r​ucknium:monero.social> I don't really think it should be banned by tx relay rules before a network upgrade.
17:30:04 <m-relay> <j​effro256:monero.social> It comes up frequently that we have to engineer really tricky edge handling logic when we take into account unlock times, most recently with working with the new seraphis enote store
17:30:06 <rbrunner> If we have now somebody with jeffro256 we hopefully can get rid of that
17:30:40 <m-relay> <j​effro256:monero.social> Why not banned by relay rule ?
17:30:43 <hyc> jeffro256 the structs being written are just collections of 64bit and 256 bit values. no packing required, no padding present. https://github.com/monero-project/monero/blob/059028a30a8ae9752338a7897329fe8012a310d5/src/blockchain_db/lmdb/db_lmdb.cpp#L283
17:31:08 <rbrunner> I am pretty sure there is a high number of people out there processing Monero transactions that would get cought with their pants down if you send them a locked tx
17:31:22 <m-relay> <r​ucknium:monero.social> Maybe the biggest thing to work on is making sure users can have their say on banning new custom unlock time.
17:31:57 <m-relay> <r​ucknium:monero.social> Ban by relay rule is best for when there is a widespread active problem
17:32:01 <rbrunner> There were some long Reddit threads with some user opinions
17:32:02 <m-relay> <r​ucknium:monero.social> Like Mordinals
17:32:45 <m-relay> <r​ucknium:monero.social> Ban by relay rule might not be successful.
17:33:12 <rbrunner> I think somebody could achieve a "widespread active problem" if they spammed Monero processing entities left and right with tiny amount locked txs.
17:34:12 <rbrunner> Don't want to give anybody ideas, just saying maybe we just kill it, and get over it, and live happily ever after.
17:34:55 <m-relay> <r​ucknium:monero.social> Ok. But make sure there is rough consensus in the userbase first.
17:35:21 <rbrunner> I am with you here, but that's easier said than done :)
17:35:53 <rbrunner> First problem is, if I remember Reddit discussions, to get "pure users" to understand the problem and the "feature" properly.
17:36:46 <m-relay> <r​ucknium:monero.social> IMHO, it is acceptable to filter out opinions that are based on complete wrong understanding of the feature.
17:37:32 <rbrunner> A quick search on Reddit gave me this: https://old.reddit.com/r/Monero/comments/mwrm6g/how_to_lock_send_future_monero_to_yourself_with/
17:38:02 <rbrunner> Or this warning from MajesticBank: https://old.reddit.com/r/Monero/comments/z51c19/warning_incoming_payments_can_confirmed_but/
17:39:23 <m-relay> <j​effro256:monero.social> Basically everything, including that first post, that uses unlock_time for something can be done with a time lock puzzle
17:40:55 <m-relay> <r​ucknium:monero.social> AFAIK, not checking unlock time has been a security problem for multiple payment processors.
17:41:13 <m-relay> <j​effro256:monero.social> ^^^
17:41:17 <rbrunner> Yeah, but it's a fact of life that sometimes you get illogical if it's question to let go of something that you currency possess. Like this feature.
17:41:31 <rbrunner> *currently possess
17:41:56 <rbrunner> Yes, that's what I meant, I doubt that everybody is already "prepared". Not by a long shot.
17:43:38 <rbrunner> I could try to write a post on Reddit and fish for fresh opinions, and also giving enough background info to make the whole story understandable for "non-techies".
17:43:52 <m-relay> <h​into.janaiyo:matrix.org> does this mean users would have to compute the solution to their own transactions if done this way?
17:44:01 <m-relay> <r​ucknium:monero.social> rbrunner: IMHO, that would be wonderful 👍️
17:44:25 <rbrunner> Ok, maybe until Sunday.
17:45:20 <m-relay> <j​effro256:monero.social> @hinto: yes
17:45:21 <m-relay> <r​ucknium:monero.social> I will put it on next MRL agenda in the GitHub issue so there is "official" notice posted.
17:46:30 <m-relay> <r​ucknium:monero.social> I have read of time lock puzzles. I didn't understand how CPU power would not affect time to unlock.
17:47:40 <m-relay> <r​ucknium:monero.social> For example, I think some Monero payment channel ideas are based on time lock puzzles.
17:48:12 <m-relay> <j​effro256:monero.social> CPU power does affect time to unlock
17:49:40 <m-relay> <j​effro256:monero.social> I havent read those channel ideas, but would the network verify solutions to the timelock puzzles and give access to coins based on that?
17:50:31 <m-relay> <r​ucknium:monero.social> I don't know. I don't like payment channels much, so I put them in moneroresearch.info and moved on.
17:50:49 <m-relay> <r​ucknium:monero.social> Which apparently plowsof and I need to renew the SSL cert of
17:51:15 <m-relay> <r​ucknium:monero.social> Two days late
17:51:19 <rbrunner> Lol
17:52:00 <rbrunner> Happens to the very best webmasters
17:52:19 <m-relay> <h​into.janaiyo:matrix.org> Rucknium: https://certbot.eff.org
17:53:03 <m-relay> <r​ucknium:monero.social> I couldn't get certbot to work with my domain provider
17:55:02 <m-relay> <h​into.janaiyo:matrix.org> sounds like you need a new provider
17:55:21 <m-relay> <r​ucknium:monero.social> I think the paper was this one: https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=123 Thyagarajan, S. A., Malavolta, G., Schmid, F., & Schröder, D. 2022, Verifiable timed linkable ring signatures for scalable payments for Monero.
17:55:22 <plowsof> Oops
17:55:47 <m-relay> <r​ucknium:monero.social> Sounds like plowsof needs to set up auto reminders :P
17:56:19 <plowsof> Am i allowed to use the fluffy excuse of reminders going into my spam folder :(
17:58:12 <m-relay> <r​ucknium:monero.social> Anything more to discuss?
18:00:02 <m-relay> <j​effro256:monero.social> How's bp++ reviews coming along ?
18:00:46 <m-relay> <r​ucknium:monero.social> Diego Salazar: Sorry to bother. Any comments on the state of BP++ review?
18:03:50 <m-relay> <r​ucknium:monero.social> We can end the meeting here.
18:07:27 <m-relay> <k​4r4b3y:karapara.net> Afaik caddyserver renews the certs for you automatically. Just throwing its name out there...
18:14:47 <m-relay> <d​iego:cypherstack.com> 80 hours into the review
18:17:25 <m-relay> <r​ucknium:monero.social> Diego Salazar: Thanks. IIRC, the CCS proposal did not have a specific number of hours. How many hours do the funds cover?
18:18:39 <m-relay> <1​23bob123:matrix.org> Most do if you have certbot
18:18:58 <m-relay> <r​ucknium:monero.social> If the result after the funds are exhausted is "the soundness could not be verified or disproven", then that is a legitimate conclusion, too.
18:18:59 <m-relay> <1​23bob123:matrix.org> Nginx,apache,nginx manager
18:19:28 <m-relay> <d​iego:cypherstack.com> We're roughly at the halfway point.
18:19:40 <m-relay> <d​iego:cypherstack.com> And we'll complete it until it's done.
18:20:07 <m-relay> <d​iego:cypherstack.com> Lol. Bad phrasing. We'll keep working until it's done.
18:20:21 <plowsof> Phew
18:20:42 <m-relay> <d​iego:cypherstack.com> If I can give a bit of a spoiler,  my personal opinion is not high of bp++
18:21:14 <m-relay> <r​ucknium:monero.social> (I knew it)
18:23:57 <m-relay> <r​ucknium:monero.social> I assume you will follow any vulnerability response procedures. I want to make sure anything MRL is involved in follows good vulnerability procedures. I don't know if Blockstream is using it on mainnet yet. Or anyone else.
18:24:15 <m-relay> <r​ucknium:monero.social> any procedures _if needed_
19:05:17 <m-relay> <c​haserene:matrix.org> it's not ideal, but it is the best temporary fix until a network upgrade enforces it on the consensus level, isn't it? anyone with the previous relay rules may relay it and even get it mined, but the chances of those happening will be reduced, which seems to be a net advantage.
19:05:29 <m-relay> <d​iego:cypherstack.com> always