00:52:06 <hyc> make test says it can't find /usr/bin/python. does it need python3 or python2?
00:52:31 <hyc> I can symlink it but right now I have only python2.7 and python3
06:12:37 <rbrunner> We may have something like a stalemate regarding the multisig PR 8149: https://github.com/monero-project/monero/pull/8149
06:12:44 <rbrunner> Looking back in the log over the last 2 days, this is how I interpret the comments of various devs - YMMV:
06:12:53 <rbrunner> In favor of merging 8149 as-is: moneromooo, ErCiccione, kayabanerve[m], arnuschky[m], rbrunner
06:13:00 <rbrunner> Against: UkoeHB, jeffro256[m], ooo123ooo1234567
06:13:07 <rbrunner> (List just for info; with this I don't propose to do simple vote-counting.)
06:13:14 <rbrunner> Any good idea how to proceed and come to a decision regarding this and the upcoming hardfork release? selsta, luigi1111
06:14:08 <kayabanerve[m]> I would want to re-hear UkoeHB's commentary as they have the most important voice here and I'm honestly willing to simply defer to them. That would make it 4:4 from 5:3 though, and not really help :p
06:15:30 <rbrunner> Well, he even suggested to disable current multisig, so the release would not support *any* multisig at all
06:15:42 <rbrunner> and people wanting it had to compile their own binary
06:19:04 <kayabanerve[m]> Considering it's flagged and explicitly experimental, AFAICT there's no concerns of liability (not that there was already. Just saying even from a PR standpoint as a project...). Anyone considering an enterprise deployment knows to wait. Anyone who already has one is already screwed. This can't make it worse and may solve it.
06:21:51 <rbrunner> Yeah, and if we disable it now we probably will have to endure pointed questions why we did not disable current multisig months ago already ...
06:22:08 <rbrunner> But that doesn't really help to decide either :)
06:23:33 <kayabanerve[m]> So koe isn't against this over the current, koe is against it at all?
06:23:46 <kayabanerve[m]> ... ack. I'm fine with that.
06:24:32 <kayabanerve[m]> But I'd hope for the sake of progress we get #8149 merged and THEN we open a partner to #8328 to make a compile time def
06:24:55 <kayabanerve[m]> Which I fully ack will probably kill koe's movement to get it disabled and this is absolutely what a politician would say lol
06:25:04 <rbrunner> That's how I interpret them, yes: https://libera.monerologs.net/monero-dev/20220607#c106196
06:25:21 <kayabanerve[m]> But at the same time, this is stalled not because people are against this code compared to the current, but because people are saying we shouldn't ship unreviewed cryptography
06:25:38 <kayabanerve[m]> The way to move forward is to separate the two
06:26:13 <kayabanerve[m]> Though I will note I'm suggesting merging 8149 then tackling a 8328 compliment. We can tackle a 8328 compliment and if we make this a compile time def, 8149 integration doesn't matter as much.
06:26:55 <kayabanerve[m]> So that'd give koe time to present their arguments on a fair playing field, instead of one predicated on being better than what ewe have, while still moving forward.
06:27:15 <rbrunner> I am not sure what you mean with "8328"
06:27:48 <rbrunner> Ah, I see: https://github.com/monero-project/monero/pull/8328
06:27:50 <kayabanerve[m]> And tbh, considering how multisig 1.0 did, I'll agree with that. Make multisig hidden behind a compile time def BUT I'd also advocate merging 8149 so we're not pointing people to koe's personal branch for multisig.
06:27:59 <rbrunner> The "Disabled by default" merged PR
06:28:09 <kayabanerve[m]> 8328 made it a config. I'm discussing a compliment to make it compile time, not run time.
06:28:52 <rbrunner> I see
06:29:04 <rbrunner> Another variant, in a way
06:29:20 <rbrunner> Compile yourself, but in a way that's a little easier
06:29:42 <kayabanerve[m]> It's a separation of the two discussions which levels debate, as I'm only saying merge 8149 as current multisig is absolutely garbage, while enabling progress.
06:30:16 <kayabanerve[m]> If we're removing multisig from Monero as we don't have any reviewed option and believe in ensuring security... good. 
06:31:08 <kayabanerve[m]> But not we have a WIP which likely handles most of the discussed issues and we have some users who already have multisig wallets. I see no reason to bar them from it. So now they have to compile multisig themselves to fully commit to an experimental feature while showing some level of tech proficiency.
06:31:18 <rbrunner> It's open to debate, up to a point, whether 8149 is "unreviewed". IMHO only a review of the last few changes is missing.
06:31:57 <kayabanerve[m]> Do we want them to compile the current garbage or compile 8149? Obviously, 8149. I don't want to point anyone to a personal GH though. Therefore, we should remove the current garbage as an option (as someone may mistakenly compile master instead of 8149), by merging 8149.
06:34:19 <rbrunner> Maybe that's the compromise people can rally around. I am bit sceptic, however ...
06:34:31 <kayabanerve[m]> rbrunner: I still have a review pending on my end, and I'm kinda stuck traveling the next week or so leading up to MoneroKon D: That said, it has had a notable amount of review, and I believe it's had more review that most changes to Monero at this point. The issue is a lot of review has been skin deep due to a lack of knowledge.
06:34:42 <kayabanerve[m]> So for sufficient review...
06:49:53 <arnuschky[m]> <kayabanerve[m]> "Do we want them to compile the..." <- That's essentially my position too. It's madness to keep the current multisig mess in the code (it should have been removed months ago). 8149 is a significant step up (and I agree, at this point it had a lot of reviews). 
06:50:38 <kayabanerve[m]> I'm fine saying still not enough review and making this a compile flag though. EXPERIMENTAL_MULTISIG=1. I want to be clear there
06:50:39 <arnuschky[m]> Once merged, a few things can kick off: integration with partner libraries (monero-js, monero-cpp) etc, people can adapt to the new KEX changes etc. All this is possible once the code is merged.
06:51:04 <kayabanerve[m]> I'm also fully ready to shame any corp/org which uses such a flag :p
06:51:05 <kayabanerve[m]> *in prod
06:51:10 <kayabanerve[m]> Integration would be healthy :)
06:51:53 <arnuschky[m]> As a separate discussion, the project should decide how to protect users / limit liability. I think a runtime option after a disclaimer is totally sufficient - it's crypto, everything's experimental, and honestly we're going a bit over board on the nanny-governance here imho.
06:52:24 <arnuschky[m]> But generally I think it's a great idea by kayabanerve to separate those two issues in order to progress in the decision making.
06:53:42 <kayabanerve[m]> And then because I've been accused of having a conflict of interest here, in the most other-privacy-coin-bs way possible, I will comment I have my own original multisig work (fully MIT, not planning on making any money by limiting access to it). Therefore, I have the possibility to gain some form of notoriety by limiting Monero's native multisig so my own gains... market share? And something something, if I was evil, I'd say it
06:53:42 <kayabanerve[m]> should be disabled.
06:54:24 <kayabanerve[m]> ¯\_(ツ)_/¯ I don't really get it. I think when I said it shouldn't be disabled, that's also what I would've said if I was evil, but if I knew it was problematic. Can't really win there
06:55:21 <kayabanerve[m]> All I know is I was told I have a CoI and was talked to in a way which suggested I was evil :p So grain of salt to the people here, I guess
06:55:26 <kayabanerve[m]> And thanks for the ACK :)
06:58:16 <arnuschky[m]> nah that conflict of interest argument didn't make any sense at all imho.
07:04:49 <kayabanerve[m]> I don't either lol. Just getting out ahead of it before it comes up again
07:05:05 <kayabanerve[m]> And if someone thinks it does make sense and this is relevant... well now it's a non-issue because I disclosed it
07:25:21 <moneromooo> Reading the above, is the issue that the old 8149 is reviewed enough, but the new one isn't ? If this is what stops sone people, just merge the previous one and not the second one yet.
07:31:56 <rbrunner> As far as I know that would be a bit unfortunate because then the functionality to make multisig tx *before* the hardfork would be missing
07:34:11 <moneromooo> Sounds weird. That ought not take any cryptography.
07:34:36 <moneromooo> So this suggests the new changes are this + some crypto, and they're likely independent.
07:35:00 <moneromooo> Then... merge original plus compat, leave the new crypto out.
07:35:11 <arnuschky[m]> <moneromooo> "Reading the above, is the..." <- Afaik the new changes are all code-level:
07:35:11 <arnuschky[m]>  - rebases to BP+ and viewtags
07:35:11 <arnuschky[m]>  - low-level comment fixes
07:35:11 <arnuschky[m]>  - enabling non-BP+ use of the new multisig code
07:35:13 <moneromooo> Assuming it doesn't take too much time to split.
07:35:43 <moneromooo> Then the "it's not reviewed crypto" argument seems bad faith ?
07:36:00 <moneromooo> Who made it and can explain ? :)
07:36:30 <arnuschky[m]> it comes from another point: the crypto in 8149 is complex and had mostly surface reviews
07:36:30 <moneromooo> More likely my inductions above are wrong :D
07:36:49 <moneromooo> So this argument is against the whole of 8148 then ?
07:36:54 <arnuschky[m]> afaik nobody other than ukoe really went deep down on verifying them. all reviews on 8149 were code-level or superficial
07:37:03 <arnuschky[m]> so there's a lingering unease about the crypto changes in 8149
07:37:21 <arnuschky[m]> the rest has been reviewed plenty - more than most changes in Monero afaik
07:37:51 <moneromooo> OK, that makes more sense then. Thanks.
07:37:57 <arnuschky[m]> That's why we commissioned the audit: have someone go deep on the crypto changes (of 8149 alone)
07:39:46 <rbrunner> I think "lingering unease" is quite a good characterization. But anyway, technically it works. It just may be that we switch one vuln with the next :)
07:40:13 <rbrunner> Quite unlikely IMHO, but still.
08:01:12 <ooo123ooo1234567> you all are choosing right words to justify whatever is needed to be justified, but I'm not sure how it helps to solve technical problems
08:26:55 <kayabaNerve> ooo123ooo1234567: Technical problems is a bogeyman until we have explicit examples. We can't prove a negative though.
08:27:28 <kayabaNerve> So we're discussing how to balance this as we should. My recommendation would be make this compile time set, not runtime like it is now, yet still merge 8149 to purge the garbage and move ownership into Monero.
08:28:04 <kayabaNerve> Then we can get further review to solidify our stance the bogeyman doesn't exist before we start being open to attacks by the bogeyman.
08:29:13 <kayabaNerve> And I don't use the term bogeyman to say there aren't issues. I'm saying we should make this compile time and unofficial (instead of official as experimental). I use the term bogeyman to highlight he will always exist and we'll never truly know.
08:33:17 <ooo123ooo1234567> why did you delete your rust package with multisig ?
08:34:26 <ooo123ooo1234567> not ready / experimental ?
08:39:09 <ooo123ooo1234567> <kayabaNerve> "ooo123ooo1234567: Technical..." <- negative side effect can be proven with exploit, positive side effect can be proven by passed test, lack of negative side effects can be proven with proper verification; what exactly can't be proven ?
08:39:36 <ooo123ooo1234567> <kayabaNerve> "ooo123ooo1234567: Technical..." <- I've said you all are good at choosing words and you're using this "bogeyman"; facepalm
08:39:46 <sech1> tests only prove lack of known bugs
08:39:55 <sech1> you can't prove that it's bug free
08:40:07 <sech1> unless you dive into formal code verification
08:40:28 <kayabanerve[m]> <ooo123ooo1234567> "why did you delete your rust..." <- I didn't delete it. I had a rust multisig, not monero multisig package public and privatized it for a few reasons. Please stop with the ad hominem confrontations
08:40:29 <ooo123ooo1234567> sech1: did you notice "positive side effect" ?
08:40:51 <sech1> "lack of known bugs" = positive side effect
08:42:16 <kayabanerve[m]> ooo123ooo1234567: You can prove a positive. You can prove there is an exploit by... Proving a negative is distinct. Sure, there is formal verification. I don't believe it's feasible to formally verify the entire Monero binary and the OS it runs on for such perfect security.
08:42:16 <kayabanerve[m]> It becomes a question of scope. We can write up the algorithm and get that formally verified. I wouldn't be against that and I may even say we should hold off on deployment until... But even that wouldn't be truly proven.
08:42:59 <kayabanerve[m]> MuSig was considered secure and had several pages of proofs. Then Drijver's published their work.
08:43:22 <kayabanerve[m]> GG20, considered secure. Alpha Rays.
08:44:21 <ooo123ooo1234567> kayabanerve[m]: MuSig and 4 other signatures had broken security proof
08:44:29 <kayabanerve[m]> We can't sit around to the heat death of the universe here. Merging this removes the horrible code that definitely shouldn't be used. Putting it behind a compile time guard ensures only people with sufficient technical savvy can enable it, which hopefully gives the opportunity to communicate its status.
08:44:42 <kayabanerve[m]> ooo123ooo1234567: Wow imagine completely missing what I said
08:45:58 <kayabanerve[m]> "considered". MuSig was considered secure. Yes, work was done to prove otherwise. I'm not contesting that. I'm saying despite their pages of proofs, and the bounds they believed they proved despite acknowledging questions remaining, those bounds were broken only after a notable amount if time
08:47:27 <moneromooo> Please try to be trolled in another channel.
08:47:29 <kayabanerve[m]> I'm saying it's completely infeasible to perfectly verify the theory and implementation of Monero multisig. There may be errors in the write up, errors in the proof, new theoretical attacks, errors in the implementation, errors in the OS predicated on Monero's usage... So at some point we have to say this is good enough. It is how it is
08:47:34 <HenryHollingwort> <sech1> "unless you dive into formal code..." <- and then you can only prove it matches a specification - but there may be bugs in that specification...
08:48:10 <kayabanerve[m]> Let's ack mooo and move on from this.
08:50:10 <ooo123ooo1234567> kayabanerve[m]: if someone can't write proof and there is at least 1 example in history with failed proof then there is no need for proofs. it's what you're saying
08:50:31 <ooo123ooo1234567> kayabanerve[m]: Btw, do you know what was wrong in their proof ?
08:53:34 <dEBRUYNE> arnuschky[m]: The audit should be finished shortly right?
09:07:00 <ooo123ooo1234567> > <@kayabanerve:matrix.org> You can prove a positive. You can prove there is an exploit by... Proving a negative is distinct. Sure, there is formal verification. I don't believe it's feasible to formally verify the entire Monero binary and the OS it runs on for such perfect security.
09:07:00 <ooo123ooo1234567> > 
09:07:00 <ooo123ooo1234567> > It becomes a question of scope. We can write up the algorithm and get that formally verified. I wouldn't be against that and I may even say we should hold off on deployment until... But even that wouldn't be truly proven.
09:07:00 <ooo123ooo1234567> Imagine someone would say all these words for the question: "can you prove security of this?"
09:08:08 <ooo123ooo1234567> <moneromooo> "Please try to be trolled in..." <- It isn't me who is choosing right words to justify blind merge.
09:19:33 <ooo123ooo1234567> <kayabanerve[m]> "I didn't delete it. I had a rust..." <- I'm about monero-sign-rs repo.
09:20:16 <rbrunner> Anyway, according to earlier decisions which nobody revoked so far we aim for a release on June 16, which is pretty damned sure
09:20:36 <rbrunner> So I would say we best arrive at a decision what to do with 8149 in the next few days
09:21:03 <rbrunner> It doesn't look to me that we are getting close, unfortunately
09:21:22 <rbrunner> So good ideas are needed how to resolve this problem
09:21:49 <rbrunner> I don't have any right now, but we are quite a number of people here. Not yet time to despair.
09:22:18 <rbrunner> Er, I meant of course "pretty damned soon" :)
09:23:00 <sech1> in one week
09:23:23 <rbrunner> How many Monero blocks is that? :)
09:23:38 <sech1> a week's worth
09:24:01 <sech1> 5040 blocks
09:24:59 <moneromooo> Clearly, we must switch to 10 min blocks in an emergency fork, just to push back the next fork.
09:25:28 <rbrunner> That proposal is at least innovative
09:26:33 <kayabanerve[m]> <rbrunner> "It doesn't look to me that we..." <- Split the two proposals. Select the people you want to weigh in. Get their comments. Provide a summary. We can trivially merge 8149 AFAIK. I'd ask if mooo is available to make the runtime flag compile time. Then the only remaining question is final review of the multisig C++ and double checking the compile time view.
09:26:48 <kayabanerve[m]> That's my vote, anyways, and I've already provided my comments on the split proposals.
09:27:04 <kayabanerve[m]> I feel most people objecting to the merge are objecting to multisig. Not objecting to this multisig over the current.
09:29:10 <ooo123ooo1234567> moneromooo: "Please try to be trolled in another channel." this msg falls into this category too
09:52:44 <ooo123ooo1234567> <kayabanerve[m]> "I didn't delete it. I had a rust..." <- Question about repo isn't "ad hominem confrontation". It's just an interesting piece of code/information that is currently not available. I've just asked why.
09:56:44 <selsta> if koe is against merging 8149 as is then i would follow his recommendation
09:56:54 <selsta> he spent the most time on it apart from ooo
10:07:17 <kayabanerve[m]> I'd want to check their thoughts on merging 8149 with the compile time guard. AFAICT, it's either that or we leave the current multisig code in (with the runtime guard or with a compile time guard). Given that choice...
10:07:34 <selsta> merging improvements vs trying to do it properly on first try becomes a philosophical question, in both cases multisig would stay insecure until considered otherwise
10:08:24 <kayabanerve[m]> selsta: One is known to be incredibly insecure. One is considered insecure to be safe. This PR is an improvement.
10:09:01 <selsta> in both cases multisig should not be used in production so it doesn't matter
10:09:24 <kayabanerve[m]> While I'm not endorsing it as a result, and not saying we should remove the runtime guard (the opposite, actually), I am endorsing taking a step towards something better while we wait for the RINO audit and figure out our next steps, such as formalization and further audits.
10:10:03 <kayabanerve[m]> selsta: Considering I assume we have existing users who use multisig and can't simply give it up... I feel it's important they at least use the better option.
10:10:07 <kayabanerve[m]> I'm mainly concerned about people with existing cold wallet setups.
10:10:45 <kayabanerve[m]> As in, organizations and exchanges who already use multisig and need to continue to use it to function. They can't sit on funds they need access to.
10:11:05 <arnuschky[m]> <dEBRUYNE> "arnuschky: The audit should be..." <- yes, we should have results early next week 
10:11:14 <kayabanerve[m]> So while I agree it shouldn't be actively used, I'm advocating this as a way out.
10:11:17 <selsta> I thought we are adding a runtime flag for that that makes it clear all multisig participants have to be trusted.
10:12:00 <kayabanerve[m]> ... right, but there's still known attacks on it. 8149 doesn't have known attacks. 
10:12:19 <kayabanerve[m]> So while we should at least keep that runtime flag, it's still undeniably better to have it next to 8149 than the current.
10:12:57 <kayabanerve[m]> The other discussion is making it a build time guard so users actually need to compile a daemon and agree to that notice, rather than download the bin and set a config. I'm also leaning in favor of that and it's what I wanted to query koe about.
10:13:20 <kayabanerve[m]> So I'm proposing at least +8149 and preferable +8149 with a build time guard for multisig as well
10:13:57 <ooo123ooo1234567> kayabanerve[m]: original PR also doesn't have known attack, but for some reasons someone decided to add few more patches on top of it and now you're pushing to merge it; facepalm
10:14:16 <kayabanerve[m]> The original PR does have a known attack.
10:14:19 <ooo123ooo1234567> kayabanerve[m]: which one ?
10:14:41 <kayabanerve[m]> I believe it was already disclosed on koe's PR. I don't care to further disclose anything at this time.
10:14:51 <kayabanerve[m]> It wasn't introduced in that PR, yet it also wasn't handled by it.
10:15:01 <kayabanerve[m]> So there's a reason those "few more patches" exist.
10:16:11 <rbrunner> Maybe this: https://github.com/monero-project/monero/pull/8149#issuecomment-1114060387
10:16:15 <kayabanerve[m]> Considering you abandoned that PR, I also wouldn't bring it up now. It's an egotistic attempt to the person who's the PR author (instead of co-author) when your work is much more limited and the co-author you're trying to remove rescued it.
10:16:26 <kayabanerve[m]> * attempt to be the person
10:16:51 <kayabanerve[m]> rbrunner: Yep. That was fully disclosed then.
10:17:29 <ooo123ooo1234567> kayabanerve[m]: Why is it considered as abandoned ?
10:17:59 <kayabanerve[m]> So selsta: It's not about endorsing 8149. It's about being robust by fixing several issues. The warning will remain. People still shouldn't use multisig. Some people still will. Now they have less to worry about.
10:19:07 <selsta> kayabanerve[m]: right, I can follow your thoughts but I still think it's best to not merge it yet if koe recommends that. runtime vs compile time doesn't matter to me personally.
10:20:53 <ooo123ooo1234567> kayabanerve[m]: write code that fixes problems - egoistic, resubmitting patch of someone else - not egoistic; facepalm
10:21:20 <rbrunner> For me it's interesting to hear what he thinks about the compromise of merging but disabling so people have to compile to arrive at working multisig
10:21:44 <rbrunner> I don't think that version was on the table yet in past discussions
10:24:05 <kayabanerve[m]> You're egotistic for trying to be the sole author when the co-authored work is the best form. You abandoned it when you stopped discussing it with koe for weeks and left multiple comments unresolved, didn't object to the new PR, didn't contribute to it, and didn't incorporate its changes into your own work to reclaim the mantle before koe spent months with this. I appreciate your original work, and am not calling it egotistic, and
10:24:05 <kayabanerve[m]> koe explicitly noted your contributions, making their work not egotistic. I've not replied to several of your messages, and will go back to that, yet wanted to be clear on my stance here.
10:26:50 <rbrunner> I only hope that we don't finally arrive at a situation where scammers will be able to take advantage of
10:27:14 <rbrunner> "No working multisig in your Monero daemon? And not able to compile yourself? Here, use my RAR, password is SCAMMER"
10:27:22 <selsta> my recommendation: add runtime flag and everything else gets merged when we are confident, without rushing it because it's a theoretical improvement. will keep it as that otherwise we are running in circles
10:28:08 <kayabanerve[m]> rbrunner: I was also concerned about this, which is why I was going to suggest keeping the runtime warning, yet that could also just be compiled out and...
10:29:21 <rbrunner> We could of course also decide to treat Monero users as mature and reasonable beings, able to decide themselves, and offer them 8149 plus runtime config, but maybe now I am just dreaming :)
10:30:37 <ooo123ooo1234567> <kayabanerve[m]> "You're egotistic for trying to..." <- if some discussion about PR is stopped then it doesn't mean that PR is abandoned.
10:31:13 <kayabanerve[m]> rbrunner: 8149 being on a branch is a compile time config :p Issue is the default is the one that's definitively worse.
10:34:27 <rbrunner> selsta: "because it's a theoretical improvement" I think this is a part that makes the whole thing so difficult: It's definitely more than a "theoretical" improvement
10:34:48 <rbrunner> I think it replaces code with one or even several known vulnerabilities
10:35:03 <selsta> rbrunner: same applies to 7760 and it's still unmerged
10:35:33 <rbrunner> Yes, another place where some people run around in circles :)
10:36:16 <rbrunner> I just wait until the running around in circles regarding the serialization improvement / replacement PR starts ...
10:36:46 <ooo123ooo1234567> <kayabanerve[m]> "You're egotistic for trying to..." <- Previous multisig had a lot of co-authors, but for some reason wasn't secure. Is it sufficient counterexample for your theory about what's the best sole author or  co-author ?
10:39:04 <rbrunner> I think soon enough our planet will have turned further enough for UkoeHB being able to join the splendid fun we have here
10:39:06 <GuruJi[m]> Maybe let's have a working multisig for the worldwide Monero community and add the authors there then? 🤔
10:42:17 <ooo123ooo1234567> <kayabanerve[m]> "You're egotistic for trying to..." <- How is it possible to refer to the same with egoistic and not-egoistic in the same paragraph without cognitive dissonance ? Where is your critical thinking ?
10:44:14 <ooo123ooo1234567> <kayabanerve[m]> "You're egotistic for trying to..." <- by this logic anyone could add stupid questions under arbitrary PR, wait until PR author will start ignoring them and then resubmit PR in the same vein; facepalm
10:48:54 <ofrnxmr[m]> Solution? ooo123ooo1234567: 
11:04:59 <ofrnxmr[m]> Or what do you believe to be the best action to take regarding all of your PRs?... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/247edd1a2dc13a871e2328af5e798048fb261941)
11:22:07 <UkoeHB> Since ooo123ooo1234567 is too immature to take responsibility (which is so incredibly unmanly and pathetic), the changes I made in 8149 don’t have any reviews. Waiting for the audit results should be the bare minimum before merging, unless someone else actually looks at all the diffs and approves it.
11:26:27 <ooo123ooo1234567> UkoeHB: For those who took responsibility and failed what would be the punishment ? The same question for previous multisig or any other failures ? So far it looks like responsibility for any flaws was shifted to auditors which are known to be good at dodging any responsibility. So no responsibility in practice.
11:28:12 <ooo123ooo1234567> <UkoeHB> "Since ooo123ooo1234567 is too..." <- And why do you think that I've refused to take responsibility for my own patches ?
11:28:34 <ooo123ooo1234567> I would say blind merge is a sign of lack of responsibility. And careful treatment of changes is a sign of responsibility.
11:29:38 <ooo123ooo1234567> So far it looks like blind merges have the highest reward and 0 punishment. And careful merging has 0 reward and the highest punishment.
11:30:35 <ofrnxmr[m]> ooo123ooo1234567: Review some of these bad merges ? You're seeing things the reviewers are missing (or not even looking at)
11:45:55 <rbrunner> Wow, 4 or 5 people discuss for hours how to treat 8149 sensibly and responsibly, and still get accused of "merging blindly", "lack of responsibility" and similar. Motivates like hell.
11:53:29 <sech1> while we're at it, can someone merge 8381 blindly? :D
14:53:54 <ErCiccione> Folks. The wording used by s
14:54:35 <ErCiccione> Somebody is clearly crafted without the intention of building a constructive discussion. Please keep that in mind
14:56:54 <ErCiccione> Don't answer to the continuous provocations and insinuations of the anon. No amount of knowledge compensates the ability of working in team, which is the only fundamental skill necessary to do collaborative development.
14:57:29 <moneromooo> No need to push to the other extreme...
14:58:52 <ErCiccione> Not an extreme at all. An important work is jeopardized by the unability of some people of collaborate. Everyone is useful, no one is necessary.
14:59:35 <ErCiccione> I scrolled now one day of conversation and it was filled by useless provocations and answers to those provocations
15:00:24 <ErCiccione> If the "other extreme" is to ignore somebody unable to conversate without ridiculizing their counterpart, so be it.
15:01:10 <ofrnxmr[m]> Knowledge is power 
15:02:33 <moneromooo> Obviously, the extreme is "the ability of working in [a] team [is] the only fundamental skill necessary to do collaborative development.". You also need enough capability to not be a net negative.
15:02:52 <moneromooo> Both are needed.
15:06:04 <ErCiccione> Sure, i simplified to make the point. Obviously you need to be able to collaborate and other things.
15:06:44 <ErCiccione> Should we just set a meeting where we can decide what to do once for all?
15:18:30 <ErCiccione> We really need to take a decision on this and seems like the discussion keeps going in circle. Let's set a meeting and decide there once for all. Even by vote if necessary. Stalling on this cannot be an option. Would people participate? Maybe the coming week end?
15:21:24 <moneromooo> After the audit results are known maybe ?
15:21:38 <moneromooo> Then we know if it's good, easy to fix, or borked.
15:21:40 <UkoeHB> ErCiccione: idk what we can decide without the audit results
15:21:59 <UkoeHB> other than 'lets see what the audit has to say'
15:23:43 <ErCiccione> Sure. That's what i proposed the last time. I'm assuming the audits will arrive before the weekend, but we can wait for them to be released before setting a date if we are more comfortable with that.
15:25:37 <dukenukem> <dEBRUYNE> arnuschky[m]: The audit should be finished shortly right?
15:25:37 <dukenukem> arnuschky[m]> <dEBRUYNE> "arnuschky: The audit should be..." <- yes, we should have results early next week 
15:25:52 <dukenukem> not before the weekend, apparently.
15:27:28 <ooo123ooo1234567> <ErCiccione> "I scrolled now one day of..." <- everything can be treated as useful or useless depending on the goal, what did you keep in mind when decided that it was useless ?
15:27:32 <ErCiccione> I assumed wrong then, my bad. Let's already set a meeting for next weekend then?
15:31:35 <ooo123ooo1234567> <moneromooo> "Then we know if it's good..." <- or inconclusive
15:33:03 <moneromooo> In fact, I'm not sure if we need a meeting. If the audit says all good, it goes in. If it's just stuff that's easy to fix correctly, fix and it goes in. Bad stuff, it doens't go in. We only need a meeting if it's not too bad but not trivial to fix...
15:33:37 <moneromooo> UkoeHB likely being the one to assess how easy it is to fix.
15:34:05 <moneromooo> (but we can have a meeting too)
15:39:27 <moneromooo> Yeah. Bit pointless to fork out for one if it was going to be unused.
15:43:07 <ooo123ooo1234567> <ErCiccione> "Not an extreme at all. An..." <- writing patch that fixes problems and waiting for proper review - jeopardized, resubmitting patch of someone else with unimportant changes on top and skipping proper review - not jeopardized; facepalm
15:56:29 <rbrunner> " everything can be treated as useful or useless depending on the goal". So true. For once this put a smile on my face.
15:56:49 <binaryFate> Note the week-end next week (18/19th) is Monerokon in Lisbon so lot of people will be busy
16:53:41 <MeowingCat> something is wrong with monero-lws and wallet2
17:23:32 <MeowingCat> where is the definition of light_wallet_get_unspent_outs()?
17:23:44 <MeowingCat> its declartion is in wallet2.h
17:24:59 <endogenic> wallet2 does not have a current or even complete impl of light wallet client features
17:25:15 <endogenic> i mentioned in my 2019 talk there's an assertion in there with the wrong condition
17:25:22 <endogenic> if anyone runs it i bet it will trip
17:25:27 <MeowingCat> ohh damnnnn
17:25:38 <MeowingCat> we just thought it supports monero-lws
17:25:46 <endogenic> no
17:25:48 <endogenic> wallet2
17:25:53 <endogenic> oops
17:25:55 <endogenic> wallet2
17:25:58 <endogenic> ugh
17:26:02 <endogenic> anyway it does not
17:26:02 <MeowingCat> damnnnn
17:26:18 <endogenic> monero lws uses scanning code from core crypto and makes its own algo
17:26:23 <endogenic> that's why it should all converge
17:26:24 <endogenic> lol
17:26:26 <MeowingCat> i was curious about why monero-lws fails at parsing JSONs from wallet2
17:26:39 <endogenic> idk what a json from wallet2 is tbh
17:27:01 <MeowingCat> damn wallet2
17:27:06 <endogenic> the reasons are all visible in the lws code
17:27:13 <endogenic> why damn wallet2?
17:27:36 <MeowingCat> you mean other options like monero-cpp?
17:27:40 <endogenic> it merely needs to be factored as i have done and i need to set aside some time to PR those factors
17:27:44 <MeowingCat> what are other options??
17:28:17 <endogenic> we've discussed this a few times by now i think
17:28:29 <endogenic> i'll share my most recent repo very soon
17:28:36 <endogenic> would be nice to have a helping hand
17:28:44 <endogenic> but for now i have no one helping me
17:29:00 <endogenic> anyway my blocker is legal at present
17:29:12 <endogenic> just waiting on attorney
17:29:26 <endogenic> the code i wrote is copyrighted sufficiently etc
17:29:35 <endogenic> complicated and stupid mess of a situation though
17:29:45 <endogenic> but simple solution. give it a couple days pls
17:29:53 <endogenic> mymonero core cpp is flawed
17:30:07 <endogenic> i fixed various issues in it besides the ones that were given to it after i left
17:30:10 <MeowingCat> C++ is dumb
17:30:29 <endogenic> uh no
17:30:31 <MeowingCat> CMake is more dumb
17:30:36 <endogenic> sure
17:30:45 <endogenic> ttyl dude
17:31:02 <MeowingCat> C++ can be written gooooodü
17:31:05 <MeowingCat> butttt
17:31:23 <MeowingCat> there are some issues in minds
17:31:33 <MeowingCat> about design patterns and things
17:31:40 <MeowingCat> i really can't understand this codes
17:31:45 <MeowingCat> why written like this
17:32:34 <MeowingCat> cursed code
17:33:21 <MeowingCat> a kind of cursed code the reason behind this is damn C++ and its design patterns and approaching curse
17:35:40 <MeowingCat> structs and snake case namespace in C is the besttt
17:36:41 <MeowingCat> i really can't understand why Monero devs didn't write build recipes for dynamic and static libraries for Monero API
17:36:45 <MeowingCat> we could use them easily
17:37:57 <endogenic> because you didnt write them yet
17:37:59 <endogenic> that is the answer
17:38:13 <endogenic> anyway they do exist
17:38:25 <MeowingCat> i agree the open source way
17:38:34 <MeowingCat> but still wrong
17:38:55 <endogenic> private parties have little incentive to release or maintain them unless they have enough resources
17:38:59 <MeowingCat> because they don't care while they are writing harder parts
17:39:10 <endogenic> MeowingCat: yes you are right
17:39:17 <endogenic> and how are you different?
17:39:30 <endogenic> i said this in my talk
17:39:32 <endogenic> basically
17:39:37 <endogenic> i said MeowingCat specifically
17:39:41 <endogenic> likes to meow a lot
17:39:41 <MeowingCat> i mean the code is there
17:39:58 <moneromooo> The existing light wallet code in wallet2 is most likely inoperable. I remember at least one obvious "this can't work" thing, though I can't recall what it was, but it was prima facie evidence it did not work.
17:40:07 <endogenic> so use my code dude
17:40:10 <MeowingCat> just need build recipes for static and dynamic libraries
17:40:16 <MeowingCat> endogenic, it can't be built lol
17:40:18 <MeowingCat> i mean this
17:40:20 <endogenic> i wrote my lws code ages before it was added to wallet2
17:40:22 <MeowingCat> CMake is dumb
17:40:35 <MeowingCat> when i open the source folder in VSCode
17:40:41 <MeowingCat> linter can't do anything
17:40:50 <MeowingCat> for Monero sources
17:40:50 <endogenic> sorry dude
17:40:58 <endogenic> that sucks
17:41:06 <MeowingCat> because the linter can't work with non relative include paths
17:41:28 <endogenic> can you DM me?
17:41:33 <MeowingCat> or some ghost macros
17:41:44 <endogenic> i'll help you get up and running if i can
17:41:55 <endogenic> gtg 4 now
17:58:44 <cryptogrampy[m]> <MeowingCat> "something is wrong with monero-..." <- can you elaborate
18:19:49 <MeowingCat> hiiii again
18:30:48 <UkoeHB> MeowingCat: for static analyzer, copy the compile commands file from your build/release directory into the main directory (afaik it has to be generated by the make command if you want the tests directory to be included).
18:31:23 <UkoeHB> Or configure your analyzer to read that file from build/release I guess
18:31:52 <UkoeHB> build/[yoursystem]/release *
18:31:57 <MeowingCat> UkoeHB, i know compile_commands.json
18:32:04 <MeowingCat> it is really an interesting thing
18:32:20 <MeowingCat> trying to fix a wrong approach with another wrong thing :(
18:32:35 <UkoeHB> Ok I don’t care about that
18:33:31 <MeowingCat> we can't build monero-cpp and other Monero things because of this design issue
18:33:41 <MeowingCat> damn CMake and other things :(
18:34:03 <MeowingCat> for example linking wallet2 API is a very common thing
18:34:33 <MeowingCat> but i worked hard to find all static libraries that i need to link for that
18:34:44 <MeowingCat> it might be easier
18:36:22 <MeowingCat> when i finish Monero part i will just build it to also a dynamic library and use it in my C# library for making transactions
18:37:01 <MeowingCat> and we will have a .Net library that can derive keys and make transactions for Monero
18:37:27 <MeowingCat> butttttt i would wish this things could be problemlesssss
18:38:05 <MeowingCat> when i see building issues that are not because of code's platform abstractions
18:38:22 <MeowingCat> i feel really badddd
18:38:40 <MeowingCat> just build script issues
18:39:51 <UkoeHB> Sounds like something you could work on to improve
18:40:03 <MeowingCat> i willl when i have time
18:40:50 <UkoeHB> Great to hear :)
18:41:11 <MeowingCat> im not an extreme math catttttttttt
18:42:37 <MeowingCat> i would like to implement Monero's transaction builidng and signing in other languages :(((
18:43:26 <moneromooo> In Whitespace. Good language for privacy tech. Appears all the same.
18:43:56 <moneromooo> Alternatively, Malbolge. Comes pre-encrypted.
18:44:43 <hyc> finding the library dependencies is easy enough. just read the CMakeLists.txt
21:07:42 <ooo123ooo1234567> <sech1> "moneromooo ooo123ooo1234567..." <- what's the maximum execution time for get_block_template_backlog so far ?
21:10:18 <sech1> looks good so far: https://paste.debian.net/hidden/f6282567/
21:10:26 <sech1> my node is running this PR
21:11:36 <sech1> those timings are for the whole submit_block RPC though
21:12:21 <sech1> 2642086 was a full block with 162 transactions, it took 1.25 seconds
21:21:30 <ooo123ooo1234567> this function is closer to fill_block_template, but it's a bit more dumb since p2pool has more sophisticated internal solver; previously it was greedy and slow backlog fetcher, after patch it will simplified fill_block_template for p2pool specific needs
21:21:59 <ooo123ooo1234567>  * this function is closer to fill_block_template, but it's a bit more dumb since p2pool has more sophisticated internal solver; previously it was greedy and slow backlog fetcher, after patch it will be simplified fill_block_template for p2pool specific needs
22:02:12 <ooo123ooo1234567> <sech1> "2642086 was a full block with 16..." <- that's the same as fill_block_template or very similar, not sure what's the precision of current comparison
22:17:14 <ooo123ooo1234567> <sech1> "those timings are for the..." <- m_txs_by_fee_and_receive_time is in sync, it's what is being used by internal miner during new block template update and called right after miner notifications within blockchain.cpp
22:45:13 <ooo123ooo1234567> sech1, what do you expect from backlog of txs received via zmq ? your code doesn't verify anything except doing optimizations for the best block reward.
22:45:32 <ooo123ooo1234567> s/your/p2pool/
23:07:02 <sech1> what's the point of this question?
23:08:06 <sech1> why p2pool should verify anything?
23:08:08 <ooo123ooo1234567> sech1: if there is an edge case when returned txs can't be combined into block, then is it expected or not expected ?
23:08:26 <sech1> can't be combined why?
23:08:34 <sech1> monerod checks every tx before sending it
23:34:57 <ooo123ooo1234567> <sech1> "can't be combined why?" <- https://github.com/monero-project/monero/blob/master/src/cryptonote_core/tx_pool.cpp#L1548, there are duplicate key images from blockchain (such txs excluded by is_transaction_ready_to_go) and there are duplicate key images within mempool itself, fill_block_template is checking for both, get_block_template_backlog is checking for duplicates relatively to db
23:35:06 <ooo123ooo1234567> > <@sech1:libera.chat> can't be combined why?
23:35:06 <ooo123ooo1234567>  * https://github.com/monero-project/monero/blob/master/src/cryptonote\_core/tx\_pool.cpp#L1548, there are duplicate key images from blockchain (such txs excluded by is\_transaction\_ready\_to\_go) and there are duplicate key images within mempool itself, fill\_block\_template is checking for both, get\_block\_template\_backlog is checking only for duplicates relatively to db
23:35:32 <ooo123ooo1234567> In theory, if p2pool will get 2 double spend txs from mempool such block will be invalid
23:36:42 <ooo123ooo1234567> <sech1> "while we're at it, can someone..." <- indeed, why not to merge ?