07:21:20 <arnuschk1> Hello. Today's merge day for 0.17, right? Any chance of #8149 getting in?
08:06:28 <ooo123ooo1234[m]> <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 https://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
08:08:08 <ooo123ooo1234[m]> hyc, look what could be achieved if someone wouldn't do gratuitous changes: https://paste.debian.net/hidden/74158896/
08:27:07 <sech1> Testnet has forked, but https://testnet.xmrchain.net/ seems to be not updated
08:27:20 <sech1> Or it's running some older version of master which is not compatible
08:40:55 <ooo123ooo1234[m]> <jeffro256[m]> "I probably won't be able to..." <- Which one is easier to grok according to your subjective opinion: https://github.com/monero-project/monero/pull/8322 vs https://paste.debian.net/hidden/74158896/ ?; Which is easier to verify ?
08:41:36 <ooo123ooo1234[m]> Which one is wasting less time of reader/verifier ?
08:47:13 <ooo123ooo1234[m]> And are there any other reason to do this kind of useful changes in for-profit company other than salary ?
08:47:18 <ooo123ooo1234[m]> "useful"
09:46:37 <selsta> 10:27 <sech1> Testnet has forked, but https://testnet.xmrchain.net/ seems to be not updated <-- ping gingeropolous
09:54:15 <hyc> ooo123ooo1234[m]: yes, that's the kind of patch we should be seeing
09:57:29 <ooo123ooo1234[m]> 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
09:57:43 <ooo123ooo1234[m]>  * 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
09:59:41 <sech1> the comment was from only 16 hours ago and not marked outdated, so...
10:00:28 <ooo123ooo1234[m]> sech1: so github ui is lying
10:02:05 <ooo123ooo1234[m]> or it isn't competent enough to detect outdated comments
10:06:55 <sech1> it probably outdates comments only if 1-2 lines of code above them changed
10:11:10 <ooo123ooo1234[m]> 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
10:11:28 <ooo123ooo1234[m]> sorted from the easiest to hardest 
10:12:05 <ooo123ooo1234[m]> what is the reason to talk about under PR instead of submitting superior patch ?
10:13:12 <ooo123ooo1234[m]> 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
10:17:26 <selsta> sech1: which height is your testnet node?
10:17:46 <sech1> currently at 1982829
10:17:55 <selsta> ok, same
11:03:14 <ooo123ooo1234[m]> <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 ?
11:03:37 <ooo123ooo1234[m]> s/dedicated/dedicate/
11:33:15 <ooo123ooo1234[m]> In current environment it doesn't really matter what the code is, what the comments are since everything will be merged
11:33:46 <ooo123ooo1234[m]> it's probably even possible to replace prove() verify() with static stubs {return true} and no one will complain
11:34:46 <ooo123ooo1234[m]> since everyone is reading comments / docs / social media posts, but not code or math
11:45:03 <ooo123ooo1234[m]> hyc, do you know how deeply linux kernel maintainer tries to verify merged commits ?
11:45:20 <ooo123ooo1234[m]> or it's mostly blind merges too
12:10:23 <sethforprivacy> <selsta> "sech1: which height is your..." <- Are y'all just running on master ATM?
12:10:48 <selsta> yes
12:11:48 <sethforprivacy> OK will get mine over onto master today unless a branch is imminent
12:29:33 <sethforprivacy> Height: 1982872/1982872 (100.0%) on testnet
12:31:15 <sethforprivacy> Nodes up on master at node.sethforprivacy.com:28080 and node2.sethforprivacy.com:28080, ready for fork 🙂
12:31:29 <hyc> ooo123ooo1234[m]: from what I've seen, many people test proposed patches
12:31:44 <hyc> for device drivers,  it can be tough to find people with the device in question
12:32:20 <hyc> though it often works the other way too - many people have a device and want support for it
12:33:38 <sethforprivacy> Anyone who wants to run it can use my Docker image to simplify things:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/83981d04ffbb2e4ef80e149c2ab0cd35f0a000a9)
12:34:05 <sethforprivacy>  * Anyone who wants to run it can use my Docker image to simplify things:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/7795add89fb2054c69bfed002a1c59d945461776)
12:34:28 <sethforprivacy> Paste for IRC users: https://paste.sethforprivacy.com/?ca1c40131798a97e#6fqTZ23QcQ79LaS46PGioodPXHRW7EPqFxmbfgsL3s3y
12:35:18 <moneromooo> I assume those three links point to the same content :P
12:36:55 <sethforprivacy> Sorry, it's the weird Matrix > IRC translation for long messages.
12:37:57 <moneromooo> I know, I found it amusing, is all.
12:44:11 <sethforprivacy> If anyone needs any testnet funds let me know, I'm testnet rich 😄
12:47:50 <sethforprivacy> 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`
12:48:25 <sethforprivacy> Nevermind, retrying worked properly. Not sure why that happened.
12:49:39 <sech1> you probably connected to some v14 node that is stuck at lower height now
12:49:56 <moneromooo> You probably tried to send a tx while your wallet isn't synced yet.
12:50:22 <moneromooo> So a fake out was sent which is created later than what your wallet thinks the height is, and the wallet smells a rat.
12:53:05 <sethforprivacy> sech1: I'm using my own synced node as trusted daemon, remotely.
12:53:26 <sethforprivacy> 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)
12:53:55 <sech1> I mean, your node connected to v14 node and got confused about blockchain height
12:54:01 <moneromooo> Should not be that, since the wallet won't ask for anything within 10 blocks of the tip.
12:55:22 <sethforprivacy> 1982879/1982879 is correct, right?
12:55:32 <sethforprivacy> sech1: Ah, that could be it.
12:57:06 <sethforprivacy> Tested a large self-spend and confirmed properly (after that weirdness) https://testnet.xmrchain.net/search?value=df65abcf4d82985598a6d11bbc9e7c93c46165e26f15f0e09d4f3e7b569dc2c8
12:57:44 <sethforprivacy> Oh, nvm, failed because I'm using an old cli wallet...
12:57:45 <sethforprivacy> Have to build that still
13:22:47 <gingeropolous> thanks for the ping . currently getting the onion explore compiled. 
13:25:57 <sethforprivacy> That TX did actually go through, surprisingly. Was accidentally using v0.17.3.0 binaries
13:27:08 <moneromooo> If testnet is done the same as mainnet, you have a day's worth of blocks to go through "old" txes.
13:32:21 <gingeropolous> huh, the tag isn't showing up. 
13:32:52 <moneromooo> If pulling, try: pull --tags
13:33:24 <gingeropolous> sorry. i meant on the testnet explorer on xmrchain. i wonder if theres a flag i need
13:34:22 <sech1> do you mean view tag on the transaction page?
13:36:21 <gingeropolous> yeah like this https://testnet.xmrchain.net/tx/df65abcf4d82985598a6d11bbc9e7c93c46165e26f15f0e09d4f3e7b569dc2c8
13:36:49 <sethforprivacy> gingeropolous: I created that on old binaries so it won't have a view tag
13:36:57 <gingeropolous> ah
13:37:03 <sethforprivacy> It's type 5
13:37:06 <sethforprivacy> Here is a type 6: https://testnet.xmrchain.net/search?value=bf36a2bd2bf07d88cf02cabb12b5e33450e1e5d41764a569466f1d51eaa074ac
13:37:36 <sethforprivacy> Still don't see a tag but I may be missing it
13:41:29 <gingeropolous> now where are my testnet wallets....
14:18:15 <sethforprivacy> 2-in/2-out: https://testnet.xmrchain.net/search?value=fb23e0372851e3a1e51cf9d8c37d28781ea1d1aba2f017f1709912f8ab663c4f
14:18:39 <sethforprivacy> 1-in/2-out: https://testnet.xmrchain.net/search?value=d888c27320ebd128325055d61ea4567cc7ca74e7507a9fcd7eed70f33d1a1e3a
14:19:18 <sethforprivacy> Fees should be roughly analogous to mainnet post-fork, correct?
14:25:29 <sethforprivacy> * Fees per kb should be
14:27:22 <sech1> No, fee per kb depends on block reward and testnet has much higher block reward
14:28:01 <sech1> ~2.42 times higher
14:41:31 <jeffro256[m]> ooo123ooo1234 That patch doesn't do the same thing as my PR though?
14:43:32 <jeffro256[m]> Also I removed that wrapper class hours before you sent that message
14:46:59 <sethforprivacy> <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?
14:47:15 <sethforprivacy> Just trying to get an idea of the fee changes impact on common transaction fees in total XMR.
14:49:39 <sech1> Do a transaction on testnet and divide the fee by 2.42
14:49:56 <sethforprivacy> Oh didn't realize it was that simple 😛 Thanks
14:53:28 <sethforprivacy> https://paste.sethforprivacy.com/?71931870cbbb1472#355KhXW1iVdbLWxBJ9pjvpFo39cfjXScf4kgQGKKwzjU, 0.5c for 1/2, 0.7c for 2/2
14:53:38 <sethforprivacy> Thought fees were going up a lot more than they are!
14:55:59 <UkoeHB> ooo123ooo1234[m]: I’ll gladly do it for free
14:57:07 <UkoeHB> If it means someone other than me is doing the main work (like I have said before, I’d rather be working on Seraphis).
15:01:57 <selsta> sethforprivacy: I think you calculated it wrong
15:02:14 <sethforprivacy> I did what sech1 said
15:02:18 <sethforprivacy> But seems too low
15:02:40 <selsta> new: https://testnet.xmrchain.net/search?value=d888c27320ebd128325055d61ea4567cc7ca74e7507a9fcd7eed70f33d1a1e3a
15:02:57 <selsta> old: https://testnet.xmrchain.net/tx/d7fddb6b95a807fbc8d2984cff776da272f124b3038e6b8e5f9744ad3e7661e7
15:03:24 <selsta> 5x difference, that's with two random 1in 2 out tx I found
15:04:05 <selsta> (but i did not check priority level)
15:04:44 <sech1> fee per byte will be 20000 piconero after the fork with block reward = 0.6 XMR
15:04:58 <sethforprivacy> A "regular" prio level mainnet TX is 1/5 the fee per kb of my calculated fee per kb
15:05:01 <sech1> you can calculate using this number and transaction size
15:05:03 <sethforprivacy> Which matches what it should AFAICT
15:05:39 <sethforprivacy> sech1: Yes, mine is 20733 piconero to be precise
15:05:50 <sethforprivacy> But using 20000 will certainly simplify things 🙂
15:06:21 <sech1> although, transactions with more than 1 input will have weight bigger than size in bytes, and the fee is calculated from transaction weight
15:07:03 <sethforprivacy> Yeah, fee per kB is slightly larger in my 2-in/2-out TX
15:07:11 <sethforprivacy> 20735 pico
15:08:43 <ooo123ooo1234[m]> <jeffro256[m]> "ooo123ooo1234 That patch doesn't..." <- yeah, everything unneeded was removed
15:08:50 <sethforprivacy> Revised numbers assuming 20000 pico as the mainnet fork will be post-tail-emission: https://paste.sethforprivacy.com/?3d536c40bc9e4349#6bJMRRGTfrLp7WKURUvT3KCTQjThFb1G7BAYhA5YnmDx
15:13:15 <ooo123ooo1234[m]> jeffro256: "2. Doesn't throw on file error, and can be used in noexcept contexts" noexcept is useless thing https://en.cppreference.com/w/cpp/language/noexcept_spec#Notes
15:14:21 <ooo123ooo1234[m]> "1. Logs what causes the errors at each step to help debug" or doesn't help due to additional noise
15:16:07 <jeffro256[m]> It's not "useless" because it describes to the reader how to use the function. That's the whole point
15:16:42 <ooo123ooo1234[m]> "3. Interface is documented" additional noise
15:16:43 <ooo123ooo1234[m]> "4. Logic is moved to aptly named file" also noise
15:17:00 <jeffro256[m]> And the logs would help in this particular case because the function can fail due to the openssl API or file I/O
15:17:01 <selsta> now we are back again to yesterday's discussion
15:17:24 <selsta> :D
15:18:13 <ooo123ooo1234[m]> "5. Changes how the file is buffered" preliminary performance optimization, noise too
15:18:25 <ooo123ooo1234[m]> "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
15:18:28 <jeffro256[m]> @ooo123ooo1234 I guess we have exhaused both of our points here but feel free to DM me if you want to still talk 
15:18:30 <ooo123ooo1234[m]> It's like those octoberfest patches but on regular basis
15:18:53 <selsta> it's subjective what some find useful and others don't, obviously everyone will have their own opinion
15:20:53 <ooo123ooo1234[m]> jeffro256[m]: who is the target reader that is gonig to read it ? 
15:22:11 <ooo123ooo1234[m]> jeffro256[m]: No. If you think that your changes are useful than I can prepare 100 such patches tomorrow
15:22:17 <ooo123ooo1234[m]> and 10 other people can prepare other noisy patches
15:22:17 <ooo123ooo1234[m]> is it really needed ?
15:22:32 <ooo123ooo1234[m]> jeffro256[m]: any other student even less knowledgeable than you can do the same
15:22:39 <ooo123ooo1234[m]> what's the purpose of this spam ?
15:22:40 <ooo123ooo1234[m]> c++ training on public repo ?
15:22:48 <UkoeHB> 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).
15:25:43 <ooo123ooo1234[m]> 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
15:26:05 <ooo123ooo1234[m]> and reward must be split between all participants according to added value
15:26:26 <ooo123ooo1234[m]> But the goal of competition should be defined before the beginning
15:26:30 <UkoeHB> How is that a competition? Lol that’s more-or-less the normal review process.
15:27:12 <ooo123ooo1234[m]> UkoeHB: Competition has rules, concrete goal, reward and rules can't be abused by participants
15:28:27 <ooo123ooo1234[m]> 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
15:28:56 <ooo123ooo1234[m]> within available time limits, reward and other constraints
15:29:28 <UkoeHB> Competitions do contain rules and rewards, but the main component is some kind of parallel goal-seeking (not serial).
15:30:46 <ooo123ooo1234[m]> UkoeHB: private part can be parallel, but public one must will be serial
15:30:47 <UkoeHB> However, I at least comprehend why this approach would be valuable to you.
15:31:00 <ooo123ooo1234[m]> UkoeHB: hahaha
15:42:42 <UkoeHB> ooo123ooo1234[m]: do you have an example of a rules/rewards structure that makes sense?
16:10:08 <ooo123ooo1234[m]> <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. 
16:10:45 <ooo123ooo1234[m]> The dumbest reference example known to me is to detect vulnerability and exploit it
16:10:51 <ooo123ooo1234[m]> if people on the other side are competent then I will lose, if not then I will win
16:11:50 <ooo123ooo1234[m]> 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
16:11:52 <ooo123ooo1234[m]> hahaha
16:12:10 <ooo123ooo1234[m]> and I don't cheat when I'm trying to solve problem
16:14:20 <ooo123ooo1234[m]> <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 
16:15:18 <ooo123ooo1234[m]> in case of multisig it's implementation + idealized math model of it + prove within idealized model that it isn't exploitable
16:15:33 <ooo123ooo1234[m]> s/prove/proof/
16:20:10 <ooo123ooo1234[m]> reward structure must be dynamic since it isn't unclear how final solution will be decomposed into work of participants
16:20:19 <ooo123ooo1234[m]> and rules must be strict to avoid any abuse
16:20:41 <ooo123ooo1234[m]> I'm sure that even first approximation of this setup will be much better than current environment
16:21:24 <ooo123ooo1234[m]> In current environment there is no incentive for proper review, goal of work can be changed during review by reviewer at will
16:21:39 <ooo123ooo1234[m]> or by submitter at will
16:34:23 <UkoeHB> 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).
16:36:53 <ooo123ooo1234[m]> UkoeHB: It's impossible to get work done without understanding how to check result.
16:39:23 <ooo123ooo1234[m]> UkoeHB: decentralized protocol development is all about defining rules for untrusted parties that can't abused in arbitrary way
16:39:35 <ooo123ooo1234[m]> > <@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).
16:39:35 <ooo123ooo1234[m]>  * decentralized protocol development is all about defining rules for untrusted parties that are hard to abuse in arbitrary way
17:06:53 <ooo123ooo1234[m]> 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
17:07:37 <ooo123ooo1234[m]> But centralized architecture is the path of least resistance forced by status quo and it's completely incompatible with monero goals
17:07:49 <ooo123ooo1234[m]> status quo = govt / ...
17:08:13 <UkoeHB> 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 
17:08:13 <UkoeHB> 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 
17:08:13 <UkoeHB> 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; 
17:08:13 <UkoeHB> hence, collecting a venn-diagram of analysts can be useful or even essential).
17:12:56 <ooo123ooo1234[m]> UkoeHB: No. The thing found by kaybaNerve is detectable within idealized model too.
17:13:49 <ooo123ooo1234[m]> <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.
17:17:37 <ooo123ooo1234[m]> I don't like academic papers written by many people with a lot of noise, when the key points are very minimal
17:18:05 <UkoeHB> Can't disagree with that
17:18:16 <UkoeHB> ^ noise
17:18:53 <ooo123ooo1234[m]> So people intentionally chose the path to be incorporated into academic hierarchy and then write nonsense, since it's just status quo
17:19:19 <ooo123ooo1234[m]> 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
17:36:20 <UkoeHB> ooo123ooo1234[m]: > Most of the work is to describe concrete protocol within it and then analyse it.
17:36:20 <UkoeHB> 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.
17:36:44 <UkoeHB> able and interested*
17:37:39 <ooo123ooo1234[m]> UkoeHB: hehe, somehow it was possible to achieve
17:46:38 <rbrunner> The testnet part of my web wallet is running already on v15, maybe it's useful for somebody for tests: https://monerotech.info/Wallet
17:46:58 <rbrunner> Also the explorer: http://explorer.monerotech.info:6001/
17:47:24 <sech1> just did a sweep_all on one of my p2pool test wallets: https://testnet.xmrchain.net/block/1983000
17:47:27 <rbrunner> Although that one does not show view tags, which I find a little strange. I thought I was compiling the latest source yesterday
17:53:00 <ooo123ooo1234[m]> <UkoeHB> "Yes, it is a lot of work that..." <- "are few and far" and who are these people ?
17:53:12 <ooo123ooo1234[m]> if there is at least two such candidates then it's possible to do competition between them
17:53:19 <ooo123ooo1234[m]> s/is/are/
17:53:23 <ooo123ooo1234[m]> s/is/are/, s/at/atleast/, s/least//
17:58:59 <ooo123ooo1234[m]> <UkoeHB> "Yes, it is a lot of work that..." <- "https://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
17:59:22 <ooo123ooo1234[m]> quite the opposite: easiest problem are the most profitable
17:59:23 <ooo123ooo1234[m]> hahahahaha
17:59:31 <ooo123ooo1234[m]> s/problem/problems/
18:00:53 <ooo123ooo1234[m]> s/Influence_peddling/Influence\_peddling/, s/'s//
18:01:46 <ooo123ooo1234[m]> game design is broken a bit
18:03:56 <ooo123ooo1234[m]> it deends: if this project is for status quo then everything is ok, if this project is going to change something then not ok
18:04:00 <ooo123ooo1234[m]> s/deends/depends/
18:07:57 <UkoeHB> 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 
18:07:57 <UkoeHB> infinitesimal.
18:09:00 <ooo123ooo1234[m]> UkoeHB: This competition is compatible with anonymity of participants, so that means anyone who can find something can participate
18:09:32 <ooo123ooo1234[m]> if there is some critical thing which cracks everything then this is a chance to get full reward
18:09:45 <ooo123ooo1234[m]> very strong incentive to participate for anyone competent
18:09:59 <ooo123ooo1234[m]> and incompetent people after few iterations can learn how to do it and participate too
18:10:12 <ooo123ooo1234[m]> all submissions must be public
18:10:42 <ooo123ooo1234[m]> I doubt that no one will try to compete with me for proper reward
18:11:07 <ooo123ooo1234[m]> People participates in programming contests just for the respect
18:17:16 <UkoeHB> 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.
18:17:43 <sethforprivacy> Includes p2pool sweep example numbers: https://paste.sethforprivacy.com/?3a142735d054f778#AEwREcTTtD6MQpvbE82G2cocVZiUNXMULZv8YjaFSqh8
18:47:12 <luigi1111w> .merges
18:47:12 -xmr-pr- 8046 8266 8307 8308 8312 8315
19:34:16 <ooo123ooo1234[m]> <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 ?
19:37:59 <UkoeHB> 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).
19:39:49 <UkoeHB> Or if there is something more for me to do, I'll put it on my todo list.
19:42:58 <ooo123ooo1234[m]> UkoeHB: In the worst case learning something new from reading submissions. In the best do something like this: https://github.com/UkoeHB/break-dual-target-dl or anything else
19:44:19 <UkoeHB> Sure, both of those things I'm happy to help with. Just let me know where and how I can help.
19:44:23 <ooo123ooo1234[m]> As you said it's close to review process, but with better focus and incentive for participants
19:47:33 <ooo123ooo1234[m]> 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
19:47:42 <ooo123ooo1234[m]> * it would be like creating
19:48:43 <ooo123ooo1234[m]> It's certainly possible to add into new project, but it means that current one should die
19:48:52 <ooo123ooo1234[m]> * to add it into new
19:53:23 <ooo123ooo1234[m]> p2pool can't compete with minexmr even with full support / money burning from xmrvsbeast owner
19:58:04 <ooo123ooo1234[m]> In general the way to fix or destroy something is the same, both need required good knowledge about weaknesses.
19:58:13 <ooo123ooo1234[m]>  * In general the way to fix or destroy something is the same, both just need extreme knowledge about weaknesses.
19:58:47 <UkoeHB> 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 
19:58:47 <UkoeHB> 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 
19:58:47 <UkoeHB> do, but there aren't a lot of real alternatives.
20:09:17 <UkoeHB> 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).
20:12:25 <UkoeHB> A lot of this is off-topic though, better suited for #monero-research-lounge or something.
20:14:53 <ooo123ooo1234[m]> UkoeHB: it's about relax, so lounge isn't suitable
20:14:54 <ooo123ooo1234[m]> hahaha
20:15:03 <ooo123ooo1234[m]> * it's not about relax,
21:51:57 <Guest47> Need help opening up