o/

found undefined behavior in hmac+keccak, where to report better?

sech1: ok

We really need a clarification from the core team about when are hard forks are going to happen. Last time i brought this up in a dev meeting, seemed like nothing changes and we are still going for hard forks every 6 months. Then i read of people mentioning that we moved to 9 months hard fork and now i'm reading the logs of yesterday's MRL meeting and people were assuming that now we have yearly hard forks.

So, what's the deal? Ledger/trezor devs also asked for a timeline, but i think nobody can give one.

I remember luigi mentioning that core were thinking about changing forks time, but rightn ow i have really no idea of what's going on.

Can we have a final word on this? This uncertainty isn't helping anybody

It's uncertain because we don't know. If we don't know, we can't tell you.

I'm not sure why you'd want to determine in advance when we'll fork. It'll be decided when it is.

There's no point in forking on a particular date just because there's a date.

That's a bit of a contrast with what we always said: "let's keep a scheduled hard fork time so that merchants and service are prepatred and know when to expect a network upgrade". If now we moved to "we fork when it's needed" we should make that known and clear, because now somebody think we cfork every year, somebody every 9 months and somebody every 6.

That was the expectation, but in practice most services weren't aware a HF would be performed

Also we were constantly trying to scramble to get everything out on time imo

Well, different people want different things.

The RandomX fork arguably went really smooth and it is probably because we deviated from the original schedule

That's what i'm saying. This uncertainty is going to be a problem, because at the end is core that decide

I cannot speak with certainty, but I think most of core are basically in line with what mooo stated

I'm only asking to clearly define a workflow here, because something this important cannot be "everyone has a different opinion", because people expecting a fork in one year will have their plans messed up if it happens after 6 months, same for all the other cases

dEBRUYNE: I would just like to have a clear statement. Last time luigi said that core was working on the problem of the schedule and nothing else from that moment on

CLSAG's really the only thing we'd want in a fork IIRC. And we don't know when it'll be mergeable due to the audit that's going nowhere in a hurry.

Now there's the gingeropolous method, which is to fork anyway even with no actual changes, just to keep people running recent software :)

moneromooo: Do you know who took it upon them to manage the audit?

Isn't this discussion proving my point? 🙂 We really don't know, but we need to give timeframes. Trezor (or ledger, don't remember) asked for a date of the next hard fork because they have to be prepared. If we tell them 1 year because some of us think that's the schedule and then we fork after 4 months, it's going to be a problem.

There is an audit workgroup afaik

I don't know.

To further clarify my point: i don't care of the timeframe for the HF (1 year, 9 months, 6 months, when it's needed). I care that there is a defined plan and that we are all aware of it. That's what i'm asking core.

I do agree it would be good to have a blog post or a similar document to which we can point

Perhaps this can be discussed in the next dev meeting?

<moneromooo> I don't know. <= All right, I will ask around

That would be good. Last time i didn't have much success.

Hey guys, any tips on creating a coin of my own? I have plans to use either an EOS token, an SLP token, or a coin?

Sure, first tip is to ask in a channel where it's on topic.

alright

my bad

trying to run monerod on 64bit rasbian - getting a crash gist.github.com/stackdump/fe68c4bdfcc6394b5473a005bb7af5c4

there is a crashfile produced - not sure what else I can try to debug

Did you build this for hte right arch ?

ie, armv8/armv7 etc.

I downloaded the binary

Did you download a binary for the right arch ?

yes AFAIK

Try setting the env var: MONERO_USE_SOFTWARE_AES=1, then run again.

similar result

What does gdb say the ill insn is ?

sorry minimal experience w/ using gdb - what should I do?

gdb monerod

run

li

It should show the instructions around where it died.

awesome - it shows "1 ../sysdeps/unix/sysv/linux/aarch64/init-first.c: No such file or directory."

hah well maybe this is more relevant Program received signal SIGILL, Illegal instruction.0x0000aaaaab23232c in aes_expand_key ()(gdb) li

It's apparently trying to use aes insns which your CPU does not have.

If MONERO_USE_SOFTWARE_AES=1 does not help, you need to tell your compiler to not generate aes insns.

Or find a binary where this was done.

cool I can try to make a build

I did try to compile *on* my PI - generally should I be doing this from another X64 Linux & cross-compiling?

Cross compiling will be faster if you already have a setup for it.

thx I'll try to do this

Hey moneromooo, about the serialization discussion you had before... I was doing some research about what can be adapted in epee::serialization for the json structures to use rapidjson.

I have also seen a PR by vtnerd which replaces the rapidjson streams with a byte stream class for zmq which could be used there too.

