01:14:50 <bonedaddy> if you have a reserve proof, but dont know the balance that was proved with it, how can you determine the balance? i checked the monero-wallet-cli, and monero-wallet-rpc calls, and it doesnt appear possible, as `check_reserve_proof` simply checks to see if the proof is valid iirc
01:16:33 <moneromooo> IIRC the balance proof proves ownership of outputs. So you can sum up all those outputs, check they're not spent.
01:17:03 <moneromooo> I'm not sure how it's laid out internally. I assume you get the amount masks.
01:18:58 <bonedaddy> ah i see, i will try that, thanks.
01:36:48 <UkoeHB_> bonedaddy: I believe `check_reserve_proof()` generates the amount stored in the outputs; the proof itself has all the information you need to get the amounts
01:37:25 <bonedaddy> UkoeHB: how to parse the proof though, i cant seem to find any docs explaining how the proof is structured
01:38:07 <UkoeHB_> in ztm2 section 8.1.6 I discussed reserveproofs, hopefully that will point you in the right direction
01:38:27 <bonedaddy> thanks ill check that
01:38:43 <moneromooo> struct reserve_proof_entry (wallet2.h)
01:40:30 <bonedaddy> nice, thanks
01:41:56 <UkoeHB_> looks like the return-by-reference variables `total` and `spent` from `check_reserve_proof` refer to the unspent amount `unspent amount = total - spent`
01:43:04 <UkoeHB_> moneromooo: the struct doesn't have any amounts
01:44:37 <moneromooo> Looks like it decodes it with the shared secret.
01:46:53 <UkoeHB_> this one has the amounts https://github.com/monero-project/monero/blob/61dd04b68121b4057b4b88356761fbfb3fa73c90/src/wallet/wallet_rpc_server_commands_defs.h#L1504
01:51:21 <UkoeHB_> yeah idk how the rpc works at all, but it looks like `check_reserve_proof` is the command you want, and the response should be response_t from that struct I linked bonedaddy
01:55:12 <bonedaddy> awesome thanks for finding this! i think the docs for the wallet-rpc are slightly incorrect then. https://www.getmonero.org/resources/developer-guides/wallet-rpc.html#check_reserve_proof the `outputs` section for the check_reserve_proof command doesnt include the `total` field.
01:58:03 <UkoeHB_> If you scroll down a few lines the demo output of the command shows total and spent fields
11:53:03 <moneromooo> .merge+ 6840
11:53:03 <xmr-pr> Added
13:50:00 <woodser_> updating my webassembly project to v0.17.0.0, it appears crypto from the supercop submodule is now being used.  I could link to the new source files, but I notice it'll fall back to `using ::crypto::generate_key_derivation;` if monero_crypto_generate_key_derivation isn't defined in src/crypto/wallet/crypto.h.  Wondering if it's better to link to the supercop submodule source files moving forward, or if it's sufficient to u
13:50:01 <woodser_> se the fall back and if there's a flag to do that easily?
13:52:32 <moneromooo> Well, it's assembler. Can webassembly even use raw asm ?
15:53:26 <selsta> .merge 6835 6834
15:53:30 <selsta> .merge+ 6835 6834
15:53:30 <xmr-pr> Added
17:00:20 <Alex_LocalMonero> @moneromooo, hi. Since the release of v0.16 with dandelion we've been having issues with transactions sometimes not propagating and being stuck in pending on the local wallet. We have to manually clear mempool and rescan spent each time. Is this is a known issue and how do we fix it? This has never happened before v0.16
17:03:36 <moneromooo> Might be the node(s) you relayed to being assholes and dropping them.
17:04:03 <moneromooo> relay_tx TXID *should* work, but it will likely broadcast to all.
17:04:11 <moneromooo> vtnerd_ might have a better answer.
17:05:21 <selsta> would deleting p2pstate.bin theoretically maybe help with malicious peers? so that you get completely fresh peers?
17:05:47 <Alex_LocalMonero> @moneromooo, what would be the command to manually add a trusted node to always broadcast to?
17:06:02 <selsta> --add-priority-peer or so
17:07:59 <moneromooo> You might get back to them.
17:16:05 <Alex_LocalMonero> @selsta, when adding a peer should we use the same port as the RPC wallet connects to or is there a different port usually?
17:16:20 <selsta> 18080 is default
17:16:24 <selsta> p2p port
17:16:29 <selsta> I think
17:17:37 <moneromooo> It is.
17:18:23 <Alex_LocalMonero> Thanks.
17:22:54 <Alex_LocalMonero> @selsta, no --add-priority-peer, but there is add-priority-node. So, I assume the config line would be add-priority-node=node.trusted.com:18080?
17:23:21 <Alex_LocalMonero> Is there a command in a running daemon that we could use to verify that our node is now connected to the trusted node?
17:24:23 <dEBRUYNE> print_pl will show the peerlist
17:24:34 <dEBRUYNE> That should allow you to verify that you are connected to the node that was specified upon startup
17:24:59 <dsc_> or `sudo ngrep -qt -W byline 'dst host 8.8.8.8'` to view traffic flying by, which is usually a good indication :p
17:25:31 <dsc_> (replace IP)
17:27:23 <Alex_LocalMonero> Great, thanks.
17:27:48 <moneromooo> print_cn
17:27:52 <moneromooo> print_pl will show all peers
17:28:04 <moneromooo> Known peers, rather than the ones you're connected to.
19:32:19 <grydz> selsta, version 1.7.1 of Ledger's Monero app which fix transfers on testnet should be available tomorrow.
19:32:39 <selsta> awesome
19:33:40 <grydz> I'll let you know on GitHub when it's available :)
20:05:45 <sarang> :)
20:05:52 <sarang> Thanks grydz!
20:34:04 <grydz> Thanks to you guys for your help ;)
20:47:44 <selsta> .merge+ 6841 6842
20:47:45 <xmr-pr> Added
20:54:19 <selsta> .merges
20:54:19 -xmr-pr- 6834 6835 6840 6841 6842
21:02:46 <iamthesenate> Hello :)  Does anybody know of a working stagenet faucet right now? I need to do some tests using stagenet moneroj...
21:03:00 <selsta> https://community.xmr.to/faucet/stagenet/
21:04:47 <iamthesenate> This one did not work for me, sadly :(  I did not get the 10 moneroj and also started getting the 'You are blocked' message after...
21:24:49 <vtnerd_> Alex_LocalMonero: a rescan on the wallet side wouldn't fix the issue? The mempool had to be cleared also? Or .. ?
22:05:39 <Alex_LocalMonero> @vtnerd_, if you don't flush the mempool there's a risk of the tx being eventually broadcast as the tx is still in the mempool even after rescan_spent on the wallet.
22:07:08 <Alex_LocalMonero> @moneromooo @vtnerd_ , I'd like to reiterate that this has never happened before v0.16. After v0.16 it became a semi-regular occurrence.
22:07:27 <moneromooo> Before 0.16, transactions were broadcasted to all your peers.
22:12:45 <moneromooo> Last I looked, 50% of my 8 out peers were lying nodes.
22:13:03 <Inge-> lying?
22:26:03 <moneromooo> Deliberately untruthful.
22:42:34 <Alex_LocalMonero> @moneromooo, why would nodes be deliberately untruthful?
22:42:59 <Alex_LocalMonero> To DoS the network?
22:43:02 <moneromooo> Because their human operator forces them to.
23:46:29 <Alex_LocalMonero> @moneromooo, apart from manually adding trusted nodes, is there a way to strengthen the protocol to avoid this problem without having to rely on people knowing to manually add trusted nodes?
23:46:51 <moneromooo> Feel free to suggest ideas.
23:47:41 <Alex_LocalMonero> In order to do that I'd need to better understand how a node lies. Does it not broadcast the tx further after receiving it?
23:48:41 <sarang> Haven't read back... are you referring to black hole attacks on Dandelion routing?
23:48:51 <Alex_LocalMonero> Oh, so this is a known issue then.
23:49:10 <Alex_LocalMonero> Yeah sarang, we've had issues since v0.16 that sometimes tx don't get propagated.
23:49:15 <sarang> At all?
23:49:20 <Alex_LocalMonero> At all.
23:49:23 <moneromooo> It doesn't matter. You can assume it'll do the worst you can imagine.
23:49:40 <sarang> There's a Dandelion embargo period against black-hole attacks, which is what I was referring to
23:49:44 <selsta> I have only had transactions taking 2-3 minutes until they show up in mempool, but I don’t send as many tx as localmonero.
23:49:52 <moneromooo> At all is not right, your own node should timeout after a feww minutes and broadcast.
23:50:13 <selsta> Timeout is only 10 seconds IIRC.
23:50:27 <moneromooo> Seems... small.
23:50:43 <selsta> Then I misremember :)
23:50:53 <sarang> The embargo timer does have some randomness as well
23:50:55 <Alex_LocalMonero> Yeah, about 0.2% of our outgoing transactions don't propagate. We have to flush tx pool and rescan spent.
23:51:43 <Alex_LocalMonero> How's this for a mitigation: have your node rebroadcast choosing different peers if you don't get the tx from another node after a certain time.
23:53:07 <sarang> If the embargo expires, the node goes into fluff mode
23:53:12 <sarang> and broadcasts to all peers
23:53:27 <Alex_LocalMonero> How long is the embargo?
23:54:44 <selsta> 173 seconds on average according to https://github.com/monero-project/monero/blob/5b3614e6a942612b577d5cdf62afa9ff101be7b0/src/cryptonote_config.h#L109
23:55:12 <Alex_LocalMonero> That's weird, we've had transactions stuck on pending for multiple days.
23:55:13 <selsta> that would explain the issue with tx taking 2-3 minutes to show up in mempool in some cases
23:56:05 <selsta> maybe increasing out_peers helps so that it gets broadcasted to more nodes
23:56:52 <selsta> CipherTrace CEO was talking about methods to circumvent D++ specifically, so it is likely that they spam the network with nodes that black hole tx.
23:57:21 <moneromooo> Oh, so they switched from passive spying to actual sabotage ?
23:57:50 <moneromooo> 173 is right about what I remembered.
23:57:51 <sarang> They admitted to injecting transactions