*arrggg* why export_outputs differ which each run?

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...

<j​effro256:monero.social> this PR should address the (or perhaps 'an') issue where nodes permanently fail to sync on stressnet: monero-project/monero #9395

<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

<r​ucknium:monero.social> jeffro256: Wonderful! Could you make the PR to the stressnet repo, too? github.com/spackle-xmr/monero/pulls

<r​ucknium:monero.social> jeffro256: Nevermind. I figured out how to pull it in: spackle-xmr/monero #14

<m​cneb10:envs.net> is there a way to get a webhook or something to detect new monero wallet payments?

monero-wallet-rpc can run a program upon an incoming transfer. Select whatever program does what you want.

See --help for options to set it up.

<m​cneb10:envs.net> thats nice

<m​cneb10:envs.net> is there a way to do webhooks though?

<m​cneb10:envs.net> if not i could submit a pr to add it

<m​cneb10:envs.net> that would be a nice feature to have

<f​alcon8:matrix.org> yeah pass it over curl

<f​alcon8:matrix.org> you are welcome

<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: github.com/vtnerd/monero-lws

<m​cneb10:envs.net> probably too late for that

<m​cneb10:envs.net> my webhook patch is like 1/3 of the way done

<m​cneb10:envs.net> also slightly related, why is wallet2.cpp so bloated

<m​cneb10:envs.net> i dont think any code file should have 15k lines

<f​alcon8:matrix.org> you are not the only one thinking that :)

<f​alcon8:matrix.org> hopefully, we will be replacing it very soon

<f​alcon8:matrix.org> :D

<m​cneb10:envs.net> godspeed

<m​cneb10:envs.net> it looks like it will take massive effort to refactor the internal API to split it up

<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.

<m​cneb10:envs.net> i feel so bad for anyone who has to audit it

<m​cneb10:envs.net> you'd think that would be a breeding ground for security issues since its so big

<m​cneb10:envs.net> small files that do one thing and one thing well are probably best

<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

<f​alcon8:matrix.org> but you can pass it over curl without any effort

<m​cneb10:envs.net> yeah but it would be nice to just have it send the whole transaction

<m​cneb10:envs.net> so the reciever of the webhook doesnt have to send another query to get tx info

<m​cneb10:envs.net> some info like what subaddress the tx was directed at also isnt public

<f​alcon8:matrix.org> I see but what's wrong with the additional tx query ?

<m​cneb10:envs.net> ^

<m​cneb10:envs.net> which in the case of webhooks, the server hosting the webhook would not have access to the rpc

<m​cneb10:envs.net> in many cases

<m​cneb10:envs.net> what is `epee` supposed to be?

<m​cneb10:envs.net> is it specific to this project?

<m​cneb10:envs.net> the api looks awful

<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

<m​cneb10:envs.net> thanks

<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

<m​cneb10:envs.net> im just trying to send an rpc to a server that is not the node

<m​cneb10:envs.net> it looks like it is going to be a lot of work

<v​tnerd:monero.social> The worse part is that it promotes everything in the header, which is why I reworked things in my pr