Hello. Today's merge day for 0.17, right? Any chance of #8149 getting in?

<jeffro256[m]> "I probably won't be able to..." <- There is no such thing as "make it easier to grok". You're just doing this en.wikipedia.org/wiki/Spaghetti_code#Ravioli_code. If you don't want to spend time on code reading then submit github issues - this is a way to contribute for people that know only English

hyc, look what could be achieved if someone wouldn't do gratuitous changes: paste.debian.net/hidden/74158896

Testnet has forked, but testnet.xmrchain.net seems to be not updated

Or it's running some older version of master which is not compatible

<jeffro256[m]> "I probably won't be able to..." <- Which one is easier to grok according to your subjective opinion: monero-project/monero #8322 vs paste.debian.net/hidden/74158896 ?; Which is easier to verify ?

Which one is wasting less time of reader/verifier ?

And are there any other reason to do this kind of useful changes in for-profit company other than salary ?

"useful"

10:27 <sech1> Testnet has forked, but testnet.xmrchain.net seems to be not updated <-- ping gingeropolous

ooo123ooo1234[m]: yes, that's the kind of patch we should be seeing

sech1, "No, it won't leak. ctx is an std::unique_ptr instance which will call evp_md_ctx_freer in destructor." this comment was for another context without std::unique_ptr and it wasn't removed by github

* sech1, "No, it won't leak. ctx is an std::unique\_ptr instance which will call evp\_md\_ctx\_freer in destructor." this comment was for another context without std::unique\_ptr and it wasn't marked as outdated by github

the comment was from only 16 hours ago and not marked outdated, so...

sech1: so github ui is lying

or it isn't competent enough to detect outdated comments

it probably outdates comments only if 1-2 lines of code above them changed

sech1: priority list for constructive way of criticism: ignore it if it isn't critical < do it yourself < suggest improvement easily understandble by original author < talk with original author

sorted from the easiest to hardest

what is the reason to talk about under PR instead of submitting superior patch ?

ooo123ooo1234[m]: not sure about naming for this order, but talking would be the last thing that I would try to do since it's the least ineficcient way to achieve the goal

sech1: which height is your testnet node?

currently at 1982829

ok, same

<UkoeHB> "ooo123ooo1234: the purpose of..." <- If there would be competition for code that fixes everything related to multisignature. How much % of reward would you dedicated to overlay with comments ?

s/dedicated/dedicate/

In current environment it doesn't really matter what the code is, what the comments are since everything will be merged

it's probably even possible to replace prove() verify() with static stubs {return true} and no one will complain

since everyone is reading comments / docs / social media posts, but not code or math

hyc, do you know how deeply linux kernel maintainer tries to verify merged commits ?

or it's mostly blind merges too

<selsta> "sech1: which height is your..." <- Are y'all just running on master ATM?

yes

OK will get mine over onto master today unless a branch is imminent

Height: 1982872/1982872 (100.0%) on testnet

Nodes up on master at node.sethforprivacy.com:28080 and node2.sethforprivacy.com:28080, ready for fork 🙂

ooo123ooo1234[m]: from what I've seen, many people test proposed patches

for device drivers, it can be tough to find people with the device in question

though it often works the other way too - many people have a device and want support for it

Anyone who wants to run it can use my Docker image to simplify things:... (full message at libera.ems.host/_matrix/media/r0/do…d04ffbb2e4ef80e149c2ab0cd35f0a000a9)

* Anyone who wants to run it can use my Docker image to simplify things:... (full message at libera.ems.host/_matrix/media/r0/do…dd89fb2054c69bfed002a1c59d945461776)

Paste for IRC users: paste.sethforprivacy.com/?ca1c40131…Q79LaS46PGioodPXHRW7EPqFxmbfgsL3s3y

I assume those three links point to the same content :P

Sorry, it's the weird Matrix > IRC translation for long messages.

I know, I found it amusing, is all.