The main idea is to keep the current abstraction improving the json serialization speed and code maintainability, which is quite hard to read right now, with a well known and maintained library as rapidjson.

There were some discussions in the past about doing this but I'd like to ask just in case before actually getting into it, could we want this?

BTW the main benefits of doing so are here github.com/bertptrs/json-speedtest

I'm not buying the maintenability argument. It'll just be other problems. I don't like big changes just because someone prefers another lib. IIRC the speed tests did demonstrate a good advantage to switching though.

(and to build time)

So if someome were to do this and the claimed gains were confirmed, I'd be fine with the change. Though I'd prefer if the author tried to keep the diffs contained if possible.

Hey, an unexpected mention. I think someone suggested a "bastard child of epee and rapidjson" to keep the diff down when I showed this? I never got around to implementing it unfortunately

I do recall something like this.

Sounds like a plan

hyc, vtnerd: any idea about the last comment in monero-project/monero #6454 ?

I don't see what's undefined.

looking

unsigned long compared to unsigned long? wtf is wrong with that? I think the tool is broken

what's different in bytecoin's keccak.c ?

IIRC I added the aligned test at some point.

There's probably something clever going on I can't see.

Oh.

Wait, no.

I was thinking alignment, but the pointer would have the right alignment in memory would it.

the address of the pointer, vs what it points to?

Yes.

What it points to is not necessarily aligned (thus the test).

yah, compiler would ensure the pointer itself is aligned

and nobody is taking the address of the pointer there

Could there be a compiler with 32 bit pointers and 64 bit unsigned long ?

mm, yes possible

Yeah, doesn't matter, even if the pointer was aligned on 32 bit only, the compiler should memcpy properly to use as uint64_t.

that's the x64 model actually. 64bit registers but only 32bit address space

Sounds like a waste. You need large pointers before large ints usually.

And then you can use long long if you do.

I guess it's for some number crunchers, dunno who really uses it

that's not the situation here

not a real problem on our platforms

#define IS_ALIGNED_64(p) (0 == (7 & ((const char*)(p) - (const char*)0)))

that's exactly the situation here

or no

IIRC, pedantically doing this subtraction is undefined to cater for segmented archs.

Segmented or otherwise machines with different types of memory.

why is that test not just (!(p & 7)) ?

so technically the current macro is UB

Feels more polite to cast pointer to integer first :)

fair enough

anyway, casting to uintptr_t is legal, and taking anyt int & 7 is legal

so I think the tool is broken

sech1's link says "any other arithmetic". Though that's not a standard quote.

bitops aren't arithmetic

So I guess &7 would be arithmetic. Is bit twiddling considered... ok.

even so, you're doing &7 of a uint, not a pointer

I don't see anything wrong with #define IS_ALIGNED_64(p) ((((uintptr_t)p) & 7) == 0)

it should be correct everywhere

Maybe some archs have ints so small 7 is off the range ^_^

I think that tool is broken: "warning: The following sub-expression cannot be evaluated:" hence the error later

agreed. if it can't evaluate a subexp (unsigned long)x & (unsigned long 7) it's braindead

I think they should report this to the tool maker

not us

I suspect it's not that dumb, and the messages may be non obvious.

then report to the toolmaker that their diagnostic messages suck

Like, it can't because of a constraint somewhere that it's not mentioning.

Fair.

none of this source line numbers correspond to our source

s/this/his/

of course, the other option is to make compiling the wallet optional.

if wallet2.h is only used when creating monero-wallet-cli .

just making up a random statistic, but i'd bet 80% of the time, a developer compiling monero is optimizing/hacking something in the daemon

but then again its me, and for all i know wallet2.h is used when compiling the daemon because logic.

for the record, this is regarding the compile time reduction ccs / effort

You can already compile just the daemon, that's what I do.

(and deps)

right, but something something defaults

something something

hell thats probably a makefile mod, right? i bet even i could figure that out

Yes. Two lines. Including a blank one.

we'll see. i surprise myself with how incompetent i am sometimes

Actually, I was thinking of "all:\n\n", and you'd have to do make -C build/release daemon wallet otherstuff, but that can't work since you have to run cmake anyway.

who needs enemies when you have your inner voice

I usuallu just cd src/daemon and then do a bunch of makes from there

Has the `test-ubuntu` CI action been disabled/removed?

It doesn't appear in a recent commit/push I did on a branch

no

it just starts once the build-ubuntu one is finished

so it will look invisible at first

Heh, so I've clearly missed that _the entire time_

=p

we could start it from the beginning, not sure if that would be preferred

Yup, just appeared now that `build-ubuntu` completed :)