03:32:50 <selsta> ofrnxmr[m]: Tor network is a bit better today, it took me 25s to construct a tx using a remote Tor node. 06:04:14 <kayabanerve[m]> selsta "Integrated Subaddresses" is a bug. We don't check the address is fully read when we parse it from a string. You can have a KB address pass Monero's address checks right now AFAICT. 06:04:37 <kayabanerve[m]> It'll fully ignore whatever's past 65 bytes. It just won't be considered invalid either. 06:09:10 <kayabanerve[m]> *at least, from what I can tell of the cryptonote_basic code. Sounds like monero-wallet-gui may have its own trickery? 07:02:06 <arnuschky> How are we moving forward from here on out? What about the release and hardfork dates? 07:02:27 <arnuschky> Did anyone hear from ledger in the meantime? That was the other blocker aside from multisig, afaik 07:06:34 <r4v3r23[m]> arnuschky: [selsta](https://matrix.to/#/%40selsta%3Alibera.chat) time for a dev meeting now that audit is in? 08:38:40 <binaryFate> wernervasquez[m]: weird I don't see frankcryptic messages on IRC side. Anyway he's gone now. 09:58:07 <stretch1> please explain: MDEBUG("Sync threshold met, syncing"); 09:59:46 <stretch1> the threshold omits the about 10k tail blocks , about 1 month, reason? 10:04:19 <moneromooo> This appears to be for committing to disk anything that's still in the fs cache or something like that. 10:05:49 <Guest57> Hi! Any info when new monero daemon will be released? With hardfork support. 10:06:56 <Guest57> want to test our capability with it on testnet. 10:11:07 <selsta> Guest57: you can compile master for now if you want to do testing 10:13:21 <selsta> arnuschky: https://github.com/monero-project/monero/pull/8299#issuecomment-1167104707 10:14:05 <selsta> Waiting to hear back from Trezor currently if they can split up their firmware update. 10:14:24 <selsta> r4v3r23[m]: also ^ 10:35:10 <stretch1> <moneromooo> "This appears to be for committin..." <- well, the importer aborts sync and dismisses about 10k blocks to current height. why? 10:35:58 <moneromooo> Probably because the code assumes the db isn't read only. 10:36:16 <ofrnxmr[m]> <selsta> "ofrnxmr: Tor network is a bit..." <- If I proxy the entire wallet over tor (including the dns requests),... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/8b77842d8337257ab8942b6e6207f15c3ebda19e) 10:38:33 <stretch1> moneromooo: read only? we are writing to it, and yes it is writing and reading 10:39:14 <stretch1> > <@moneromooo:libera.chat> Probably because the code assumes the db isn't read only. 10:39:15 <stretch1> * read only? we are writing to it, and yes the importer is obviously writing and reading 10:40:02 <moneromooo> Oh, I was confused, sorry. I was thinking exporter for some reason. I don't know then. You get to debug. 10:40:44 <stretch1> how to force the importer with --stop-block=myblockend-tostopimportingat 10:45:35 <stretch1> <moneromooo> "Oh, I was confused, sorry. I was..." <- reason? 10:45:35 <stretch1> > Towards the ends of synchronization your node will verify Proof of Work, this can be an additional bottleneck on slower (laptop) processors. 10:50:23 <arnuschky[m]> <selsta> "arnuschky: https://github.com/..." <- Thanks selsta. That delays the hardfork, but not the release, right? 10:50:57 <selsta> yes the firmware does not delay the release 10:51:03 <arnuschky[m]> Meaning, we can have the dev meeting and start preparing the release? Just asking because every day spent testing/integrating is useful 10:51:17 <arnuschky> independent of hardfork date 10:52:17 <selsta> any date suggestions for the meeting? 10:52:37 <selsta> tomorrow usual time? 10:57:39 <arnuschky[m]> I am pretty flexible; works for me. But I am probably the least relevant :D 11:00:16 <tobtoht[m]> Works for me 11:12:55 <sech1> usual time is when? 11:14:53 <plowsof> 17:00 UTC? 11:33:54 <r4v3r23[m]> <selsta> "r4v3r23: also ^" <- if they don't then the hard fork will be at the mercy of whenever they get their act together? 12:53:35 <jeffro256[m]> @selsta by tomorrow, did you mean 29 June 17:00 UTC or 30 June ? 13:08:45 <spirobel[m]> is this the preferred way to prove a transaction? https://www.getmonero.org/resources/user-guides/prove-payment.html is it really a good idea to share the private tx_key with others? 13:09:15 <moneromooo> There are proofs now, better than sending the secret key. 13:09:30 <moneromooo> I think you did mentnion them a couple days ago, or was it someone else ? 13:09:50 <moneromooo> Sharing the tx secret key was done before those proofs were added. 13:10:08 <tobtoht[m]> spirobel[m]: For proving payment to an address you can/should use an OutProof. 13:10:51 <tobtoht[m]> If you need to prove you created a transaction (but not that you sent money to a specific address) use a SpendProof. 13:15:13 <spirobel[m]> <tobtoht[m]> "For proving payment to an..." <- the thing I am confused about is this: the check_tx_proof function seems to be using check_tx_key internally: https://github.com/monero-project/monero/blob/9750e1fa103539b3e533455500610aae76e253a5/src/wallet/wallet2.cpp#L11840 does this mean that the outproof contains the private tx_key? 13:28:46 <moneromooo> It seemed odd, so I checked, and it doesn't AFAICT. 13:28:59 <moneromooo> It calls check_tx_key_helper, is that what makes you think it does ? 13:29:20 <moneromooo> If it is, check what parameters are supplied. 14:10:49 <spirobel[m]> <moneromooo> "It calls check_tx_key_helper, is..." <- yes. because check_tx_key also calls that and it gets supplied the private tx_key https://github.com/monero-project/monero/blob/9750e1fa103539b3e533455500610aae76e253a5/src/wallet/wallet2.cpp#L11390 this is maybe the last part I need to understand. both check_tx_key and check_tx_proof call this check_tx_key_helper. the check_tx_key function supplies the private tx_key while the 14:10:49 <spirobel[m]> check_tx_proof supplies something else and I need to completely understand what that is and how its possible that the two things can lead to the same result. 14:40:35 <stretch1> monero.conf + --add-peer peer123.onion:28083; is an outgoing connection; 14:40:35 <stretch1> how will monerod resolve this .onion? it seems that --tx-proxy tor,127.0.0.1:9050,10 is mandatory to have tor resolve peer123.onions.. 14:40:35 <stretch1> If this is the case then --tx-proxy is misleading, since it is sets p2p outgoing tor traffic which includes blocks 14:40:51 <stretch1> * monero.conf + `--add-peer peer123.onion:28083`; is an outgoing connection; 14:40:51 <stretch1> how will monerod resolve this .onion? it seems that `--tx-proxy tor,127.0.0.1:9050,10 `is mandatory to have tor resolve peer123.onions.. 14:40:51 <stretch1> If this is the case then `-tx-proxy `is misleading, since it is sets p2p outgoing tor traffic which includes blocks 14:41:25 <moneromooo> .onion is resolved by the tor daemon AFAIK. 14:43:00 <stretch1> so it is misleading, since tx-proxy points to the local 9050 torsocket 14:43:19 <ofrnxmr[m]> stretch1: tor doesnt replay blocks. Im confused? 14:43:38 <ofrnxmr[m]> tx-proxy to be specific 14:43:53 <ofrnxmr[m]> --proxy does 14:44:31 <moneromooo> Make sure you read ANONYMITY_NETWORKS.mkd. If it still seems broken, file a bug. 14:57:37 <stretch1> <ofrnxmr[m]> "stretch1: tor doesnt replay..." <- mmh? also tor clearnet (torc) and tor onions (toro) are different 14:57:37 <stretch1> torc clearly syncs blocks (with tor hops inbetween) 14:57:37 <stretch1> toro does not sync blocks? 14:57:50 <stretch1> s/also/naming:/ 15:03:48 <moneromooo> AFAIK if you use tor to proxy your traffic, it proxies everything (can't do anything else really). 15:04:06 <moneromooo> If yo uuse tx-prixy, it proxies txes and not blocks. Kinda what the name is for. 15:05:48 <ofrnxmr[m]> <ofrnxmr[m]> "--proxy does" <- ^ 15:06:15 <ofrnxmr[m]> tx-proxy does not sync blocks. 15:06:15 <ofrnxmr[m]> stretch1: 15:07:06 <ofrnxmr[m]> Handshakes, transactions and peer lists. 15:07:27 <stretch1> sync alias relay, ok. 15:07:48 <stretch1> s/relay/send or forward/ 15:08:17 <ofrnxmr[m]> Only handshakes, peer timed syncs and transaction broadcast messages are supported over anonymity networks. If one --add-exclusive-node p2p address is specified, then no syncing will take place and only transaction broadcasting can occur. It is therefore recommended that --add-exclusive-node be combined with additional exclusive IPv4 address(es). 15:09:03 <ofrnxmr[m]> --proxy is newer then this document 15:09:03 <ofrnxmr[m]> --proxy does blockchain sync over tor. Outgoing only 15:10:13 <stretch1> true?: if --tx-proxy + --add-peer , monerod will only `Handshakes, transactions and peer lists.` 15:10:19 <stretch1> * peer lists.` over tor 15:11:35 <ofrnxmr[m]> Yea 15:11:58 <stretch1> true?: if --proxy and no --tx-proxy, monerod will send tx over tor ? 15:12:16 <ofrnxmr[m]> It will send tx over tor exit nodes, not onions 15:12:33 <MajesticBank> it proxy all goes over proxy 15:12:36 <ofrnxmr[m]> If you use both tx-proxy and proxy, it will block sync over tor, tx relay over oniob 15:12:36 <MajesticBank> even sync 15:13:23 <ofrnxmr[m]> * If you use both tx-proxy and proxy, it will block sync over tor exit nodes and tx relay over onions 15:14:06 <stretch1> anon-inbound does tx or blocks? 15:14:12 <ofrnxmr[m]> Tx 15:14:49 <stretch1> missing?: how to sync blocks tor (in or outgoing) 15:14:58 <ofrnxmr[m]> --proxy 15:15:18 <stretch1> * or outgoing) via **onions** 15:15:33 <ofrnxmr[m]> Not possible to sync blocks over onion 15:16:04 <stretch1> why? correlation is big tor deanon tool 15:16:12 <ofrnxmr[m]> Block sync over exit nodes, tx relay over onions (tx proxy for outgoing, anon inbound for incoming) 15:16:23 <MajesticBank> bounty: if someone can add user:pass support for proxy for monero, current code is based on boost library 15:16:40 <MajesticBank> ready to pay 1500 USD 15:16:52 <ofrnxmr[m]> MajesticBank: Password for rpc? 15:17:07 <MajesticBank> for sock5 proxy 15:17:20 <ofrnxmr[m]> Or pass to login to a proxy 15:17:22 <MajesticBank> when using proxy on wallet init 15:17:41 <MajesticBank> yeah user:pass to login to proxy 15:18:29 <tobtoht[m]> Would like to see this too, it's relevant for tor stream isolation. 15:23:13 <stretch1> <ofrnxmr[m]> "Or pass to login to a proxy" <- https://datatracker.ietf.org/doc/html/rfc1928 15:23:13 <stretch1> method o X'02' USERNAME/PASSWORD builtinto serverside 15:49:43 <selsta> jeffro256[m]: June 30th, 17:00 UTC 15:55:30 <jberman[m]> I'm in for that^ 16:06:55 <UkoeHB> ok 16:12:16 <jeffro256[m]> I can probably make the beginning of the meeting 17:41:57 <stretch1> if --tx-proxy and --proxy is set & no onion peer avail, what happens to tx relay and own tx ? 17:42:07 <stretch1> is there fallback or tmp block? 17:46:57 <ofrnxmr[m]> <stretch1> "if --tx-proxy and --proxy is set..." <- Doesn't get relayed until you have peers 17:47:26 <stretch1> mempool peerlists handshakes of forwards? 17:47:38 <ofrnxmr[m]> Until you have onion* peers 17:47:38 <ofrnxmr[m]> Are you running on testnet, mainnet and are you running release binaries or master? 17:48:12 <ofrnxmr[m]> stretch1: The tx will stay on your node until you you have onion peers to relay it to 17:48:42 <stretch1> officl latest binary; i talk about not my, but other txs 17:49:24 <stretch1> will tx-proxy prevent fallback to --proxy exit relays for tx i ask 17:50:11 <ofrnxmr[m]> I believe so 21:41:35 <stretch1> how to balance the 64 peers into 32 ip4 net + 32 tor net ? 21:43:05 <stretch1> monerod has brittle tx-relay warnings due <=2 tor peers 21:51:43 <ofrnxmr[m]> Brittle? 21:52:59 <moneromooo> Have you tried the recent patches by jberman[m] ? They improve tor connection stability. 21:54:09 <ofrnxmr[m]> <stretch1> "how to balance the 64 peers into..." <- --out-peers=32 --tx-proxy=tor,127.0.0.1:9050,32 --anonymous-inbound=blablah.onion:18084,127.0.0.1:18084,32 21:55:35 <moneromooo> Nice. 22:03:51 <stretch1> <tobtoht[m]> "Would like to see this too, it's..." <- checked zcashd:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/d20af89b153afa4cdb8612fdb9b0a4a73a323de7) 22:04:15 <stretch1> > <@tobtoht:monero.social> Would like to see this too, it's relevant for tor stream isolation.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/353610ccfd6cb92e3dd8b2496ea7eeb30753875a) 22:04:32 <stretch1> * checked zcashd:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/8dedd03d7700d79fb836967a9f18c2b6249ef851) 22:07:55 <stretch1> <ofrnxmr[m]> "--out-peers=32 --tx-proxy=tor,12..." <- if outpeer 32 and tx-proxy has 32, howto sync blocks since no leftovers for ip4 blocks 22:07:56 <stretch1> > Set max number of outgoing connections to other nodes. By default 12. Value -1 represents the code default. 22:09:43 <stretch1> * checked zcashd:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/40a9b4186277532edce4c82972f2317317f82c6d) 22:10:19 <ofrnxmr[m]> stretch1: Out peer = exit node (ipv4) only 22:10:19 <ofrnxmr[m]> tx proxy = out onions 22:10:20 <ofrnxmr[m]> anon inbound = in onions 22:12:23 <ofrnxmr[m]> My setup... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/e94ac5a14c87b84dcf12b367696149480539da8f) 22:12:35 <ofrnxmr[m]> in-peers=0 22:14:25 <stretch1> auto-discover onions or -add-foo-node conf? 22:14:25 <stretch1> also all onions in https://monerodocs.org/infrastructure/tor-onion-p2p-seed-nodes/#config-snippet are 'never' seen so far 22:15:22 <stretch1> if have plenty onions in print_pl but meh on solve via -add.. flags 22:16:03 <ofrnxmr[m]> Build master. The peer issue is fixed 22:17:40 <ofrnxmr[m]> qstotuswqshpfq3tk5ue6ngbx6rge3macsfa7qyt5j4caopixxhckpad.onion:18084 22:17:40 <ofrnxmr[m]> Works and I have alot of peers 22:18:23 <stretch1> yes, it got two nodes on the same onion but 18089 22:19:10 <stretch1> <moneromooo> "Have you tried the recent..." <- ack: https://github.com/monero-project/monero/commits?author=j-berman 22:19:10 <stretch1> q2: howto scrub nodeid from onion ? 22:21:17 <ofrnxmr[m]> The peer id is 000...1 for all onions. Im not sure the question here. 22:21:17 <ofrnxmr[m]> Please read 22:21:17 <ofrnxmr[m]> https://xyproblem.info/ 22:23:49 <stretch1> mmh?: add-peer=blz....onion has node id 7f3.... despite seen never (print_pl) 22:25:50 <moneromooo> It's "peer_id", mostly in net_node.inl. Add logs to see where it changes. It is supposed to be a predefined constant for tor nodes IIRC. 22:26:03 <stretch1> > <@ofrnxmr:monero.social> qstotuswqshpfq3tk5ue6ngbx6rge3macsfa7qyt5j4caopixxhckpad.onion:18084 22:26:03 <stretch1> > 22:26:03 <stretch1> > Works and I have alot of peers 22:26:03 <stretch1> got nodeid: 02fa4d4ed798d7f5 22:26:33 <stretch1> * got peer_id: 02fa4d4ed798d7f5