03:53:49 <MeowingCat> is there an explaination for Monero's transaction structure?
05:29:13 <MeowingCat> is Monero working with something like UTXOs like BTC????
06:43:26 <moneromooo> There an explaination for Monero's transaction structure somewhere on monero.stackexchange.com. Monero works with UTXOs, yes.
09:23:04 <selsta> mj-xmr[m]: I don't see the point of a testing framework. Doing `time make` with cleared / disabled ccache is as objective as it gets.
09:23:20 <selsta> That's what 99% of users will compile and is what should be optimized for.
09:24:00 <mj-xmr[m]> I don't think you're right on the 1st one.
09:24:01 <mj-xmr[m]> 2nd one: It's for developers, not users. Users compile once a quarter. They don't care.
09:40:38 <selsta> What is unobjective about doing `time make`?
09:46:12 <mj-xmr[m]> https://github.com/mj-xmr/monero-patches/blob/master/src/monero-test-build-time.sh#L6
09:46:17 <mj-xmr[m]> The documentation says it all.
09:47:40 <mj-xmr[m]> Short answer: many things.
09:47:46 <selsta> I will remeasure https://github.com/monero-project/monero/pull/7217, because I might have done something wrong in not enabling tests.
09:58:45 <selsta> how does ninja have an influence on cmake? do you mean make?
10:00:39 <mj-xmr[m]> Yeah. That's a valid finding.
10:00:41 <mj-xmr[m]> Thx
10:01:09 <mj-xmr[m]> Although it's cmake which creates these Makefiles, so...
10:09:25 <Guest21> how can I integrate monero payments in my online shop, I use nodejs ?
10:10:05 <moneromooo> Maybe "monero integrations" has what you want.
10:10:20 <moneromooo> Plugins for some online shop software.
10:10:53 <Guest21> ty I'm gonna check
10:11:13 <mj-xmr[m]> Re: 7217, please do if you wish, especially since my framework takes some 4-8 hours to complete.
10:11:13 <mj-xmr[m]> Re: ninja: it replaces make and Makefiles entirely
10:12:14 <mj-xmr[m]> Re 7217, the expected result is, that the core tests themselves compile ~40-50% faster. So if you can prove it in a matter of 2 hours, it's all fine.
10:14:02 <mj-xmr[m]> The problem with ninja is, that it's incompatible with some exotic improvements, like icecream. But not everybody uses all the improvements at the same time. 
10:14:20 <mj-xmr[m]> The most important part is, that it works with ccache.
10:32:43 <selsta> moneromooo: do you remember what you meant with this comment? https://github.com/monero-project/monero/pull/6097#issuecomment-549979567
10:34:38 <moneromooo> I had to reorder some code to fix... a timing info leak IIRC. In turn, this undid something I had fixed before, which I believe was a subtle race condition with the txpool.
10:35:16 <moneromooo> It was pretty subtle IIRC, and so I needed time to think about how to refix it after the move, and I never got to it. I do not remember the details of the race.
10:35:27 <moneromooo> I don't think I'm likely to ever get to it now.
10:43:41 <selsta> ok ty, i guess i'll let the other decide if we keep the unused variable
10:45:01 <moneromooo> At this point, since it was to remind me, it could be replaced by a comment if people really hate it.
10:51:23 <mj-xmr[m]> Makes sense.
10:51:42 <selsta> mj-xmr[m]: i just checked and ram disk is negligible for measurement on my system. the difference is < 1% for single core compilation
10:53:02 <mj-xmr[m]> OK. Actually for OSX the RamDisk option is still disabled, since I can't test it properly. But for Linux it's fine so far.
11:43:49 <selsta> mj-xmr[m]: interesting that your recommended command ends up being slower https://github.com/monero-project/monero/pull/7217#issuecomment-1144767782
11:45:40 <mj-xmr[m]> Hmmmm. Then either I'm reading it upside down, or you wrote it upside down.
11:46:15 <selsta> I meant RAM disk, -DBUILD_SHARED_LIBS=ON and -DSTRIP_TARGETS=ON
11:46:31 <selsta> it's either -DBUILD_SHARED_LIBS=ON or -DSTRIP_TARGETS=ON that slows things down
11:46:42 <mj-xmr[m]> aaah.
11:46:50 <selsta> strip targets is probably extra work, not sure why you enable it
11:46:51 <mj-xmr[m]> Well it's a mixture.
11:46:57 <mj-xmr[m]> Exactly
11:47:09 <selsta> but it's irrelevant for measurement
11:47:49 <mj-xmr[m]> For this reason:
11:47:51 <mj-xmr[m]> https://github.com/mj-xmr/monero-patches/blob/master/src/monero-test-build-time.sh#L8
11:48:03 <mj-xmr[m]> - Strips symbols off the targets, in order to spare the space on RAMDisk, that would otherwise lead to memory fragmentation or worse: swapping
11:50:03 <mj-xmr[m]> And when you strip in both runs, the negative influence zeroes out. For example, imagine what interference of the same time your simple `make core_tests (with unity)` and `make core_tests (without unity)` has caused, let alone your `make -j8`
11:50:26 <mj-xmr[m]> read: thread starvation.
11:50:31 <selsta> I didn't do -j8?
11:51:39 <mj-xmr[m]> hmmmm. Were you testing it already?
11:52:03 <mj-xmr[m]> Perhaps I sleep too little lately because of a bit too long meetings in Matrix.
11:52:17 <selsta> that previous test run a couple days was incorrect because i didn't compile tests in the first place, that's why i redid it
11:53:02 <mj-xmr[m]> Ah. Thanks for the sanity check.
11:53:08 <mj-xmr[m]> literally.
11:58:10 <HenryHollingwort> is there any reason in particular why `get_address` requires that the subaddress index(s) supplied must be >= the number of labelled subaddresses?
11:58:10 <HenryHollingwort> wallet2.h: size_t get_num_subaddresses(uint32_t index_major) const { return index_major < m_subaddress_labels.size() ? m_subaddress_labels[index_major].size() : 0; }
11:58:10 <HenryHollingwort> wallet_rpc_server: THROW_WALLET_EXCEPTION_IF(i >= m_wallet->get_num_subaddresses(req.account_index), error::address_index_outofbound);
11:58:10 <HenryHollingwort> my use case is that I don't want to 'pollute' my wallet using `create_address` when the part of my program which runs after the create `create_address` is fallible. Basically for each item I am trying to get a subaddress - ideally using the id off the item as the subaddress index
12:02:02 <selsta> HenryHollingwort: are you sure it's >= ?
12:02:29 <HenryHollingwort> https://github.com/monero-project/monero/blob/master/src/wallet/wallet_rpc_server.cpp#L535
12:03:04 <selsta> but that says throw an exception if >= ?
12:03:28 <HenryHollingwort> ah derp i meant to say must be <=
12:03:50 <selsta> it has to be < probably
12:04:20 <HenryHollingwort> basically I'd like to use `get_address` for subaddress index say 65 - when I haven't created subaddresses for indexes up to and including 64
12:05:56 <HenryHollingwort> wow i'm struggling with my inequalities tonight
12:06:30 <selsta> https://github.com/monero-project/monero/pull/6394
12:06:40 <selsta> the CLI wallet has this address one-off command
12:06:51 <selsta> I'm not sure if RPC also supports this
12:08:33 <HenryHollingwort> [wallet 9ssWyM]: address one-off 0 200
12:08:33 <HenryHollingwort> Address at 0 200: BdcYFby3sYXfgBiuv2RWHDUhsoi2v1pETgZLViSbqmox3BFmoJuyyxj9pMkqiH7LBHKyify1wip6Fgf4ymn4JUX3DVNdiQ5
12:08:33 <HenryHollingwort> yep that is perfect 
12:08:59 <HenryHollingwort> I might have a go at adding this to the wallet RPC because AFAKT it doesn't support it?
12:09:20 <selsta> if you add it a PR would be nice :D
12:09:50 <HenryHollingwort> my project can just generate a new address each time it tries to do something - which isn't a roadblock it's just not ideal and then I can have a go at implementing the RPC command
12:10:14 <HenryHollingwort> great :) 
12:10:59 <selsta> mj-xmr[m]: so far I don't see the point of your "test framework", none of the things you listed have a measurable impact (>1%), apart from BUILD_SHARED_LIBS
12:11:29 <mj-xmr[m]> And that's exactly why we need the framework.
12:11:48 <mj-xmr[m]> Why? Because it tells a different story.
12:12:09 <mj-xmr[m]> and I don't want to be accused of "charlatanism" as usual. 
12:14:02 <mj-xmr[m]> And a general remark: I'm not a rookie. Apart from these ill-fated Boost PRs, which were created BEFORE I could do any measurements, from now on whenever I PR something, it does have a measurable impact. Otherwise I wouldn't PR it in the first place.
12:14:45 <mj-xmr[m]> So exercise the possibility, that the problem may be within your measurements, maybe?
12:14:58 <selsta> lol
12:15:45 <mj-xmr[m]> What? Not a chance?
12:22:33 <selsta> I feel like you are overcomplicated something simple. Measuring build time is as easy as it gets. And I gave you the benefit of the doubt by testing every problem you have listed in your test framework (RAM disk, RAM cache influence, dynamic linking, etc.) and all of this has been negligible, as I expected. The only thing that has made a difference is BUILD_SHARED_LIBS but for setting that you don't need a complicated test framework.
12:22:50 * selsta enough testing now, afk again
12:25:21 <mj-xmr[m]> Well, thanks for helping anyway. Appreciate it.
12:25:30 <mj-xmr[m]> *I
12:27:28 <selsta> and I'm not saying that the things you have listed have 0% impact on build time, they do have an impact probably in my testing it's negligible (<1%), so I'm not sure if it's important to concentrate on it now
12:27:47 <selsta> but*
12:28:38 <mj-xmr[m]> <1% would be not worth it, I agree.
12:28:46 <selsta> basically we have to decide if we want to test with or without BUILD_SHARED_LIBS
12:46:14 <mj-xmr[m]> Do you mean running the tests on GH? Then only static, because this is closest to the user experience as possible.
12:46:14 <mj-xmr[m]> Anything else that a Developer typically wants is using approximations of all these User's comfy settings, in order to maybe execute a bit slower, but build a lot faster.
12:46:26 <mj-xmr[m]> So in the Dev's case - shared.
12:56:50 <mj-xmr[m]> afk
13:04:25 <hyc> the main reason static builds are slow is because we use LTO. for debug it's sufficient to turn that off if we want faster static linking
13:05:00 <hyc> but sure, using shared libs could be faster still, since binaries won't need relinking
15:15:48 <mj-xmr[m]> 1) I think static builds are fast enough, even with LTO, if they're done on GH, using ccache. Limiting header interdependencies helps even more, since ccache would be using smaller, more reusable chunks of independent blobs
15:15:49 <mj-xmr[m]> 2) Yes. Especially if one's machine has a slow disk.
15:19:11 <moneromooo> FWIW, ccache does not cache link outputs, just compiled and preprocessed outputs. Unless it changed when I wasn't looking, which is possible.
15:24:12 <mj-xmr[m]> No, it doesn't (or never did). I'm just saying that on GH, the caches are being stored in a relative abundance, since the each new run of master updates and extends the cache.
15:24:36 <mj-xmr[m]> and GH is the typical use case for an statically linked binary + LTO
15:25:13 <mj-xmr[m]> So that advantage of ccache there somehow regularizes the losses made by LTO
15:47:50 <arnuschky[m]> Hey there. Wall of text incoming, apologies in advance. :)
15:48:03 <arnuschky[m]> For those of you that don't know, I am with RINO. Due to our products  nature, we depend on multisig and thus are quite concerned about it's current state. We try to help out where we can, and issued a while ago a $10k bounty for  fixing multisig in the upcoming hardfork.
15:50:29 <arnuschky[m]> As already dicusssed in the dev meeting, another audit of PR #8149 is advisable.  We decided that RINO would commission this review with Inference AG (did Monero audits for CLSAGs, Thorchain, and possibly others). After checking with the folks over at the research lounge, UKoe and the Haveno guys, we decided to put the promised $10k bounty towards this audit. In the interest of time and efficieny, RINO will pick up the rest of the tab
15:50:29 <arnuschky[m]> as well.
15:50:48 <arnuschky[m]> UkoeHB and I met with the auditors and defined the scope of the audit. We addressed some concerns with their Thorchain audit; UkoeHB had some nice suggestions wrt to the scope in order to prevent these kind of oversights in the future. Overall we were satisfied that their audit can improve the trust in PR #8149.
15:51:02 <arnuschky[m]> The contract has been signed and the audit will start on Monday. UkoeHB agreed to collaborate with the auditors to help them in their work - thank you, your work is much appreciated! I hope to receive the final report the week after. Once the audit is finished, we'll share the report with the community.
15:51:22 <arnuschky[m]> A few questions remain to be discussed.
15:51:26 <arnuschky[m]> 1) We're obviously not sure what the audit will yield, so it's unclear to which extend it'll improve trust in the multisig system and whether it's deemed sufficient to enable it again.
15:52:34 <arnuschky[m]> 2) Several people brought up the idea to audit the whole multisig system (via a CCS proposal, most likely). The main issue here is that the multisig system badly designed, badly implemented, and lacking a formal specification. We discussed this potential "big" audit with the guys from Inference AG and it became clear that neither the scope nor the goals are defined enough to estimate cost/effort. Also, Ukoe doesn't seem to see the
15:52:34 <arnuschky[m]> necesscity of one big audit over smaller, incremental fixes/audits (correct me if I am wrong). Overall I would suggest to put this idea aside until we have the results of the audit of #8149, and then rediscuss.
15:52:48 <arnuschky[m]> 3) The current implementation of #8149 will break multisig transaction building pre-hardfork. Not sure how big of a problem that is, but this differs from how hardforks usually work in Monero I think. Ukoe already proposed to fix the PR, but some questions around testing remain.
15:52:57 <arnuschky[m]> ErCiccione suggested that we get together to discuss the multisig situation, maybe already this weekend, at the latest after we receive the auditor's report.
15:55:53 <hyc> #2 sounds like quite a lack. We should get an actual spec written
15:56:34 <hyc> and as for badly designed and badly implemented, while writing the spec we should take the opportunity to fix the design.
15:57:40 <hyc> it sounds like it's all a mess but if the audit from #1 says "doesn't make things worse" I guess that's the best we can expect
15:59:00 <hyc> I don't understand #3. if the 8149 patch is deployed in the next hardfork then it doesn't matter what its pre-hardfork behavior is, does it?
16:00:09 <arnuschky[m]> re #3: just my concern from an operator's perspective. Deploying the new version pre-hardfork (as one is supposed to do) yields a broken software (can't build txes)
16:00:49 <arnuschky[m]> also, any multisig users are desperately waiting for a patch, hardfork or no. The issue prolongs this wait by a month.
16:00:57 <arnuschky[m]> I am obviously biased though
16:01:36 <hyc> I see, yeah, it'll be unusable for a month.
16:02:16 <hyc> but obviously you can keep on using the current release then, if you need it up till the hf occurs.
16:02:31 <arnuschky[m]> re #2: the question is: who is willing to write such a spec? someone would essentially need to a) reverse-engineer the code, b) derive the design, c) fix the design, and then d) fix the code. Lot of work, and I am not sure who can do it. The auditors usually only work on c) and d).
16:03:08 <hyc> who understands what the problems with the current design are?
16:03:15 <kayabanerve[m]> > <@arnuschky:matrix.org> 3) The current implementation of #8149 will break multisig transaction building pre-hardfork. Not sure how big of a problem that is, but this differs from how hardforks usually work in Monero I think. Ukoe already proposed to fix the PR, but some questions around testing remain.
16:03:15 <kayabanerve[m]> > 
16:03:15 <kayabanerve[m]> Multisigs are disabled as of master without a cli flag. I don't personally see this as an issue.
16:03:16 <arnuschky[m]> Theoretically it's definitely the cleanest solution thought - especially as every new fix or audit will do some of the reverse engineering again, and then kinda throw away the result.
16:04:42 <arnuschky[m]> hyc: I think Ukoe knows best. The anonymous author of #8149 had lots to say on the topic, but nobody seems to be able to rate the truth of it.
16:05:24 <kayabanerve[m]> hyc: I personally think the biggest practical issue has nothing to do with the algorithm and is instead the use of unvalidated rpc routes to step it
16:07:00 <arnuschky[m]> UkoeHB mentioned that he knows of 2 issues that need fixing, but as I said he doesn't seem to see the necessity of a "big" audits beyond fixing those issues
16:07:30 <UkoeHB> it's pretty hard to define the boundary of a big audit
16:07:36 <arnuschky[m]> (UkoeHB let me know if I am talking nonsense here, working on the basis of my notes but might have misunderstood)
16:09:19 <UkoeHB> I can provide notes, comments, and outlines about how multisig should work. I don't have time, energy, or enthusiasm to write a spec. Nor do I want to be sucked into doing work that someone else says they will do (like this damn 8149 pr).
16:15:01 <moneromooo> Why is the current non-spec not good enough as a spec ?
16:16:22 <UkoeHB> rbrunner: 8149 only works on testnet
16:16:55 <rbrunner> Ah, you mean, it works only if already forked?
16:17:02 <UkoeHB> yes
16:17:10 <rbrunner> That I did not notice :)
16:17:36 <rbrunner> Yeah, that's a bit unfortunate ...
16:18:39 <arnuschky[m]> Operators have the choice of updating before the hardfork, and not being able to build transaction, or wait to update after the hardfork and be inoperable in the meantime. Either way, it's a forced downtime, which isn't nice.
16:19:42 <rbrunner> Well, but the way things currently look it may well be that #8149 does not make it into the release anyway?
16:20:03 <rbrunner> For lack of final review, at least
16:20:12 <UkoeHB> I'm working on an update so it works with mainnet
16:20:55 <arnuschky[m]> <moneromooo> "Why is the current non-spec..." <- Not sure. A full-spec seems to be a precondition of a "full" audit, which was discussed in the community.
16:21:04 <arnuschky[m]> UkoeHB: awesome. so maybe we should drop this point then
16:21:24 <arnuschky[m]> rbrunner: That's what we're trying to fix with the upcoming audit - though probably not in time
16:22:09 <rbrunner> Yes, release is currently planned for June 16, if I remember correctly. And a bit of testing beforehand would probably be nice :)
16:23:02 <rbrunner> I have also a PR on the way that may miss that deadline, although of course much less important
16:23:24 <kayabanerve[m]> MAGIC was also working on audit prep to some degree, though it looks we got beaten to the punch. If there is later a full audit... We'd still be happy to help there :)
16:27:41 <hyc> since multisig will be disabled by default anyway, I think 8149 should be able to go in
16:32:28 <rbrunner> I think so as well. If UkoeHB manages it to get working on mainnet pre-fork in the next few days, merge the damned thing. It works.
16:40:55 <kayabanerve[m]> It can't be worse than what we have :p
16:41:13 <kayabanerve[m]> So with disabling by default, I see absolutely no reason it shouldn't be optimistically included in the next release
16:41:35 <kayabanerve[m]> Either it is broken and we need to update or it's fine and...
16:42:04 <kayabanerve[m]> Though I'm not advocating for merging the current PR. koe would need to comment is ready, albeit unaudited, under these criteria
16:44:22 <rbrunner> Think positively: Bad people don't have to go to extraordinary lengths and try to find exploits in Monero multisig. Make an NFT, people will throw money at you, finished :)
17:38:19 <UkoeHB> moneromooo: I'm trying to debug core tests but it doesn't want to read the input commands: Failed to parse arguments: unrecognised option '--generate_and_play_test_data --filter *multisig*'
17:40:33 <UkoeHB> ok got it: "args": ["--generate_and_play_test_data", "--filter=*multisig*"] damn syntax 
17:43:17 <moneromooo> You probably also want \*multisig\*, it won't do what you want if you have a file matching *multisig* in ..
17:43:59 <moneromooo> Also, it looks like it's somehow parsing it as a single option for some reason. Did you put the whole inside "" ?
17:47:24 <UkoeHB> this is in vscodium's handy debugging framework - it's a json file that passes stuff to lldb (so it has annoying syntax nuances I guess)
17:48:01 <UkoeHB> at the command line you need escape characters
18:07:12 <UkoeHB> arnuschky[m]: rbrunner ok pushed a new commit that should work on master/stagenet (core tests and functional tests do not cover this)
18:10:22 <rbrunner> Wow, that was fast.
18:10:38 <rbrunner> Will try tomorrow with stagenet
18:10:50 <UkoeHB> im not a zoomer... born too soon?
18:29:00 <arnuschky[m]> <UkoeHB> "arnuschky: rbrunner ok pushed..." <- oh wow, that was fast! thanks, we'll go test the shit out of it and get started on integration work (monero-js and monero-cpp afaik)
19:49:00 <ooo123ooo1234567> <arnuschky[m]> "UkoeHB and I met with the..." <- "We addressed some concerns with their Thorchain audit" is it private info ?
19:58:25 <ooo123ooo1234567> <arnuschky[m]> "As already dicusssed in the..." <- Inference AG didn't do audit for CLSAGs.Advisor of Inference AG (JP Aumasson) was involved into CLSAG audit, but not actual workers of Inference AG. Check names of Thorchain audit and CLSAG audit.
20:02:56 <ooo123ooo1234567> <arnuschky[m]> "I think Ukoe knows best. The..." <- Indeed, nobody
20:28:48 <ooo123ooo1234567> <arnuschky[m]> "I think Ukoe knows best. The..." <- if you all stopped pretending that you understand something in area where you don't, everything would be much simpler. I think you will just learn hard way that you've thrown away 10+k $
20:28:49 <ooo123ooo1234567> hahahaha
20:56:26 <ooo123ooo1234567> <rbrunner> "I think so as well. If UkoeHB..." <- Are you advocating for another blind merge ?
21:11:43 <UkoeHB> ooo123ooo1234567: " is it private info ?" -> Failure to consider validating preconditions as in-scope (which it should be). I had them add a clause to the scope about preconditions, so if anything goes wrong with the audit that falls under that clause, there won't be any ambiguity.
21:25:56 <ooo123ooo1234567> <UkoeHB> "ooo123ooo1234567: " is it..." <- What's about already prev audit ? Are they going to compensate somehow their big overlook in prev audit ?
21:26:03 <ooo123ooo1234567> s/What's about already prev audit ?//
21:28:02 <kayabanerve[m]> ooo123ooo1234567: Which was...?
21:30:15 <ooo123ooo1234567> kayabanerve[m]: https://gitlab.com/thorchain/tss/monero-sign/-/blob/master/src/wallet/wallet2.cpp#L7285
21:30:38 <ooo123ooo1234567> I don't trust people that blindly approve PRs, but these even claimed to do proper audit and failed. I can't understand it.
21:42:23 <kayabanerve[m]> I was more asking what in that function was broken which they missed
21:42:51 <kayabanerve[m]> And while I know they reviewed thorchains edits, which would've been over the historical multisig, if their scope was just the edits...
21:43:30 <kayabanerve[m]> Though I wouldn't be surprised to hear Thorchain has bad code, I've been saying so myself for a while and submitted a few crits to their WIP XHV work.
21:44:12 <kayabanerve[m]> I also wouldn't be surprised to hear an auditor missed something. Plenty do. I'm curious what specifically they missed, as I did know they had an audit for the edits to monero for thorchain
21:49:39 <ooo123ooo1234567> <kayabanerve[m]> "I also wouldn't be surprised..." <- You're lowering quality bar when saying "missed something. Plenty do.".  I'm sure there is certain reason that audit was shitty. But I can't debug it since I don't have access to info
21:51:42 <kayabanerve[m]> So you said they had a "big overlook" and cited this function definition. Unless you can say what they overlooked, you can't say they overlooked something
21:51:46 <kayabanerve[m]> Their audit report is public
21:52:29 <kayabanerve[m]> I'm also not justifying them because I'm saying a lot of auditors do make mistakes. I'm saying there's a lot of bad auditors and I wouldn't be surprised to hear they're one of them, because statistically...
21:58:30 <ooo123ooo1234567> "https://github.com/monero-project/research-lab/issues/100" how would you describe progress on this ?
21:58:52 <ooo123ooo1234567> stopped / abandoned / slowly progressing / undefined ?
22:00:45 <ooo123ooo1234567> <kayabanerve[m]> "I'm also not justifying them..." <- someone here is doing the next audit with that Inference AG, while you're saying "I'm not justifying them", "there's a lot of bad auditors"; I can't understand this inconsistency 
22:01:48 <kayabanerve[m]> Not a priority for me. I've previously tried letting you know why your conversations are seen as frequently antagonistic and unproductive. To try again, if we're discussing X, and have somewhat opposing view points, and then you ask about Y which is a lack of progress, it feels like an ad hominem attack in bad faith. You truly need to contextualize your statements.
22:02:02 <kayabanerve[m]> You haven't provided any evidence they're bad
22:02:24 <kayabanerve[m]> There are a lot of bad auditors. I wouldn't be surprised if they were bad. Do you have evidence they are or not?
22:02:44 <kayabanerve[m]> Without such evidence, I will default to RINO's review and wait to see the audit.
22:03:34 <ooo123ooo1234567> kayabanerve[m]: Did you encounter some obstacle or just stopped due to other tasks with higher priority ?
22:04:53 <ooo123ooo1234567> kayabanerve[m]: I don't see any reason to continue talk about audit, since I don't agree with you and you don't want to debate about it. That's why I've asked about something interesting for me and similar to prev topic and you.
22:05:45 <selsta> kayabanerve[m]: we discussed it in #monero-research-lounge a week ago or so, https://gitlab.com/thorchain/tss/monero-sign/-/blob/master/src/wallet/wallet2.cpp#L7285 is vulnerable to the same issues that are fixed 8149, and they were in scope
22:06:31 <kayabanerve[m]> Got it. That would absolutely be critical and means they did not handle that competently at all
22:06:46 <kayabanerve[m]> I assumed their audit was specifically based on the API functions added per the segments I read
22:06:59 <ooo123ooo1234567> kayabanerve[m]: I thought that you're communicating with UkoeHB and knew it already. Hmm, strange
22:07:29 <kayabanerve[m]> selsta: no, I was right
22:07:31 <kayabanerve[m]> > The client requested a review of the changes introduced by the thor_monero_signing_parallel
22:07:31 <kayabanerve[m]> branch in the thorchain/tss/monero-sign repository. The code was forked from github.com/monero-
22:07:31 <kayabanerve[m]> project/monero at commit cb70ae94.
22:07:54 <kayabanerve[m]> This was solely the changes introduced by thorchain. It was not their responsibility nor scope to check the actual algorithm
22:08:38 <kayabanerve[m]> So unless their changes re implemented the underlying algorithms, and that's why they're also vulnerable to 8149 AND in scope...
22:09:06 <UkoeHB> a scoping debacle, as I have long argued... if scope is properly defined then it's easier to set expectations and identify failures
22:09:58 <kayabanerve[m]> <ooo123ooo1234567> "Did you encounter some obstacle..." <- It has a large amount of plumbing which is why I wanted to move the proof of concept to halo 2, as the ecc offers elliptic curve ops and hash functions for it. I have multiple other prioritized items, unfortunately
22:10:30 <kayabanerve[m]> I personally think it's completely fine to say we didn't touch monero code and assume it's fine. We only did these rpc routes
22:11:26 <kayabanerve[m]> So unless the rpc routes explicitly open issues, I don't believe the audit is at fault
22:11:54 <kayabanerve[m]> And I'd have to review the routes they added myself accordingly, as it isn't really just routes. It coordinates the process as a whole
22:12:33 <kayabanerve[m]> <ooo123ooo1234567> "I thought that you're communicat..." <- I did know multisig was critically flawed. The part I was responding to was those issues being in scope
22:12:58 <kayabanerve[m]> Based on what the audit says however, they weren't
22:13:20 <kayabanerve[m]> Though I do hate discussing thorchain D:
22:13:23 <selsta> I'm quite sure they did whitespace changes making it technically in scope but I'd have to look up the chat backlog from -lounge.
22:13:32 <selsta> but yes discussing this again now doesn't help
22:13:57 <selsta> things can't get worse with the audit, if it's worth the funds will be seen
22:14:06 <kayabanerve[m]> selsta: The changed whitespace itself was fine though :p it's just what is directly next to which isn't
22:14:14 <kayabanerve[m]> Though I do love the technicality
22:15:02 <kayabanerve[m]> I'll try to read up on that myself. The contract is signed so unfortunately this decision has been made. The monero community can review the audit and debate its competency
22:15:32 <kayabanerve[m]> I personally believe we should merge when koe agrees, yet before the next release, purely because it can't be worse. The question solely becomes the experimental flag
22:16:42 <ooo123ooo1234567> kayabanerve[m]: How do you prevent internal conflict due to your own project ?
22:16:58 <ooo123ooo1234567> Just interesting, how it works
22:17:07 <kayabanerve[m]> My potential conflict is a completely separate codebase
22:17:39 <kayabanerve[m]> I actually am disincentivized from monero having a working multisig lol
22:17:44 <kayabanerve[m]> *if you want to argue that
22:17:47 <UkoeHB> It would probably be best to leave the experimental flag until a proper model can be published (if that ever occurs), and the code validated with respect to the model.
22:18:08 <ooo123ooo1234567> kayabanerve[m]: Yes, that's what I'm saying
22:18:12 <ooo123ooo1234567> s/saying/seeing too/
22:18:20 <kayabanerve[m]> I'm also a monero community member who's submitted exploits to our multisig work and think multisig is incredibly important, who benefits from the theory being understood
22:18:24 <UkoeHB> Although from one point of view, the monero protocol itself is 'experimental', since there is no formal model for the entire thing.
22:18:35 <selsta> UkoeHB: "best to leave the experimental flag" <-- agree
22:18:49 <ooo123ooo1234567> kayabanerve[m]: which one ?
22:19:08 <kayabanerve[m]> My stance is one which ensues it's ready when it's ready and potentially voids the need for yet another release
22:19:58 <kayabanerve[m]> UkoeHB: I'm waiting to see the immediate audit, but I'm currently leaning towards secondary audits as discussed this morning
22:20:43 <kayabanerve[m]> I do agree the experimental flag should remain though :) Just want to be verbose and clear on that as it's being brought up I could be working against monero :O
22:21:20 <UkoeHB> Btw ooo123ooo1234567 speaking of progress, where the hell is your progress report? All I have seen is you being a toxic ass for months.
22:21:41 <MajesticBank> multi-sig is very important and will be used a lot
22:21:52 <ooo123ooo1234567> UkoeHB: progress report for what task ?
22:24:54 <ooo123ooo1234567> UkoeHB: period of unpleasant talk started from "https://libera.monerologs.net/monero-dev/20220507#c92654", it's even less than 1 month, so not months
22:25:18 <selsta> felt like months tbh
22:28:01 <ooo123ooo1234567> <kayabanerve[m]> "I'm also a monero community..." <- do you mean burning bug or something else ?
22:28:51 <kayabanerve[m]> UkoeHB: is there an issue disclosing here? I think it already was tbh
22:29:06 <kayabanerve[m]> selsta: It is exhausting :(
22:29:16 <UkoeHB> No, you being a toxic ass started in December when you ignored my messages about PR 8149 and disappeared. How about progress on anything? I'm not your task manager, why don't you find something useful to do instead of being so unbearable.
22:31:38 <ooo123ooo1234567> UkoeHB: Do you remember at least 1 msg from me which you may consider as toxic without any reason ?
22:31:58 <ooo123ooo1234567> * without very good reason
22:33:00 <ooo123ooo1234567> ignoring is at least less painful, than writing criticism directly, which I've postponed until I've solved problem by myself, so that I'm 100% what I'm talking about
22:36:18 <selsta> just curious, what happens in such an audit contract when issues are missed?
22:36:36 <kayabanerve[m]> Generally nothing
22:38:37 <ooo123ooo1234567> kayabanerve[m]: yes, nothing, the same as in any other rewarding system (current monero environment) without verification
22:39:15 <ooo123ooo1234567> * without verification and competition
22:39:23 <selsta> but if you can verify if an audit is correct, do you need the audit in the first place?
22:39:33 <selsta> complete*
22:39:54 <kayabanerve[m]> Wait till we discuss bit flips from radiation :(
22:40:32 <kayabanerve[m]> Formalizing the algorithm would enable complete verification of the theory. Then an audit is solely on if the algorithm is matched and if it leaks data while doing so
22:40:57 <kayabanerve[m]> So nothing is ever complete, yet there's a reason such a step was noted and why is relevant
22:41:04 <kayabanerve[m]> s/is/it's/
22:42:11 <ooo123ooo1234567> kayabanerve[m]: No. Define quality bar for audit. If it's too low then go to do it yourself. if it's too high then ask others to do it. Currently it looks like bar is too low, so it's more profitable to do useless audits, then to rely on them.
22:43:03 <selsta> we don't know yet if the audit will be useless
22:46:21 <MajesticBank> wrap CSS
22:46:38 <MajesticBank> everyone will be using multi-sig
22:47:03 <MajesticBank> probably just hard to find right company
22:52:42 <kayabanerve[m]> <ooo123ooo1234567> "No. Define quality bar for audit..." <- I've reviewed worthless audits. PirateChain had one at a conference, which I don't say to accuse piratechain of on purposely getting one, yet as a literal fact. No issues anywhere, not even minor. I will not hesitate to review the audit, continue my own reviews of the code, and discuss it here
22:53:03 <kayabanerve[m]> But unless we shadow the process entirely, we have to wait to do that. We don't have the audit yet
22:53:38 <kayabanerve[m]> <selsta> "we don't know yet if the audit..." <- It can't hurt. We can review its competency when we see it. RINO made this decision. It's not a Monero decision. It's solely a discussion we're having.
22:55:00 <kayabanerve[m]> MAGIC is continuing its work on its platform, and we wanted to host audit funding for multisig, believing it was a solid fit. After this much discussion, it sounds like that consideration shouldn't be striked, not that I'm making any guarantees on behalf of MAGIC, and we should be discussing a second audit by a community agreed upon group
22:55:23 <kayabanerve[m]> I'd also be curious what UkoeHB: thought of the auditors cryptography talent based on their discussions
22:55:46 <ooo123ooo1234567> kayabanerve[m]: "cryptography talent" facepalm
22:57:04 <kayabanerve[m]> K, you still haven't posted anything and the most recent discussion here was a scope issue which had them in the clear. I was PMed something that was flawed yet supposedly in scope, and I'll review that when I can, yet I'm out right now and the diff isn't feasible to parse from a phone
22:58:09 <ooo123ooo1234567> kayabanerve[m]: false assumption of safety may hurt
22:58:32 <kayabanerve[m]> It did sound like they missed something crit, and in scope, suggesting that no, they're not the best part for this, at which point koe could comment if they've changed/assigned competent people this time, or if he believes this audit shouldn't be planned upon and monero needs to continue establishing its own review process, including formalization and an audit.
22:58:34 <selsta> we don't assume safety based on this audit
22:59:16 <kayabanerve[m]> It explicitly sounds like this audit will be a discussion point of a much lengthier conversation at this point. The immediate question would be who wants to formalize the multisig protocol
23:00:13 <kayabanerve[m]> Beyond the pure math of it, I would hope to see data flow also formalized. Certain random values were moved to a hash chain. That's perfectly secure, yet then the question becomes how are we deriving other random values.
23:00:37 <kayabanerve[m]> Etc
23:07:14 <ooo123ooo1234567> <kayabanerve[m]> "UkoeHB: is there an issue..." <- answer to this ?
23:08:49 <selsta> https://github.com/monero-project/monero/pull/8149#issuecomment-1114060387
23:08:52 <selsta> this was disclosed
23:10:15 <ooo123ooo1234567> What's the next date for hardfork in case if current master will be released as is ?
23:10:19 <ooo123ooo1234567> 6+ months / 12+ months ?
23:35:23 <ofrnxmr[m]> <ooo123ooo1234567> "What's the next date for..." <- Likely when enough or important enough changes require