If anyone needs any testnet funds let me know, I'm testnet rich 😄

Have never seen this before, trying to self-spend testnet funds: `Error: output key's originating block height shouldn't be higher than the blockchain height`

Nevermind, retrying worked properly. Not sure why that happened.

you probably connected to some v14 node that is stuck at lower height now

You probably tried to send a tx while your wallet isn't synced yet.

So a fake out was sent which is created later than what your wallet thinks the height is, and the wallet smells a rat.

sech1: I'm using my own synced node as trusted daemon, remotely.

moneromooo: Wallet was synced but possible a block came in while I was trying the transfer (lots of inputs so took a few seconds to build the TX)

I mean, your node connected to v14 node and got confused about blockchain height

Should not be that, since the wallet won't ask for anything within 10 blocks of the tip.

1982879/1982879 is correct, right?

sech1: Ah, that could be it.

Tested a large self-spend and confirmed properly (after that weirdness) testnet.xmrchain.net/search?value=d…c93c46165e26f15f0e09d4f3e7b569dc2c8

Oh, nvm, failed because I'm using an old cli wallet...

Have to build that still

thanks for the ping . currently getting the onion explore compiled.

That TX did actually go through, surprisingly. Was accidentally using v0.17.3.0 binaries

If testnet is done the same as mainnet, you have a day's worth of blocks to go through "old" txes.

huh, the tag isn't showing up.

If pulling, try: pull --tags

sorry. i meant on the testnet explorer on xmrchain. i wonder if theres a flag i need

do you mean view tag on the transaction page?

yeah like this testnet.xmrchain.net/tx/df65abcf4d8…c93c46165e26f15f0e09d4f3e7b569dc2c8

gingeropolous: I created that on old binaries so it won't have a view tag

ah

It's type 5

Here is a type 6: testnet.xmrchain.net/search?value=b…33450e1e5d41764a569466f1d51eaa074ac

Still don't see a tag but I may be missing it

now where are my testnet wallets....

2-in/2-out: testnet.xmrchain.net/search?value=f…8781ea1d1aba2f017f1709912f8ab663c4f

1-in/2-out: testnet.xmrchain.net/search?value=d…67cc7ca74e7507a9fcd7eed70f33d1a1e3a

Fees should be roughly analogous to mainnet post-fork, correct?

* Fees per kb should be

No, fee per kb depends on block reward and testnet has much higher block reward

~2.42 times higher

ooo123ooo1234 That patch doesn't do the same thing as my PR though?

Also I removed that wrapper class hours before you sent that message

<sech1> "No, fee per kb depends on..." <- OK, any easy way to estimate the fee per kb of a transaction on main-net post-fork?

Just trying to get an idea of the fee changes impact on common transaction fees in total XMR.

Do a transaction on testnet and divide the fee by 2.42

Oh didn't realize it was that simple 😛 Thanks

paste.sethforprivacy.com/?71931870c…VdbLWxBJ9pjvpFo39cfjXScf4kgQGKKwzjU, 0.5c for 1/2, 0.7c for 2/2

Thought fees were going up a lot more than they are!

ooo123ooo1234[m]: I’ll gladly do it for free

If it means someone other than me is doing the main work (like I have said before, I’d rather be working on Seraphis).

sethforprivacy: I think you calculated it wrong

I did what sech1 said

But seems too low

new: testnet.xmrchain.net/search?value=d…67cc7ca74e7507a9fcd7eed70f33d1a1e3a

old: testnet.xmrchain.net/tx/d7fddb6b95a…da272f124b3038e6b8e5f9744ad3e7661e7

5x difference, that's with two random 1in 2 out tx I found

(but i did not check priority level)

fee per byte will be 20000 piconero after the fork with block reward = 0.6 XMR

A "regular" prio level mainnet TX is 1/5 the fee per kb of my calculated fee per kb

you can calculate using this number and transaction size

Which matches what it should AFAICT

