yay viewtags visible now: testnet.xmrchain.net/tx/7d75c250f7d…5b981ffeb85c3ae647d876d8b4e8ec0f6a2

gingeropolous: cool :) jberman and I leaving our mark on the ledger

That's awesome !

Do we know who runs xmrchain.net ?

The web/admins name of xmrchain beings with g and rhymes with gingeropolous , he will know xd

haha gingeropolous thanks

I use that site all the time

Is there anything keeping UkoeHB's new Seraphis proposal from moving to funding required? repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/314

djh

<jeffro256[m]> "@ooo123ooo1234 I guess we have..." <- "en.cppreference.com/w/cpp/io/c/setvbuf#Example", So "Uses the system-defined buffer size instead of a hardcoded 4096 value" is literally gratuitous change

"Possible output: BUFSIZ is 8192, but optimal block size is 65536"

<jeffro256[m]> "I probably won't be able to..." <- All changes except those 9 lines are noise since it just adds overhead between openssl api and thing wrapper in c++

And this overhead makes verification harder without any benefits

The final goal determines what is important and what is not, and if you are not approaching it then you're just adding useless overhead

which in the best case will be fixed others, and in the worst case will lead to vulnerability

Full code is complex graph which you don't want to study. And your changes is like doing bit flipping of few edges/vertices without taking into consideration relevant scope.

Context free canges

hahaha

So instead of changing 1 edge to swap SHA256 for EVP_, you've decided to add new entity

and say that it helps

interesting theory

<UkoeHB> "need a new fundamental concept..." <- Fundamental concept is to approach common goal without compromises and with critical thinking.

I thought that correct cryptography is the most uncontroversial goal. If it would be true then at least code that isn't proven to be correct couldn't be merged.

But it isn't true

In all my previous attempts to deduce goal from the context and attack it fails. I suppose it's time to set goal explicitly

s/In//, s/fails/failed/

Can’t create view wallet on testnet: monero-project/monero #8339

You say "on testnet" but the command line specifically omits --testnet. Is there a reason ?

Shoot you’re right

My bad

rhetorical question: how many bits of security does monero protocol have ?

any guesses ?

That question doesn't make much sense. Also, read Zero to Monero

It was just a forgotten flag on the command line.

<merope> "That question doesn't make..." <- Definition from here en.wikipedia.org/wiki/Security_level. Have you already read Z2M ?

To be precise, monero transaction protocol (the thing on top of pow)

I know what security level means. I'm telling you that you can't blindly apply that definition to "the transaction protocol" as a whole, because it is composed of multiple parts - not all of which rely on bits of security. Therefore, go read ZtM2 and look up the security levels of the cryptographic primitives involved

merope: Which part doesn't rely on bits of security ?

Try to call at least 1

merope: No, you don't know.

The number of ring members in a ring signature, for example

Additionally, different parts of the protocol rely on different primitives, so they will have different security levels against different types of attacks

Something you would know, if you bothered doing your own reading instead of demanding to be spoonfed

Do your homework

merope: Number of ring signatures is a parameter of cryptography. It isn't a component. Ring signature is a component.

s/signatures/members/

merope: Call at least 2 different primitives

This isn't highschool, and you are not a teacher

merope: critical thinking can be used outside of highschool too

merope: What would the goal of that homework ? How to verify that it was reached ? Have you done it already ?

* What would be the goal

Oh look - a shiny ignore button!

merope: as expected

merope: can't answer question -> can't call a troll -> use ignore button

<merope> "That question doesn't make..." <- I would read something like this reddit.com/r/AskEngineers/comments/…mpetent_is_ruining_my_topperforming. More revelant in current context.

s/a_lazy_incompetent_is_ruining_my_topperforming/a\_lazy\_incompetent\_is\_ruining\_my\_topperforming/, s/revelant/relevant/

ooo123ooo1234[m]: it’s supposed to be ~128 bit. Did you find something that makes it less?

UkoeHB: can't comment

So you guess is 128, ok

s/you/your/

Why can’t you comment?

What's the precision interval for ~128 ? +-1 ?

Hmm my ballpark would be within 10bits or less

<jeffro256[m]> "Is there anything keeping UkoeHB..." <- I would not do so detailed c++ reference implementation without checking security of cryptography.

ooo123ooo1234[m]: most of the code is not dependent on unproven cryptography (can be fixed if/when a problem is found with probably <10hr work)

UkoeHB: hmm, I think it's possible to find at least 1 example that is very dependent

are you really sure ?

it's literally minimum wrapper on top cryptography

Are you saying ed25519 is unproven? Lol

UkoeHB: ed25519 -> transaction protocol of seraphis -> seraphis lib

I'm about "transaction protocol of seraphis" part

Nah, thanks to good code quality it’s very easy to replace any proof or even the entire squashed enote model.

