<r​ucknium:monero.social> MRL meeting in this channel in one hour

<r​ucknium:monero.social> Meeting time! monero-project/meta #965

<r​ucknium:monero.social> 1) Greetings

<j​effro256:monero.social> Howdy

hi

Hello

<h​into.janaiyo:matrix.org> hello

<r​ucknium:monero.social> 2) Updates. What is everyone working on?

I'm investigating whether ssl trust-on-first-use for wallet2/simplewallet can be added without destroying the codebase

the goal is to have a user interactive warning if a daemon ssl cert changes

<j​effro256:monero.social> Getting back to seraphis development after writing the pool handling PR

<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.

<h​into.janaiyo:matrix.org> working on cuprate's db thread/actor system

<r​ucknium:monero.social> 3. Discussion. What do we want to discuss?

<j​effro256:monero.social> I wanted to revisit issue monero-project/research-lab #78 and seriously discuss removing the unlock time from future transactions

<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.

<r​ucknium:monero.social> I am in favor of prohibiting new txs with custom unlock time in the next network upgrade.

<j​effro256:monero.social> Regarding the unlock time, I went ahead and wrote a PR which would ban nonzero unlock times in the mempool : monero-project/monero #9151

<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

<j​effro256:monero.social> What DB format will cuprate use ?

<r​ucknium:monero.social> Yes, that's what I meant. Without `cuprated`.

<r​ucknium:monero.social> Don't change your design plans at all if it would not be possible with your intended path. Just wondering.

<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

<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

<j​effro256:monero.social> You have two different DB backends planned ?

<h​into.janaiyo:matrix.org> yes, one is basically a shim around LMDB, the other is an original rust db

<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".

<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

<j​effro256:monero.social> but damn is it fast

there's nothing C++-specific about the objects

there are a bunch of 64bit and 256bit hashes

<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

<0​xfffc:matrix.org> I thought we are saving the hashes, not the objects too.

<j​effro256:monero.social> Well you also know how your system packs the structs

<j​effro256:monero.social> IIRC most structs use the default compiler packing and not something like pragma pack 1

Er ... I think the members get written one by one, each one after the other, never some struct as a whole

I.e. 1 call for every value

<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

<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)

<r​ucknium:monero.social> I'm basing my (maybe incorrect) knowledge of the database's contents on this answer: monero.stackexchange.com/questions/…-and-how-explore-its-contents-using

<0​xfffc:matrix.org> github.com/monero-project/monero/bl…lockchain_db/lmdb/db_lmdb.cpp#L2530

<0​xfffc:matrix.org> Lets look at the code to make sure.

I am quite sure that any compiler packing questions don't play any role because we simply don't write out structs

<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: github.com/monero-project/monero/bl…blockchain_db/lmdb/db_lmdb.cpp#L835

<0​xfffc:matrix.org> github.com/monero-project/monero/bl…blockchain_db/lmdb/db_lmdb.cpp#L814

<j​effro256:monero.social> Jinx

how is any of this detail important?

Ah, ok, that's one level deeper than I was thinking

<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

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

"loose consensus" failed to materialize for once, and then the subject was dropped ...

<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++

<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?

<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

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

<r​ucknium:monero.social> I don't really think it should be banned by tx relay rules before a network upgrade.

<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

If we have now somebody with jeffro256 we hopefully can get rid of that

<j​effro256:monero.social> Why not banned by relay rule ?

jeffro256 the structs being written are just collections of 64bit and 256 bit values. no packing required, no padding present. github.com/monero-project/monero/bl…blockchain_db/lmdb/db_lmdb.cpp#L283

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

<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.

<r​ucknium:monero.social> Ban by relay rule is best for when there is a widespread active problem

There were some long Reddit threads with some user opinions

<r​ucknium:monero.social> Like Mordinals

<r​ucknium:monero.social> Ban by relay rule might not be successful.

I think somebody could achieve a "widespread active problem" if they spammed Monero processing entities left and right with tiny amount locked txs.

Don't want to give anybody ideas, just saying maybe we just kill it, and get over it, and live happily ever after.

<r​ucknium:monero.social> Ok. But make sure there is rough consensus in the userbase first.

I am with you here, but that's easier said than done :)

First problem is, if I remember Reddit discussions, to get "pure users" to understand the problem and the "feature" properly.

<r​ucknium:monero.social> IMHO, it is acceptable to filter out opinions that are based on complete wrong understanding of the feature.

A quick search on Reddit gave me this: old.reddit.com/r/Monero/comments/mw…send_future_monero_to_yourself_with

Or this warning from MajesticBank: old.reddit.com/r/Monero/comments/z5…incoming_payments_can_confirmed_but

<j​effro256:monero.social> Basically everything, including that first post, that uses unlock_time for something can be done with a time lock puzzle

<r​ucknium:monero.social> AFAIK, not checking unlock time has been a security problem for multiple payment processors.

<j​effro256:monero.social> ^^^

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.

*currently possess

Yes, that's what I meant, I doubt that everybody is already "prepared". Not by a long shot.

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".

<h​into.janaiyo:matrix.org> does this mean users would have to compute the solution to their own transactions if done this way?

<r​ucknium:monero.social> rbrunner: IMHO, that would be wonderful 👍️

Ok, maybe until Sunday.

<j​effro256:monero.social> @hinto: yes

<r​ucknium:monero.social> I will put it on next MRL agenda in the GitHub issue so there is "official" notice posted.

<r​ucknium:monero.social> I have read of time lock puzzles. I didn't understand how CPU power would not affect time to unlock.

<r​ucknium:monero.social> For example, I think some Monero payment channel ideas are based on time lock puzzles.

<j​effro256:monero.social> CPU power does affect time to unlock

<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?

<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.

<r​ucknium:monero.social> Which apparently plowsof and I need to renew the SSL cert of

<r​ucknium:monero.social> Two days late

Lol

Happens to the very best webmasters

<h​into.janaiyo:matrix.org> Rucknium: certbot.eff.org

<r​ucknium:monero.social> I couldn't get certbot to work with my domain provider

<h​into.janaiyo:matrix.org> sounds like you need a new provider

<r​ucknium:monero.social> I think the paper was this one: moneroresearch.info/index.php?actio…n=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.

Oops

<r​ucknium:monero.social> Sounds like plowsof needs to set up auto reminders :P

Am i allowed to use the fluffy excuse of reminders going into my spam folder :(

<r​ucknium:monero.social> Anything more to discuss?

<j​effro256:monero.social> How's bp++ reviews coming along ?

<r​ucknium:monero.social> Diego Salazar: Sorry to bother. Any comments on the state of BP++ review?

<r​ucknium:monero.social> We can end the meeting here.

<k​4r4b3y:karapara.net> Afaik caddyserver renews the certs for you automatically. Just throwing its name out there...

<d​iego:cypherstack.com> 80 hours into the review

<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?

<1​23bob123:matrix.org> Most do if you have certbot

<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.

<1​23bob123:matrix.org> Nginx,apache,nginx manager

<d​iego:cypherstack.com> We're roughly at the halfway point.

<d​iego:cypherstack.com> And we'll complete it until it's done.

<d​iego:cypherstack.com> Lol. Bad phrasing. We'll keep working until it's done.

Phew

<d​iego:cypherstack.com> If I can give a bit of a spoiler, my personal opinion is not high of bp++

<r​ucknium:monero.social> (I knew it)

<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.

<r​ucknium:monero.social> any procedures _if needed_

<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.

<d​iego:cypherstack.com> always