sech1: Yes, mine is 20733 piconero to be precise

But using 20000 will certainly simplify things 🙂

although, transactions with more than 1 input will have weight bigger than size in bytes, and the fee is calculated from transaction weight

Yeah, fee per kB is slightly larger in my 2-in/2-out TX

20735 pico

<jeffro256[m]> "ooo123ooo1234 That patch doesn't..." <- yeah, everything unneeded was removed

Revised numbers assuming 20000 pico as the mainnet fork will be post-tail-emission: paste.sethforprivacy.com/?3d536c40b…rLp7WKURUvT3KCTQjThFb1G7BAYhA5YnmDx

jeffro256: "2. Doesn't throw on file error, and can be used in noexcept contexts" noexcept is useless thing en.cppreference.com/w/cpp/language/noexcept_spec#Notes

"1. Logs what causes the errors at each step to help debug" or doesn't help due to additional noise

It's not "useless" because it describes to the reader how to use the function. That's the whole point

"3. Interface is documented" additional noise

"4. Logic is moved to aptly named file" also noise

And the logs would help in this particular case because the function can fail due to the openssl API or file I/O

now we are back again to yesterday's discussion

:D

"5. Changes how the file is buffered" preliminary performance optimization, noise too

"6. And added unit tests to test the file variant of sha256sum, as it didn't have a unit test previously" implementation is the same as previous one, so it's noise

@ooo123ooo1234 I guess we have exhaused both of our points here but feel free to DM me if you want to still talk

It's like those octoberfest patches but on regular basis

it's subjective what some find useful and others don't, obviously everyone will have their own opinion

jeffro256[m]: who is the target reader that is gonig to read it ?

jeffro256[m]: No. If you think that your changes are useful than I can prepare 100 such patches tomorrow

and 10 other people can prepare other noisy patches

is it really needed ?

jeffro256[m]: any other student even less knowledgeable than you can do the same

what's the purpose of this spam ?

c++ training on public repo ?

ooo123ooo1234[m]: Also, I don’t see how competition is a viable strategy for development. It sounds like wasting resources writing code that’s known in advance to be unusable (ie everyone except first place). Better to try to find the right person for the job, and then they go do it. If a re-do is necessary, at least it will only be done when actually necessary (much more efficient).

UkoeHB: Any further submission should iterate of previous ones: verify whether available submissions reach the goal - if yes then work is done, if not then submit patch with further changes

and reward must be split between all participants according to added value

But the goal of competition should be defined before the beginning

How is that a competition? Lol that’s more-or-less the normal review process.

UkoeHB: Competition has rules, concrete goal, reward and rules can't be abused by participants

I don't know how would someone define competition for the cleanest code, but It's possible to define competition for the most correct code

within available time limits, reward and other constraints

Competitions do contain rules and rewards, but the main component is some kind of parallel goal-seeking (not serial).

UkoeHB: private part can be parallel, but public one must will be serial

However, I at least comprehend why this approach would be valuable to you.

UkoeHB: hahaha

ooo123ooo1234[m]: do you have an example of a rules/rewards structure that makes sense?

<UkoeHB> "ooo123ooo1234: do you have an..." <- There are few goals / important problems that are not solved now and there are few competitions that can be used a reference.

The dumbest reference example known to me is to detect vulnerability and exploit it

if people on the other side are competent then I will lose, if not then I will win

But it isn't zero sum game for me in any case since I always approach complex problems. If I'm not competent then I learn something. If I'm then I get full reward

hahaha

and I don't cheat when I'm trying to solve problem

<UkoeHB> "ooo123ooo1234: do you have an..." <- It starts from goal, not from rules or reward. It's better to start from something that is easy to verify: like math statement and it's prove

in case of multisig it's implementation + idealized math model of it + prove within idealized model that it isn't exploitable

s/prove/proof/

reward structure must be dynamic since it isn't unclear how final solution will be decomposed into work of participants

