04:10:11 <sythaeryn_aerie[> Hi! Is it possible to create a visual studio solution for monero-gui and compile it with MSVC?
07:04:24 <selsta> sythaeryn_aerie[: you can try it, cmake allows you to create a visual studio solution
07:04:38 <selsta> but there is no support for it if it doesn't work
07:07:05 <selsta> https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html
09:03:23 <sythaeryn_aerie[> <selsta> "sythaeryn_aerie: you can try it,..." <- thanks! I think I need some slightly more detailed steps how to make cmake generate a Visual Studio solution for the monero project. I am an experienced C++ programmer, but primarily with game development, so I spent my whole life in the windows ecosystem, where I only had to care about C++ in Visual Studio. I'd like to contribute to Monero, and I think I'd be able to quickly get
09:03:23 <sythaeryn_aerie[> into most of the code, but I'd also like to keep using the tools I know best, being Visual Studio and all its related tools. are any of the monero devs using visual studio or is that something unusual?
09:04:09 <hyc> none
09:04:51 <hyc> everything is built with either gcc or clang toolchains
09:04:57 <selsta> on Windows mingw64 is used
09:05:14 <hyc> everything is built from bash shell
09:05:53 <hyc> for main CLI build we don't even use mingw64 anymore, we just cross-compile from linux
09:07:27 <sech1> I'm using Visual Studio
09:07:49 <sech1> So p2pool supports VS. But yes, Monero tools don't support it
09:08:25 <hyc> they might. cmake might work. but nobody has bothered to check, and nobody will care if it doesn't.
09:10:00 <sech1> VS supports clang toolchain, so in theory it could work. But you'd need to find all dependencies too.
09:10:49 <hyc> waste of time. Windows as a base OS is so much slower than Linux it kills productivity
09:12:57 <sythaeryn_aerie[> hyc: I am never slowed down by my OS in any way, so I think that statement doesn't really make sense. there are obviously a huge amount of programmers who use windows every day. I'm not a Microsoft fan at all, but they know one thing, and that's how to make good tools for developers, because that's obviously what they need themselves.
09:13:09 <sech1> I wouldn't say so. After a proper tuning, XMRig is faste on Windows for me. GUI differences are a matter of taste
09:13:51 <sech1> yes, VS is very good for developers
09:14:01 <hyc> no, I'm talking about basics like file I/O
09:14:12 <hyc> NTFS is a shitty slow filesystem
09:14:28 <hyc> the Windows memorry manager sucks, manages cache poorly
09:14:49 <hyc> tools are whatever they are, but it's just lipstick on a pig
09:15:40 <sech1> can't comment on file I/O, I don't run file servers :D
09:16:12 <sech1> sythaeryn_aerie try cmake .. -G "Visual Studio 16 2019" -T ClangCL -A x64
09:16:15 <sythaeryn_aerie[> most open source projects make it easy to get a visual studio .sln generated to make it easy for anyone to contribute who likes to simply use VS. I think it would be good if Monero would try to do the same. making it as easy as possible for people like me to help the project. I'm sure there's a lot of people like me who know C++ very well but are primarily working on the windows side of things and might not be familiar with the
09:16:15 <sythaeryn_aerie[> toolchain Monero is setup around
09:16:21 <sech1> it should create clang project for VS
09:18:03 <sech1> actually I'll try it right now. Need to install C++ clang tools for VS first.
09:19:39 <sythaeryn_aerie[> sech1: thanks!
09:22:44 <hyc> you sound like a spoiled child. "your open source project that doesn't use any of the tools I'm familiar with should bend over backwards to add support for my tools"
09:23:47 <sech1> yeah, cmake didn't work. It can't find dependencies, so it will take a while to even make it generate .sln
09:29:29 <sythaeryn_aerie[> <hyc> "you sound like a spoiled child...." <- I'm sure you'd agree that for an open source project it's quite ideal when the barrier to entry for any skilled programmer who wants to help is as low as possible and everyone can use their favorite tools for the job, because what matters is the code that's written and not what tools or OS someone uses for it. visual studio is very popular and there are a lot of C++ programmers who use
09:29:29 <sythaeryn_aerie[> it every day for their work, so I am sure long-term it would bring many new contributors to the project if they could easily contribute using the tools they are used to. and that's something everyone would benefit from.
09:32:32 <hyc> beside the point. the project is driven by volunteers. if nobody on the project uses <your favorite tools> then who has the responsibility to learn how to integrate your toolchain?
09:32:54 <hyc> who has the time to do the work? who has the time to maintain it, when nobody uses it?
09:33:36 <hyc> and it's more than just "the code" since there are subtle differences in header files and supported APIs between MSVC and gcc/clang
09:36:11 <sythaeryn_aerie[> since Visual Studio seems to work fine with clang too, MSVC support might not be relevant, clang alone should be fine. as long as I could use the visual studio tools, I'd be happy.
09:36:26 <hyc> great, make yourself happy.
09:36:33 <hyc> it's nobody else's job to do things for you.\
09:52:16 <sythaeryn_aerie[> <hyc> "great, make yourself happy." <- I'm not sure why you're so salty. I have come here because I'd like to contribute to Monero in my free time - I have not asked you to do anything for me. Visual Studio is the most popular development tool for C++, and I personally am sure it would benefit the Monero project a lot long-term to make it easy to use for Monero development. just my opinion. you are obviously free to disagree and
09:52:16 <sythaeryn_aerie[> just ignore my thoughts on it.
09:53:48 <hyc> ... you have asked "someone" on the project to add support for your tools, that nobody on the project uses
09:54:11 <moneromooo> It's just how hyc is, straight to harsh :D It's a bit annoying but there's not going to be a change there.
09:54:24 <hyc> a good open source developer understands that if you want something done, you do it.
09:54:46 <moneromooo> My own opinion is that if you can make it work with minimal changes, why not. But it it's more than a few #defines, not worth the bother.
09:55:30 <moneromooo> If you want to add a MSVC project file to the repo though, you'd have to maintain it, or it'll get removed.
09:55:44 <moneromooo> (or find some other rube to maintain it :P)
09:58:09 <hyc> if you think it'll be such a great boon to the project but you can't be bothered to do it yourself, then certainly no one else on the project will be motivated to do it
09:59:01 <spirobel[m]> so you guys mostly use codeblocks atm?
09:59:04 <moneromooo> Did they ask for someone else to do it ? 
09:59:42 <hyc> they keep saying it would be great to have it - but are they expecting it to magically appear?
09:59:51 <hyc> no. for it to appear, someone has to do the legwork.
10:00:16 <moneromooo> But they said they wanted to work on monero. Sounds like a "I could start with that" to me.
10:01:26 <hyc> and again, "great, make yourself happy"
10:02:46 <spirobel[m]> so what is the official "monero core team certified ide"? codeblocks, vim or emacs?
10:03:09 <leonarth> do you guys know if there's a way to extract the daily transactions on my wallet and create a daily report of all in/out
10:05:42 <moneromooo> Yes, see src/wallet/*defs.h (or utils/python_rpc/framwework)
10:07:18 <sythaeryn_aerie[> <moneromooo> "But they said they wanted to..." <- I'd love to, but unfortunately that's not really something I could start with - the main work there seems to be "making cmake happy" and that's outside of my area of expertise
10:07:21 <leonarth> thank you moneromooo 
10:08:13 <hyc> the wallet rpc lets you constrain by block height. not by date.
10:08:39 <hyc> so you'd need to keep a side record of the last height you checked before
10:12:37 <moneromooo> I think there might be a new RPC to get a height from a date.
10:12:51 <hyc> that's only an estimate
10:13:05 <hyc> not sure how well it overlaps for consecutive dates
10:13:33 <moneromooo> But in any case, if you get the txes, you get the timestamps anyway, so you can bin them then.
10:14:15 <moneromooo> True, it's not actually monotonous...
10:15:47 <sech1> sythaeryn_aerie your best shot is to try configure VS Code to use mingw64 toolchain because clang toolchain on Windows is also not supported
10:16:12 <leonarth> you then suggest to extract all txs which returns me an obj w/ containing the dates, then I can filter by day and sum all amounts
10:16:55 <leonarth> and I can do that via the RPC API calling into monerod
10:18:11 <sech1> sythaeryn_aerie or just install msys2/mingw64 and follow the build instructions. I personally couldn't make Visual Studio Debugger work with it on Windows, and it's not the first time I tried
10:18:14 <moneromooo> Either monerod (for all txes) or monero_wallet_rpc (for just that wallet's txes).
10:18:22 <sech1> for text editor, VS Code will be just fine
10:19:10 <hyc> I've never seen anything re: cross-compatible debug formats
10:19:19 <leonarth> can I query monerod to return all txs pertinent only to my wallet address?
10:19:22 <hyc> so no, should not expect that to ever work
10:19:47 <moneromooo> Yes, if you have the txids.
10:20:13 <moneromooo> But you can't tell the daemon "get me txes to or from address 4xxx", that'd defeat hte point.
10:20:15 <leonarth> those need to be extracted from the wallet still
10:20:25 <leonarth> I understand thank you moneromooo 
10:21:03 <leonarth> can the wallet be setup on a server in read-only?
10:21:22 <hyc> yes, that's a view-only wallet
10:21:23 <moneromooo> Yes.
10:21:52 <leonarth> thank you guys for the info
10:22:46 <sythaeryn_aerie[> sech1: since I am a C++ programmer spending a lot of time using tools like the Visual Studio Debugger and Visual Studio Profiler usually, I don't think I'd enjoy working on a C++ project without having access to those tools...
10:32:31 <spirobel[m]> <leonarth> "can I query monerod to return..." <- I think working with wallet_rpc or some other wallet related api is probably best. Here is how monero gui does it: https://github.com/monero-project/monero-gui/blob/edb0358916de455a72aa30eff63eb49aba6ee392/src/libwalletqt/TransactionHistory.cpp#L82  it imports from wallet2_api https://github.com/monero-project/monero/blob/master/src/wallet/api/wallet2_api.h
10:35:18 <hyc> ^ that's one of the biggest problems with working with M$ tools. they don't support open standards (like DWARF debug info) and they don't publish specs of their PDB format to enable open source projects to support theirs.
10:35:29 <sech1> sythaeryn_aerie I understand, I myself work mostly in VS (both at work and in my own projects). You can try to check out p2pool first, it supports VS. It's not so hard to work with Monero codebase once it's set up in msys2/mingw64
10:36:41 <sech1> hyc while VS tools are excellent, I agree on this point. M$ tries to lock users to their ecosystem and are often successful
10:42:05 <spirobel[m]> <sech1> "hyc while VS tools are excellent..." <- but VS code is fine. it is open source. But visual studio is still closed source right? the naming is so confusing. It is so similar.
10:42:14 <spirobel[m]> s/but//
10:43:54 <sech1> VS code is just a text editor with tons of plugins
10:44:15 <sech1> Maybe you can set it up to be comfortable, but 99% you won't be able to use VS debugger with the Monero codebase
10:45:12 <sythaeryn_aerie[> <sech1> "hyc while VS tools are excellent..." <- one good thing is that MSVC has become a lot more standard compliant in recent years
10:46:47 <hyc> you can barely use any debugger with the monero codebase on windows. the object file format blows up from all the symbol data
10:46:50 <leonarth> thank you spirobel[m] 
10:48:45 <sythaeryn_aerie[> hyc: I don't quite understand why? what's the issue there? obviously big projects like Chromium can be debugged fine on Windows. Monero is not "bigger" I'd assume?
10:49:15 <hyc> there's a limit of something like 32768 symbols per object file
10:49:48 <sythaeryn_aerie[> my main work is with Unreal Engine 4 code. which is also a huge codebase.
10:50:05 <hyc> and with the wild overuse of templates, boost, and other C++ syntactic garbage, many of the object files hit that limit\
10:50:27 <hyc> I recall the only thing that worked reliably was the PSDK debugger
10:54:31 <sythaeryn_aerie[> hyc: is that some issue related to the toolchain used or something? as I said I don't have any experience with non-windows projects, but at least with VS and MSVC I've never, ever heard of there being any project running into something like a 32768 symbols limit for debugging or something similar
10:54:37 <hyc> it may be this was only an issue on the 32bit builds. I don't remember now
10:55:06 <hyc> and we ought to be phasing out 32bit builds soon anyway
10:56:05 <hyc> yeah, this was an issue with gcc/gdb and COFF object files. Since MSVC uses PDB it probably didn't affect that
10:59:24 <sech1> speaking of, PSDK debugger? I've been using debug printf so far :D it would be nice to have working debugger on Windows
10:59:44 <hyc> well, it's asm-level only, but yeah. microsoft debugger
11:00:10 <sech1> asm-level only works perfectly fine in VS too
11:00:18 <sech1> just attach to the running process and open ASM view
11:00:24 <hyc> https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools
11:00:26 <hyc> WinDbg
11:00:31 <spirobel[m]> <sythaeryn_aerie[> "is that some issue related to..." <- maybe this can be an opportunity for you to learn about linux and the toolchains there. Using one ide too much can also become a crutch. 
11:00:41 <sech1> ah, WinDbg
11:02:17 <sech1> spirobel true. Even at my work, where it's mostly VS and Windows, we use quite a bit of clang and linux toolchains for server-side tools
11:02:42 <sythaeryn_aerie[> I find it hard to imagine how I could debug my own code without having access to the VS debugger, only having to reply on stuff like prints.... I'd think that would make everything take 10x longer and be way less fun. it's just deeply engrained in my workflow to use all the VS tools. I love to have access to the VS profiler and easily see how much time every individual line of code takes to run too. and having a quick and easy
11:02:42 <sythaeryn_aerie[> right click -> go to disassembly to judge what exactly the compiler is doing and if I'm happy with that
11:03:41 <sythaeryn_aerie[> spirobel[m]: problem is I'm really happy with the workflow I'm used to and I love writing C++ code but I don't love learning about toolchains and stuff, so it would be quite hard to motivate me to spend time with something like that... and I'm already busy with enough projects anyways
11:05:06 <sech1> "to judge what exactly the compiler is doing" gcc toolchain can do that too, you can compile a single cpp file into .S asm file and check it out
11:05:37 <sech1> also, if the code you write is self-contained, nothing prevents you from doing it in VS and then just plugging it into the Monero codebase
11:08:03 <sythaeryn_aerie[> sech1: if there would be anything so self contained that would be useful, yeah
11:08:12 <moneromooo> ^ good point there
11:08:15 <sythaeryn_aerie[> if no one has ever been able to run the monero code through the VS profiler, I'd really love to be able to do that... I'm sure it would easily identify many potential optimizations
11:08:32 <sech1> anyway, you can start with https://github.com/SChernykh/p2pool#windows-1 - p2pool is not part of Monero codebase, but it's tightly integrated. At least you could learn how to use RPC and ZMQ interfaces
11:10:24 <sech1> Monero code was run through the profiler (not VS) before
11:10:40 <sech1> some parts are optimized (like Supercop crypto library)
11:13:46 <moneromooo> Something like bulletproofs might be easy-ish to extract to build with whatever tools you like, including that profiler. Speeding those up even more would be nice.
11:22:53 <sech1> That's not a good starting point :D Any change in bulletproofs has a potential for infinite money glitch :D
11:25:35 <moneromooo> There are tests and reviews.
11:29:21 <sech1> true, but optimizing bulletproofs requires deep knowledge of the underlying math, and what the code in bulletproofs.cc does is just calling low-level crypto functions
11:30:21 <moneromooo> I optimized it without knowning much of the math :P
11:30:24 <sech1> it uses functions from monero\src\crypto\crypto-ops.c as far as I can see. Optimizing those would be nice
11:30:52 <sythaeryn_aerie[> <moneromooo> "Something like bulletproofs..." <- often the code that people know should be fast is already quite fast, and the most significant improvements can be had from code that people did not consider too relevant for the overall speed of the program before which is then only noticed by profiling
11:30:57 <sech1> I'm talking about optimizations like this: https://github.com/monero-project/monero/commit/4ed60b626a368132fccad4449f1c4d50e312b60c#diff-52bc06cbdd63ac7e0d5300f4b17cc75da111f6dc24ac262ea1439352fb81c5b8
11:30:59 * moneromooo looks at several people rush to their editor with anguished looks
11:31:23 <moneromooo> Those are already the optimized supercop code, no 
11:31:24 <moneromooo> ?
11:31:42 <sech1> crypto-ops.c?
11:31:48 <moneromooo> If not, then I agree, it'd be a very good target.
11:32:00 <sech1> I'm still not sure where supercop is actually used
11:32:10 <sech1> I think it's only for wallet scanning
11:32:19 <moneromooo> Also, the person doing the profiling/sorting needs not be the one to do the speedups.
11:32:55 <sythaeryn_aerie[> moneromooo: that's true, yeah
11:35:22 <sythaeryn_aerie[> but often finding out what code needs to be optimized more is actually more work than doing the optimizations :P
11:36:03 <sythaeryn_aerie[> unless stuff is already super optimized
13:09:53 <selsta> sythaeryn_aerie[: maybe you can do a review of this PR? https://github.com/monero-project/monero/pull/8046
13:10:22 <selsta> it's wallet optimization related
13:47:56 <Rucknium[m]> sythaeryn_aerie: Please join #monero-recruitment:monero.social 
14:24:13 <selsta> moneromooo: there are some new review comments here https://github.com/monero-project/monero/pull/7819
14:24:28 <moneromooo> Thanks
18:15:18 -xmr-pr- woodser opened issue #8168: Don't require --rpc-login with --rpc-access-control-origins
18:15:18 -xmr-pr- > https://github.com/monero-project/monero/issues/8168
18:48:28 <UkoeHB> sythaeryn_aerie[: if you want toolchain support improvement, you could create a bounty for it (a bit more motivating than 'please do this work for me for free')
21:11:23 <Guest36> would it be possible to add privacy-preserving scripting to monero using zk proofs?
21:12:19 <UkoeHB> maybe? lol
21:15:37 <Guest36> like, have all the utxo's pay to a hash of a script, and then when spending the uxto the spender would create a zk-proof that they a) have a script that matches the hash in the utxo they're consuming, and b) their transaction fulfills the conditions in the script
21:17:07 <Guest36> you may notice that this removes stealth addresses an subaddresses. I'll soon explain how to add them back in, if someone can confirm that my idea has any merit.
21:19:22 <UkoeHB> are they trustless setup?
21:20:46 <Guest36> I haven't actually implemented anything. this is purely my speculation >:D
21:21:38 <UkoeHB> is it theoretically, a trustless setup?
21:21:51 <Guest36> yes
21:21:56 <Guest36> i guess?
21:22:20 <UkoeHB> guess? isn't that kinda important?
21:22:44 <Guest36> it probably would be possible to create a zk-proof that does this and is trustless.
21:23:11 <Guest36> if not, we shouldn't implement this
21:24:26 <Guest36> you're the zk wizard, what do you think?
21:25:15 <UkoeHB> wizard? um all I know about is Monero ^.^
21:32:44 <Guest36> the idea for reimplementing subadresses and stealth adresses goes like this. To create a subadress you take the main script hash and append to it a subadress index, and then hash them together. This is the subadress. To send to someone using a stealth adress you first create a shared secret with them, and then you append the shared secret to their
21:32:44 <Guest36> public adress (either a main or sub adress) and hash them together and publish the result to the blockchain as a "script public key".
21:37:29 <UkoeHB> Idk anything about zk scripting, so if you write up a doc explaining how it all works, that would be pretty helpful
21:39:40 <Guest36> lets say that you want to spend a utxo sent to a stealth-subadress. You create a zk proof that you input publicly the hash on the blockchain and the block height. You also input secretly the stealth shared secret, the subadress index, any hash preimages or other garbage the script checks and the actual script. the zk proof then proves to everybody
21:39:41 <Guest36> that 1) the script you used was the script being referenced and 2) the script indeed allows you to spend the utxo.
21:40:07 <UkoeHB> you lost me at "You create a zk proof"
21:40:21 <UkoeHB> how?
21:40:32 <Guest36> I can't write that right now because I have to go to sleep. sorry for my bad english