But that’s a bit too big brain I guess

Let me know if you find an unproven piece that is really so critical though. I won’t hold my breath

<UkoeHB> "Let me know if you find an..." <- In case of cryptography there is presumption of unproven by default, so it must be proven firstly.

<UkoeHB> "Nah, thanks to good code quality..." <- It would be true if proofs can be combined in arbitrary but still secure way

<UkoeHB> "Nah, thanks to good code quality..." <- In general it isn't true. But if your assumptions hold then you're right.

ooo123ooo1234[m]: man I am so tired of you typing words but saying nothing; let me know when you have something to contribute and are done with this bs negotiation charade

<UkoeHB> "ooo123ooo1234: man I am so tired..." <- "bs negotiation charade" every meeting without critical questions looks like this for me

and from spectator point of view it looks like everyone is enjoying participating or pretending that enjoying

ooo123ooo1234 Have you ever contributed code to Monero?

jeffro256[m]: And then gratuitous patches will be used as justification to get badge of monero contributor

typical octorberfest particpant

Maybe that SHA256 patch is "gratuituous", but you're avoiding the question. For someone who hasn't contributed at all, you seem to be ready to argue with anyone about anything on here, not just myself. Why don't you channel some of that energy into something more productive?

<jeffro256[m]> "ooo123ooo1234 Have you ever..." <- "who hasn't contributed at all" or contributed, how did you check ?

jeffro256[m]: I've mentioned problem in current game design that can't be fixed with patch to github

or few problems

jeffro256[m]: I don't talk in DM, don't even try

ooo123ooo1234[m]: ‘critical questions’ pretty rich coming from someone who thinks he is too important to answer questions. Nice double standard

I just discovery an "ignore" button on ooo123ooo1234 profile :D

<UkoeHB> "ooo123ooo1234: ‘critical..." <- Important critical questions. Since there is no common goal or at least it isn't announced explicitly then it's possible to treat any question as not important to answer.

This kind of thing isn't possible in proper competition

Or unimportant critical questions should be penalized

s/discovery/discovered/

<jeffro256[m]> "Maybe that SHA256 patch is "..." <- probably with anyone but not about anything

* <del>probably with, * about anything</del> only anything related to monero development

The amount of effort that went into arguing here is 10x more than needed to review the SHA256 patch from top to bottom. Someone just likes to steal devs time.

sech1: It was balanced with 9 lines patch. And the whole talk was about bigger problem related to many such PRs, not just that one. So you're not right

I am right and you're not right

sech1: explain then

The patch does the needed change and also improves code structure. I don't see any problem with this. Your approach will eventually lead to "hack on top of hack on top of hack on top hack" code

that will need full rewrite

sech1: No. Do you want an example of patch that you would ignore in xmrig or p2pool ?

just because of you don't some changes that are needed since you know code better

* you don't want some changes

the principle of "just fix one thing and don't touch anything else" is sound software engineering. time-tested. used by all large software projects.

"I'm changing this because it's easier for me to read" isn't really a good argument against it.

ooo123ooo1234[m]: It's a matter of basic decency. Oh look, my 'putting up with indecent behavior' meter ran out. Guess you'll need a new account if you want me to read your messages.

I personally wouldn't do this patch the way it was done, I would reduce the changes to the minimum. But I'm totally ok if someone else did tidy up the code in the process.

The patch is not huge and can be reviewed in one go

Bigger refactorings without purpose are no go, but this is below the "no" threshold

sech1: ok, I'm glad you at least take this into consideration and have a threshold in mind

it doesn't sound to me like many others do

sech1: As long as those who are doing bigger changes have capacity. But there are already few examples where you ignore something in xmrig / p2pool

I still personally believe shuffling files and requiring a new header file to be included by multiple source files is out of scope for what the issue was meant to fix.

I mean seriously. it's like saying "hey, this square root function needs to be fixed" and requiring a dozen other files to be updated due to the fix.