and rules must be strict to avoid any abuse

I'm sure that even first approximation of this setup will be much better than current environment

In current environment there is no incentive for proper review, goal of work can be changed during review by reviewer at will

or by submitter at will

ooo123ooo1234[m]: The reason I ask for an example is I don’t know how to write such a goal/rule/reward structure, and idk anyone who does. It’s not an area I have skill or enthusiasm in. I just want to get work done and think about new technical ideas... (pretty much ran out of those at this point for Monero - after years of thinking about the same stuff).

UkoeHB: It's impossible to get work done without understanding how to check result.

UkoeHB: decentralized protocol development is all about defining rules for untrusted parties that can't abused in arbitrary way

> <@UkoeHB:libera.chat> ooo123ooo1234: The reason I ask for an example is I don’t know how to write such a goal/rule/reward structure, and idk anyone who does. It’s not an area I have skill or enthusiasm in. I just want to get work done and think about new technical ideas... (pretty much ran out of those at this point for Monero - after years of thinking about the same stuff).

* decentralized protocol development is all about defining rules for untrusted parties that are hard to abuse in arbitrary way

It's also the main reason why people from regular jobs can't bring any value to monero development since they are used to centralized architecture where every failure is easy to fix and there would be no penalty

But centralized architecture is the path of least resistance forced by status quo and it's completely incompatible with monero goals

status quo = govt / ...

ooo123ooo1234[m]: I agree with you, however attaining that goal isn't necessarily straightforward. New perspectives and 'what ifs' can crop up regardless of what formal model has been designed (which mean updating the formal model). For example, the idea of a post-kex verification round for multisig that I recently had is, as far as I know, addressing a new problem that no one considered before. Similarly with kayabaNerve 's

point about the danger of burning funds in multisig. That isn't to say formal models aren't useful or important, just that there is a dimension to protocol analysis that can't be formalized (the realm of 'imagination' I guess, which precedes and informs formalization). Another way of saying it is - formal models encapsulate all the problems that have already been imagined (the process of formalization can also identify new

problems). This implies two issues. 1) knowing the existing best formal model isn't required to imagine new problems (anyone can do protocol analysis and potentially contribute something). 2) learning the existing best formal model requires collecting ideas that may be hidden or difficult to locate (finding any single person who knows the entire existing best formal model is non-trivial, especially for new/complex systems;

hence, collecting a venn-diagram of analysts can be useful or even essential).

UkoeHB: No. The thing found by kaybaNerve is detectable within idealized model too.

<UkoeHB> "problems). This implies two..." <- There are very few approaches for modelling. Most of the work is to describe concrete protocol within it and then analyse it.

I don't like academic papers written by many people with a lot of noise, when the key points are very minimal

Can't disagree with that

^ noise

So people intentionally chose the path to be incorporated into academic hierarchy and then write nonsense, since it's just status quo

For the purpose of monero development there is no need to waste time on that front door polishing or simulation of hard work for a grant

ooo123ooo1234[m]: > Most of the work is to describe concrete protocol within it and then analyse it.

