06:00:18 -xmr-pr- jeffro256 opened pull request #8173: Removing unused SHA-1 code from EPEE
06:00:18 -xmr-pr- > https://github.com/monero-project/monero/pull/8173
06:23:37 <jeffro256[m]> I have a visceral hatred for EPEE and will not stop until it is completely dissolved 
06:30:18 -xmr-pr- jeffro256 opened pull request #8174: Remove Unused tiny_ini code from EPEE
06:30:18 -xmr-pr- > https://github.com/monero-project/monero/pull/8174
08:24:04 <spirobel[m]> <jeffro256[m]> "I have a visceral hatred for..." <- why is it called epee by the way? does it have something to do with electronic urine or is there a different reason? I know its an old library that came from somewhere. I googled, but couldnt find anything. 
12:43:55 <selsta> jeffro256[m]: maybe it's easier to do it in a single PR with multiple patches?
12:44:26 <selsta> better overview and easier to review
12:44:54 <selsta> but you can keep the already opened PRs open obviously, just for future patches
12:49:16 <selsta> spirobel[m]: it's a helper library written by andrey sabelnikov
12:49:30 <selsta> allegedly it was used for botnets but he denied that
12:49:53 <selsta> sabelnikov reused it when programming cryptonote and bytecoin
14:11:14 <jeffro256[m]> selsta > jeffro256: maybe it's easier to do it in a single PR with multiple patches?
14:11:14 <jeffro256[m]> Yeah I was going to ask: should I split it up into modular bits or combine it into one big PR? What would be easier for you all?
14:11:39 <selsta> one PR with multiple patches
14:13:10 <jeffro256[m]> okay! I'll start one more new one, name it something general, and put future epee cleanup comits in there
14:14:21 <selsta> sounds good
16:30:26 <bbqcore[m]> hi all, i got contacted by one of the airgap.it devs who's interested in creating a standard for qr-based offline txs in monero
16:32:04 <bbqcore[m]> its possible in theory, the only potential bottleneck is the size of the outputs/key images files from wallets with loads of txs
16:35:14 <bbqcore[m]> moneromooo: plowsof mentioned that you said there could be some easy wins in reducing those file sizes
16:36:16 <moneromooo> I think so. I never tried to minimize the amount of data in those.
16:37:18 <moneromooo> I guess I could have a look at it. Useful, and might get me back to coding.
16:39:19 <bbqcore[m]> technically animated QR can fit a few MBs of data, but users would have to scan for a few minutes which isnt a great UX
16:39:55 <bbqcore[m]> so any reduction in data size would help make this really user-friendly and add an awesome alternative to HWWs
16:40:02 <bbqcore[m]> moneromooo: thanks
17:39:47 <bbqcore[m]> AirGap re: offline txs - "We would definitely need help in the monero specifics because noone in our team has knowledge there. Also, our wallet is cross device (runs on phones, but can also be used on Linux (eg. Tails), so it is based on javascript. Are there any good libraries available in js to do all the crypto operations like generating addresses and signing transactions?"
17:40:33 <moneromooo> If you want to code your own wallet, you get to read the code :)
17:40:51 <moneromooo> But mymonero has js code to do some of that.
17:42:02 <endogenic> oh that's me
17:45:41 <bbqcore[m]> endogenic: guessing mymonero doesnt have the option for offline txs?
17:45:55 <endogenic> it does
17:46:14 <endogenic> you'll just need to use the interfaces for working with a light wallet server for now
17:46:49 <endogenic> i could provide you with a high performance and secure scanning service and then you'd use our code
17:46:55 <endogenic> for client side
17:47:05 <endogenic> well, that's the theory anyway
17:47:28 <endogenic> otherwise, you'd need a service to make various things available to your cold client
17:47:39 <endogenic> the code is very close to mainline's full wallet code
17:47:45 <endogenic> i've wanted it to converge for years
17:47:49 <endogenic> but i'm just one person
17:48:05 <endogenic> hard to keep up with everything i have on my plate sometimes
17:48:22 <endogenic> i've done lots of research into the techs related to your product
17:48:31 <endogenic> even developed a version of it
17:48:40 <endogenic> guess the cat is out of the bag
17:49:04 <bbqcore[m]> im not from airgap - i was asking around about qr codes for xmr and they reached out
17:49:11 <bbqcore[m]> they are definitely interested
17:49:14 <endogenic> oh my bad
17:49:21 <endogenic> yeah i mean the concept is legit
17:49:29 <endogenic> makes me want to cry
17:49:37 <endogenic> cause i'm slow
17:49:41 <bbqcore[m]> for sure. just needs to be worked out
17:49:56 <endogenic> but yknow what drake says. not about who did it first but who did it right
17:50:23 <bbqcore[m]> so i'll send them your mymonero-core-js lib
17:50:36 <bbqcore[m]> endogenic: you've got a working version?
17:50:37 <endogenic> yes but tell them i left that co 2 yrs ago
17:50:42 <endogenic> i have a much better core lib now
17:50:47 <endogenic> but it's not yet public
17:50:50 <endogenic> yes i do
17:51:14 <endogenic> i mean the concept already exists for monero
17:51:25 <endogenic> someone made a gtk(?) or qt app for it for linux ages ago
17:51:28 <endogenic> had a funky name
17:53:16 <bbqcore[m]> endogenic: would you be down to be their poc? 
17:53:35 <endogenic> happy to talk with them, sure
17:53:36 <bbqcore[m]> im no dev so this will all go over my head
17:53:57 <endogenic> not my priority to provide enterprise services right not because i'm overwhelmed but my team certainly can do it
17:54:07 <endogenic> right now*
17:54:23 <endogenic> feel free to DM me
17:54:30 <endogenic> we can exchange contact indo
17:54:31 <endogenic> info
17:55:52 <bbqcore[m]> awesome, ill get the contact info and DM you
17:56:23 <crypto_grampy[m]> https://github.com/monero-ecosystem/monero-javascript/blob/master/docs/developer_guide/view_only_offline.md
18:15:18 -xmr-pr- jeffro256 opened pull request #8175: Epee Cleanup
18:15:18 -xmr-pr- > https://github.com/monero-project/monero/pull/8175
19:46:23 <jeffro256[m]> Hey the cmake generates the Makefile, right? if I wanted to run cmake with a new setting, how would I go about doing that?
19:46:41 <jeffro256[m]> Specifically I want -D CMAKE_EXPORT_COMPILE_COMMANDS=1
19:47:44 <selsta> `mkdir b; cd b; cmake -D CMAKE_EXPORT_COMPILE_COMMANDS=1 ..; make`
19:50:52 <jeffro256[m]> That wrote everything to to the project root directory. Any way to avoid this?
20:01:34 <UkoeHB> jeffro256[m]: `mkdir build && cmake -S . -B build -D CMAKE_EXPORT_COMPILE_COMMANDS=1 && make`
20:05:29 <selsta> jeffro256[m]: it should write everything into the `b` dir if you did the same steps as I wrote
20:05:52 <selsta> UkoeHB solution should be equivalent
21:15:18 -xmr-pr- SamsungGalaxyPlayer opened issue #8176: Feature request: optionally export tx_keys with export_transfer
21:15:18 -xmr-pr- > https://github.com/monero-project/monero/issues/8176
21:32:42 <bbqcore[m]> any traction on #1070?
21:32:43 <bbqcore[m]> https://github.com/monero-project/monero/issues/1070
21:35:25 <UkoeHB> bbqcore[m]: seraphis/jamtis will do that
21:35:36 <UkoeHB> https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024
21:37:55 <bbqcore[m]> yeah, but thats a while off
21:38:02 <bbqcore[m]> just realized there was a proposed solution for it already
21:42:51 <UkoeHB> bbqcore[m]: afaict that proposal adds data to txs, which generally kills enthusiasm in most ideas lol. Plus it would break the 'view key contract' that exists right now for view-only wallets (view keys can't see outgoing txs). 
21:55:47 <bbqcore[m]> gotchya, seraphis it is then. 
21:56:01 <bbqcore[m]> looks like consensus was reached re: fee change
21:56:22 <bbqcore[m]> has the next hard fork meeting been planned?
22:07:17 <UkoeHB> bbqcore[m]: I don't see any upcoming meetings in the meta repo
22:07:26 <UkoeHB> https://github.com/monero-project/meta/issues
22:08:20 <bbqcore[m]> thats why i asked :)
22:14:37 <jberman[m]> My view of the status of tasks for the HF:
22:14:44 <jberman[m]> - fee change PR has 2 approvals (7819)
22:14:55 <jberman[m]> - bp+ PR pending final review from vtnerd (7170)
22:14:59 <jberman[m]> - view tag PR has 3 approvals (8061)
22:15:15 <jberman[m]> - multisig PRs have 1 approval each from vtnerd + pending final review(s) from h4sh3d (8149, 7877)
22:15:24 <jberman[m]> - I'm submitting a PR to bump the ring size to 16 today
22:16:41 <jberman[m]> idk if a meeting is necessary til reviews are done, we're just working through stuff. unless people think a meeting is necessary?
22:18:16 <UkoeHB> later today or tomorrow I will re-review the fee PR, then do ~final cleanup on the multisig address PR
22:20:39 <dark[m]> Is project OSPEAD coming to this HF?
22:22:19 <UkoeHB> don't think so
22:35:08 <Rucknium[m]> dark: No, it's not. We decided a while ago that it's not going in the hard fork. And it doesn't need to be implemented in a hard fork since the change occurs in the wallet software rather than the blockchain consensus level.