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