Yes, it is a lot of work that requires a lot of expertise. Unfortunately, people who are able and interesting in doing that work are few and far between (and won't materialize out of thin air). I have done the best I can, and use my energy to be as productive as possible within my skillset, but there's no question what I have done/do is sufficient for a final answer on anything.

able and interested*

UkoeHB: hehe, somehow it was possible to achieve

The testnet part of my web wallet is running already on v15, maybe it's useful for somebody for tests: monerotech.info/Wallet

Also the explorer: explorer.monerotech.info:6001

just did a sweep_all on one of my p2pool test wallets: testnet.xmrchain.net/block/1983000

Although that one does not show view tags, which I find a little strange. I thought I was compiling the latest source yesterday

<UkoeHB> "Yes, it is a lot of work that..." <- "are few and far" and who are these people ?

if there is at least two such candidates then it's possible to do competition between them

s/is/are/

s/is/are/, s/at/atleast/, s/least//

<UkoeHB> "Yes, it is a lot of work that..." <- "en.wikipedia.org/wiki/Influence_peddling" current environment creates incentive for this and it's obviously doesn't lead to more people interested to compete in solving hard problems

quite the opposite: easiest problem are the most profitable

hahahahaha

s/problem/problems/

s/Influence_peddling/Influence\_peddling/, s/'s//

game design is broken a bit

it deends: if this project is for status quo then everything is ok, if this project is going to change something then not ok

s/deends/depends/

ooo123ooo1234[m]: at the moment, in this project, among those who are vocal, it might be just you (there may be some guys with a less advanced level of skill). AFAIK the guys at Firo and possible ZCash also have at least one person with that capability (or at least inclination). However, you are VERY unlikely to find someone who has the qualifications you want and is also interested in a competition. The probability seems

infinitesimal.

UkoeHB: This competition is compatible with anonymity of participants, so that means anyone who can find something can participate

if there is some critical thing which cracks everything then this is a chance to get full reward

very strong incentive to participate for anyone competent

and incompetent people after few iterations can learn how to do it and participate too

all submissions must be public

I doubt that no one will try to compete with me for proper reward

People participates in programming contests just for the respect

The first step would be finding someone else who is enthusiastic about a competition. To set up a competition, you need enthusiasts. I am not that person - all the stuff I do is voluntary and public and self-motivated.

Includes p2pool sweep example numbers: paste.sethforprivacy.com/?3a142735d…D6MQpvbE82G2cocVZiUNXMULZv8YjaFSqh8

.merges

<UkoeHB> "The first step would be finding..." <- That's about obstacle to setup competition, but do you mean that you're not interested to participate even if the problem to solve is directly related to what you're doing right now ?

ooo123ooo1234[m]: what new thing would I be doing in this competition? If there is something I can do right now, then I'll do it (unless the task is becoming an expert at security proofs/modeling - I have tried to get into that stuff and could not muster enough enthusiasm).

Or if there is something more for me to do, I'll put it on my todo list.

UkoeHB: In the worst case learning something new from reading submissions. In the best do something like this: github.com/UkoeHB/break-dual-target-dl or anything else

Sure, both of those things I'm happy to help with. Just let me know where and how I can help.

As you said it's close to review process, but with better focus and incentive for participants

The question is whether it's possible to incorporate it into current game design, otherwise it would like creating mining pool for few MH/s of hashrate, when others are mining at minexmr

* it would be like creating

It's certainly possible to add into new project, but it means that current one should die

* to add it into new

p2pool can't compete with minexmr even with full support / money burning from xmrvsbeast owner

In general the way to fix or destroy something is the same, both need required good knowledge about weaknesses.

* In general the way to fix or destroy something is the same, both just need extreme knowledge about weaknesses.

From what I can tell, any kind of centralization in the core concept of a project will make it hard to succeed. These include tech-centric projects ('our tech is the best, use us'), company-centric and team-centric projects (monero is in the odd position of having a very custodial core team). Starting a new project to tweak something about a previous project doesn't work (often, new projects just create new centralizations). You

need a new fundamental concept that people can get attached to. Tech, management, roles, strategies, and 'memes' are only reflections and embodiments of the project's core concepts (the tech/etc. is what we do, because that's who we are). From this human perspective (which may be annoying, but is critical), what can you do? Encourage people to be better people, to have better ideas, to do things in more effective ways. Hard to

do, but there aren't a lot of real alternatives.

It just so happens that monero is rather haphazard (due to lack of centrally mandated direction), so what we need to improve is less haphazard protocol and code work (or at least tighten merge requirements).

A lot of this is off-topic though, better suited for #monero-research-lounge or something.

UkoeHB: it's about relax, so lounge isn't suitable

hahaha

* it's not about relax,

Need help opening up