03:32:44 <vthor> *arrggg* why export_outputs differ which each run?
03:53:34 <vthor> well, I see now, it doesn't matter anyway it imports the same data, it's only fucked, I wasted another 5 hours thinking I made some error in the encoding, comparing binary wise and try to figure out what is going on and why anon doesn't read the outputs, when it reads them from feather, but it seems that feather is able to read mine...
06:18:36 <m-relay> <j​effro256:monero.social> this PR should address the (or perhaps 'an') issue where nodes permanently fail to sync on stressnet: https://github.com/monero-project/monero/pull/9395
06:19:11 <m-relay> <j​effro256:monero.social> It would be much appreciated if other people, who have run into this issue, compile and run this patch on their node
13:34:25 <m-relay> <r​ucknium:monero.social> jeffro256: Wonderful! Could you make the PR to the stressnet repo, too? https://github.com/spackle-xmr/monero/pulls
15:14:24 <m-relay> <r​ucknium:monero.social> jeffro256: Nevermind. I figured out how to pull it in: https://github.com/spackle-xmr/monero/pull/14
17:06:40 <m-relay> <m​cneb10:envs.net> is there a way to get a webhook or something to detect new monero wallet payments?
17:10:50 <moneromooo> monero-wallet-rpc can run a program upon an incoming transfer. Select whatever program does what you want.
17:11:04 <moneromooo> See --help for options to set it up.
17:11:10 <m-relay> <m​cneb10:envs.net> thats nice
17:11:32 <m-relay> <m​cneb10:envs.net> is there a way to do webhooks though?
17:12:18 <m-relay> <m​cneb10:envs.net> if not i could submit a pr to add it
17:12:19 <m-relay> <m​cneb10:envs.net> that would be a nice feature to have
17:14:28 <m-relay> <f​alcon8:matrix.org> yeah pass it over curl
17:20:17 <m-relay> <f​alcon8:matrix.org> you are welcome
20:23:46 <m-relay> <v​tnerd:monero.social> mcneb10: monero-lws has webhook support for payments. It watches N wallets at time, and does not have wallet spend capabilities: https://github.com/vtnerd/monero-lws
20:24:21 <m-relay> <m​cneb10:envs.net> probably too late for that
20:24:31 <m-relay> <m​cneb10:envs.net> my webhook patch is like 1/3 of the way done
20:28:17 <m-relay> <m​cneb10:envs.net> also slightly related, why is wallet2.cpp so bloated
20:28:44 <m-relay> <m​cneb10:envs.net> i dont think any code file should have 15k lines
20:29:09 <m-relay> <f​alcon8:matrix.org> you are not the only one thinking that :)
20:29:54 <m-relay> <f​alcon8:matrix.org> hopefully, we will be replacing it very soon
20:29:58 <m-relay> <f​alcon8:matrix.org> :D
20:30:19 <m-relay> <m​cneb10:envs.net> godspeed
20:30:33 <m-relay> <m​cneb10:envs.net> it looks like it will take massive effort to refactor the internal API to split it up
20:32:21 <m-relay> <f​alcon8:matrix.org> In this community, wallet2.cpp is held in such high regard that it's almost like a sacred ritual. It's unlikely that anyone will criticize it.
20:32:40 <m-relay> <m​cneb10:envs.net> i feel so bad for anyone who has to audit it
20:33:00 <m-relay> <m​cneb10:envs.net> you'd think that would be a breeding ground for security issues since its so big
20:33:12 <m-relay> <m​cneb10:envs.net> small files that do one thing and one thing well are probably best
20:33:53 <m-relay> <m​cneb10:envs.net> im trying to add webhooks to `monero-wallet-rpc` in wallet2.cpp and vscode is struggling just to edit the file
20:35:50 <m-relay> <f​alcon8:matrix.org> but you can pass it over curl without any effort
20:35:57 <m-relay> <m​cneb10:envs.net> yeah but it would be nice to just have it send the whole transaction
20:36:11 <m-relay> <m​cneb10:envs.net> so the reciever of the webhook doesnt have to send another query to get tx info
20:36:47 <m-relay> <m​cneb10:envs.net> some info like what subaddress the tx was directed at also isnt public
20:37:00 <m-relay> <f​alcon8:matrix.org> I see but what's wrong with the additional tx query ?
20:37:15 <m-relay> <m​cneb10:envs.net> ^
20:41:27 <m-relay> <m​cneb10:envs.net> which in the case of webhooks, the server hosting the webhook would not have access to the rpc
20:41:35 <m-relay> <m​cneb10:envs.net> in many cases
20:47:34 <m-relay> <m​cneb10:envs.net> what is `epee` supposed to be?
20:47:43 <m-relay> <m​cneb10:envs.net> is it specific to this project?
20:48:02 <m-relay> <m​cneb10:envs.net> the api looks awful
20:50:26 <m-relay> <v​tnerd:monero.social> epee is a collection of mostly RPC/serialization routines. There's other stuff too, but it's mostly stuff needed for rpc/serialization
20:50:39 <m-relay> <m​cneb10:envs.net> thanks
20:51:37 <m-relay> <v​tnerd:monero.social> It's not terrible for what it does, although some of the macros can be cleaned up a bit, something my outstanding serialization pr does
20:52:02 <m-relay> <m​cneb10:envs.net> im just trying to send an rpc to a server that is not the node
20:52:08 <m-relay> <m​cneb10:envs.net> it looks like it is going to be a lot of work
20:52:18 <m-relay> <v​tnerd:monero.social> The worse part is that it promotes everything in the header, which is why I reworked things in my pr