I don't merge patches in xmrig. As for p2pool, there are very few examples, you can count them by fingers on one hand. It's either totally broken patches (doesn't compile) or it does something unnecessary. Either way, I comment there and write what's wrong with the patch.

<sech1> "I don't merge patches in xmrig..." <- There are some ignored issues in p2pool, but 0 ignored PRs. And p2pool is mostly solo project at the moment. But for xmrig which isn't your solo project you ignore almost all PRs since they don't help to achieve the goal (performance optimization). It depends on the goal of project / capacity of developers.

sech1 isn't lead dev on xmrig

you seem to be dragging up a bunch of stuff beyond the scope of this conversation now

p2pool issues are not ignored, they're in my backlog :P

hyc: I've tried to bring some context familiar for sech1. If it isn't true then I can stop.

> <@hyc:libera.chat> you seem to be dragging up a bunch of stuff beyond the scope of this conversation now

* I've tried to bring some context familiar for sech1. If it isn't a cache miss then I can stop.

* I've tried to bring some context familiar for sech1. If it is a cache miss then I can stop.

Do you know that all your edits just spam the IRC side?

the main point remains the same: if it ain't broke don't fix it. only touch what is absolutely needed to fix an issue, and nothing more.

p2pool.io/u/b75c6e38f4846678/spam.png

doing anything else - reformatting, restructuring, only adds the risk of introducing new bugs.

for this SHA256 issue the patch is simple enough that we can see it doesn't introduce new bugs. but at the same time, the issue is simple enough that the patch ought to be much much smaller.

the only time any refactoring is justified is when needed to add new features

I want to guage the general sentiment of the SHA256 PR because this is taking up too much bandwidth: monero-project/monero #8322#issuecomment-1129118658. If it's generally negative, I'll close it

hyc: +1. If this project would be about some simple like piping data from left to right with simple processing then it would be ok to allow arbitrary changes.

hyc: +1

jeffro256[m]: you understand that the patch is only an example at this point, highlighting the overal issue, development best practices.

jeffro256[m]: sentiment

it isn't about emotions, but about really problems that will come with it

* it isn't about emotions, but about real problems that comes with that kind of changes

sech1: Yes, but IRC isn't compatible with tor.

It is. Currently connected via Tor right now.

I think up until recently it was tacitly understood by developers. Now I believe it needs to be explicitly stated.

hyc: +1, 4 years ago I thought the same

> <@hyc:libera.chat> I think up until recently it was tacitly understood by developers. Now I believe it needs to be explicitly stated.

* +1, 4 years ago it was more obvious

since moneromooo was maintaining it vocally

4 years ago I hated it but it looks like it's really necessary

Epsilon: How did you register your account ?

ooo123ooo1234[m]: I just followed the guide on Libera's website libera.chat/guides/connect worked for me back when Libera launched.

Epsilon: registration is prohibited for proxy/tor/anonymous connections

if you used your real ip then your tor connection is useless since you've already leaked your location

ooo123ooo1234[m]: I don't remember exactly what I did but iirc I just constantly tried reconnecting with different exit nodes or I used a VPN Its been a while

Epsilon: VPN means you leaked your destination too

anyway matrix account setup is easier to do and there is no problems for tor users

s/problems/problem/

selsta: thanks for your commentary on #8322 that sums it up pretty well.

<UkoeHB> "ooo123ooo1234: It's a matter..." <- It looks like decency about being conformist within social environment. It isn't compatible with solving hard technical problems.

sometimes pretty evil things are treated as moral

ooo123ooo1234[m]: I am a sucker and checked the logs. I guarantee you'll never accomplish anything when no one wants to work with you. Is this the CLSAG issue you've been alluding to? I swear to god reading tea leaves is a mind-boggling waste of time and energy. usercontent.irccloud-cdn.com/file/t…ijsixQU/0001-clsag-patch-demo.patch

This will never get merged without a concrete proof or argument.

I don't understand what this patch does

sech1: there is some material missing from hashes in the clsag implementation (an oversight)

I see that it adds something to the hash inputs. But the reasoning?

although 'oversight' may be an overstatement; more like 'it could be a little bit more robust'

the reasoning is mostly paranoia, unless mr annoying as hell has a concrete proof

mr annoying as hell has implied there is an issue with clsag, and this is all I could find; if that's the issue, it's up to him to prove it's worth a hf to fix

is the bridge down?

irc side?

no

or not sure, I'm only on irc

irc msgs not showing up on matrix

<koe000[m]> "is the bridge down?" <- My first assumption was that someone banned me from monero-dev.

hahahaha

<koe000[m]> "is the bridge down?" <- #monero-dev:libera.chat doesn't work at the moment

<UkoeHB> "ooo123ooo1234: I am a sucker and..." <- It could be used as a submission for competition.

<UkoeHB> "ooo123ooo1234: I am a sucker and..." <- Do you really believe that I'll waste someone time with something trivial ?

and unimportant

"I guarantee you'll never accomplish anything when no one wants to work with you." I don't know any way to motivate people to not stick with path of least resistance

"I swear to god reading tea leaves is a mind-boggling waste of time and energy." If there would be at least one rule that I could use as justification that my work is hard and worth something

then i would talk somehow differently

<UkoeHB> "ooo123ooo1234: I am a sucker and..." <- You said it monero-research-lab that some pushback helped to do something. Is this patch a result of pushback from my side too ? Was it written solely by you ?

s/it/in/

looks like 8149 needs review again? got a lot going (haven't bailed, promise), working on carving out some time shortly on that

vtnerd_: yeah that would be awesome

hyc: that should be the final version of the patch now, if you can take one last look monero-project/monero #8340

selsta: just 1 trivial change. otherwise looks ok

hyc: done

looks good