00:19:54 <neromm[m]> > Yeah I agree with selsta. It makes more to put it in utils. The contrib folder (besides epee) is mostly compatibility, packaging, patches, etc 
00:19:54 <neromm[m]> perfect, thanks! I'll do that tomorrow, I've been outside home this weekend
00:25:02 <neromm[m]> > Also do you know if these completions work with Bash also?
00:25:03 <neromm[m]> pretty sure they do not. Separate completion files should be written for Bash and zsh
10:29:14 <nikg83[m]> Has the code been freezed for 0.18 ?
10:33:51 <bridgerton[m]> <plazma> what is this
10:33:52 <bridgerton[m]> <plazma> https://eprint.iacr.org/2022/744
10:34:03 <bridgerton[m]> <plazma> MoNet: A Fast Payment Channel Network for Scriptless Cryptocurrency Monero
10:34:28 <bridgerton[m]> <plazma> is it compatible with seraphis
10:56:00 <r4v3r23[m]> <nikg83[m]> "Has the code been freezed for 0...." <- waiting on multisig audit 
11:07:29 <moneromooo> AFAICT, it uses ethereum, so pretty useless.
12:08:13 <Dan[m]> https://web.getmonero.org/resources/user-guides/node-i2p-zero.html
12:08:14 <Dan[m]> Is this actively developed?
12:08:45 <Dan[m]> I2p-zero
12:17:18 <lousiF> Melinda French knows
12:21:04 <lousiF> I finally got a cooling pad for one of the laptops, chance of meltdown is lowered now. lol
12:49:39 <M0x1zxq7896lp2ze> lol
14:08:04 <sech1> .merges
14:08:04 -xmr-pr- 7774 8296 8356 8357 8358 8384
14:08:50 <selsta> we are making progress with ledger
14:36:01 <lousiF> Btw, OpenAlias still works great. If you have a domain, it's pretty simple.
14:36:01 <lousiF> https://openalias.org/
14:38:45 <plowsof[m]> selsta "we are making progress with ledger" <- This is great news! 
14:44:26 <gingeropolous> Dan[m], check the github repo for i2p-zero i guess
14:47:06 <lousiF> Thanks to all the devs, I hope you are all getting donations for your work,
14:48:16 <lousiF> Time = monero, and the internet isn't free as in the bills,
15:26:10 <neromm[m]> any way to only mine, on testnet, when the tx pool is not empty/new transactions arrive? Would that be a useful thing for people if it does not exist?
15:32:52 <moneromooo> You can mine whenever you're synced logic's a bit more complicated IIRC, but close enough). Whether the pool is empty or not does not matter. When txes arrive, monerod stops mining just for a short time while it verifies. While it *might* be possible to continue mining during that time, it's not worth the work I think.
15:33:24 <moneromooo> Oh wait. I see what you're saying.
15:33:52 <moneromooo> I guess it could be useful, yes.
15:34:52 <moneromooo> There is a "smart mining" thing, which considers a number of configurable conditions before starting mining. You could add "is the pool empty" as another condition.
15:35:54 <moneromooo> Though when I need a block, I use the python console and call genereateblocks(address, 1).
15:36:19 <moneromooo> (I removed the "doesn't work except if --regtest is passed" check, which is pointless I think)
15:44:15 <neromm[m]> oh thank you! I think the "smart mining" does it for me. the rpc call `genereateblocks` is also useful, but maybe a `generate [numblocks]` command for monerod would also be useful (like the one bitcoin-cli has)? Or maybe it would be redundant?
15:59:38 <rbrunner> I think selsta floated the idea yesterday or the day before to hold a dev meeting today to clear the release situation
15:59:50 <rbrunner> but I could not find any formal announcement.
16:00:31 <rbrunner> And it's almost the usual time for such a meeting, so ... :)
16:03:55 <jeffro256[m]> Hi !
16:05:57 <jeffro256[m]> Do we know if there has been any issues with view tags on test net so far?
16:06:57 <rbrunner> I can only speak for myself. I tested them quite extensively on monerotech.info and had no problems whatsoever
16:07:13 <rbrunner> Also did quite a number of testnet transactions since the fork, to test multisig, also without issues
16:09:31 <sech1> p2pool testing with view tags went fine too
16:20:19 <jberman[m]> got em working on ledger on a local testnet, will test against live testnet shortly. ledger will be ready for the fork one way or another
16:20:38 <selsta> rbrunner: still waiting on the audit
16:21:35 <selsta> but in general everything should be fine, we have ledger and trezor and multisig isn't a necessity for the HF
16:32:24 <jeffro256[m]> jberman: were ledger and Trezor still able to parse txs with view tags before adding support, even if they didn’t utilize the feature ?
16:37:23 <moneromooo> While I do not know, I'm certain they can't parse it since there's an extra byte per output they would not expect.
16:38:02 <dEBRUYNE> I do think the 16 July date may be a bit optimistic, would probably not be a bad idea to push it back 1-2 weeks
16:39:38 <arnuschky[m]> <selsta> "rbrunner: still waiting on the..." <- Yes, unfortunately. The auditors promised me a draft report by last Friday. Haven't heard from them since. Bit surprised they were super responsive up to now.
16:40:25 <jberman[m]> jeffro256: not sure about Trezor, but it doesn't look like Ledger parses txs. Looks like the wallet software (CLI) does the parsing, but I'll keep testing to confirm maybe I'm missing something
16:43:32 <arnuschky[m]> I am only involved in the multisig bits, and have no overview over the rest. What's the status of the other bits of the release? How much work is rebasing all the PRs?
16:45:30 <selsta> most stuff is already merged, apart from multisig, trezor and ledger
16:46:37 <selsta> dEBRUYNE: we also need to know when trezor will update their firmware
16:47:28 <selsta> I've asked already and waiting on an answer currently
17:11:00 <ooo123ooo1234567> <selsta> "but in general everything should..." <- or not fine
17:14:10 <rbrunner> or anything in between
17:14:40 <ooo123ooo1234567> <arnuschky[m]> "Yes, unfortunately. The auditors..." <- maybe they are realized that it's another trap; hahahahahaha
17:14:46 <ooo123ooo1234567> > <@arnuschky:matrix.org> Yes, unfortunately. The auditors promised me a draft report by last Friday. Haven't heard from them since. Bit surprised they were super responsive up to now.
17:14:46 <ooo123ooo1234567>  * maybe they've realized that it's another trap; hahahahahaha
17:15:21 <ooo123ooo1234567> (rbrunner: "scammer" wasn't directed at you in that reply to erciccione)
17:16:13 <ooo123ooo1234567> <selsta> "we are making progress with..." <- how to track the progress ?
17:17:56 <ooo123ooo1234567> <jberman[m]> "got em working on ledger on a..." <- https://github.com/j-berman/app-monero, wow
17:18:55 <ooo123ooo1234567> rbrunner: indeed, that's how critical thinking is supposed to work
17:19:03 <selsta> the patch will be public once tested and then it's up to ledger to test, merge it and publish an update
17:20:03 <ooo123ooo1234567> there is no reason to reject working patch done by others for free, pure benefit for them
17:21:55 <ooo123ooo1234567> <arnuschky[m]> "Yes, unfortunately. The auditors..." <- any upper boundary estimate on date ? and what's the next action in case of failure ?
17:22:34 <ooo123ooo1234567> `+inf, undefined the next action` is acceptable reply too
17:22:40 <ooo123ooo1234567>  * `+inf, the next action is undefined` is acceptable reply too
17:50:59 <bularotunda[m]> 00:01:07 WARN  src/pool.c:2053: result not found... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/ebe4318bc68b246581cb30b7827967da05336f8f)
18:27:11 <Ackermann[m]> I may be missing something here but I see on xmrguide that the author suggests not using --tx-proxy 
18:27:11 <Ackermann[m]> https://xmrguide.org/remote_nodes
18:27:11 <Ackermann[m]> However, if all of your peers are onion addresses how does monerod know to use tor to actually reach them if you don't tell it to use tor as a proxy?
18:37:57 <selsta> Ackermann[m]: who is the author of this website? it does not seem accurate
18:39:12 <selsta> ok it's guidelines for remote node operators
18:40:01 <plowsof[m]> tobtoht i believe : xmrguide author 
18:40:05 <selsta> i think this is about the end user being protected by tor
18:40:17 <selsta> not the node operator
18:41:05 <selsta> you can work around the propagation delays by using `disable_noise`
18:42:05 <ooo123ooo1234567> > <@bularotunda:0wnz.at> 00:01:07 WARN  src/pool.c:2053: result not found... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/de2816971d3a72b34b21f0c2f0c109330a2ac375)
18:42:14 <ooo123ooo1234567>  * redirect it to that pool sw
18:49:36 <ooo123ooo1234567> > <@bularotunda:0wnz.at> 00:01:07 WARN  src/pool.c:2053: result not found... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/56769f10955cf59df8d4a25dba8a5421ea75cec2)
18:51:12 <bularotunda[m]> > <@ooo123ooo1234567[m]:libera.chat> > <@bularotunda:0wnz.at> 00:01:07 WARN  src/pool.c:2053: result not found... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/8949857ef5a166ae911e281e9b3373ae8ab3bc1f)
18:51:33 <ooo123ooo1234567> wow, are there hex of that block in logs somewhere ?
18:52:38 <rbrunner> That's a message by the pool manager that it can't find the "meta" counterpart to a tx that is in the pool
18:53:01 <rbrunner> I don't know whether anybody ever researched that "to the bottom" when and how and why that happens
18:53:27 <rbrunner> But it happens quite frequently, in comparison, without any visible bad effects
18:53:46 <rbrunner> I think it can be so frequent that moneromooo made it "print only once", like the message tells
18:54:04 <bularotunda[m]> ooo123ooo1234567[m]: No, thats all my diaries.
18:54:19 <bularotunda[m]> monerod banning ips, is that expected?
18:54:43 <ooo123ooo1234567> are you sure that there is nothing in pool logs ?
18:56:06 <rbrunner> What do you mean with "pool logs"?
18:57:05 <rbrunner> In any case, with "pool manager" I mean that Monero code that manages the tx pool
18:57:19 <rbrunner> As used internally by the daemon
18:58:23 <ooo123ooo1234567> > <@bularotunda[m]:libera.chat> > <@ooo123ooo1234567[m]:libera.chat> wow, are there hex of that block in logs somewhere ?
18:58:23 <ooo123ooo1234567> > 
18:58:23 <ooo123ooo1234567> > No, thats all my diaries.
18:58:23 <ooo123ooo1234567> what's your pool setup: miners <->single pool <-> single monerod ?
18:58:47 <bularotunda[m]> > <@ooo123ooo1234567[m]:libera.chat> > <@bularotunda[m]:libera.chat> > <@ooo123ooo1234567[m]:libera.chat> wow, are there hex of that block in logs somewhere ?... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/6f208e512108383870b7917e69ddd542c8b6c2b9)
18:58:51 <Ackermann[m]> <selsta> "not the node operator" <- Ok thats what I was thinking, thank you 
19:00:58 <ooo123ooo1234567> it looks like pool submitted a block with a tx that isn't in txpool of daemon anymore, the next question is how that tx got into block template and how that tx disappeared from txpool ?
19:01:13 <rbrunner> https://github.com/monero-project/monero/blob/9750e1fa103539b3e533455500610aae76e253a5/src/cryptonote_core/tx_pool.cpp#L1456
19:01:41 <rbrunner> You can have that with regular daemon and wallet use, without any mining in play
19:02:14 <ooo123ooo1234567> (all messages about missing tx meta are irrelevant)
19:02:25 <bularotunda[m]> I lost a Reward because of this error, Pool reports finding the block, but in my wallet I don't see the reward
19:03:04 <ooo123ooo1234567> It isn't clear yet who is responsible for it
19:03:26 <rbrunner> Ah, I see, the message "Transaction not found in pool" is relevant?
19:03:58 <ooo123ooo1234567> rbrunner: wow, good deduction
19:05:50 <selsta> bularotunda[m]: which monerod version or commit do you run?
19:06:39 <ooo123ooo1234567> selsta, it is also likely unrelated
19:08:20 <bularotunda[m]> 00:01:07 WARN  src/pool.c:2069: Error (-7) with block submission: Block not accepted
19:08:20 <bularotunda[m]> 2022-06-19 00:01:07.252        E Transaction not found in pool
19:08:20 <bularotunda[m]> happens in the same minute as the error in the pool
19:08:20 <rbrunner> Very, very unfortunate sequence of events? Somebody finds and publishes the block a tiny bit earlier, bularotunda's daemon receives it juuuust before it can submit itself, and the new blocks takes the tx from the pool
19:08:46 <rbrunner> *block, singular
19:09:26 <bularotunda[m]> selsta: Monero 'Oxygen Orion' (v0.17.3.2-release)
19:10:20 <ooo123ooo1234567> rbrunner: did you read code ?
19:10:31 <ooo123ooo1234567> > <@bularotunda[m]:libera.chat> 00:01:07 WARN  src/pool.c:2069: Error (-7) with block submission: Block not accepted... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/ab73d91e7e03db3e7be92190b3b8929049bd734c)
19:10:36 <rbrunner> You think I openly admit here I am just guessing :)
19:10:50 <bularotunda[m]> rbrunner: This is the third time this has happened to me. I've recorded it three times.
19:11:13 <rbrunner> Ok, there probably goes my theory then
19:11:46 <ooo123ooo1234567> are you sure that you use only 1 pool instance and 1 monerod instance ?
19:13:41 <bularotunda[m]> My daemon also keeps blocking other IP   is this expected... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/6e389a391572c9394875106def6cd3dcc3593a78)
19:14:52 <ooo123ooo1234567> those blocks are stupid but it isn't important unless your daemon has 0 connections in result
19:15:21 <bularotunda[m]> is it possible that my LMDB database is corrupted?
19:15:48 <ooo123ooo1234567> > <@bularotunda[m]:libera.chat> > <@rbrunner:libera.chat> Very, very unfortunate sequence of events? Somebody finds and publishes the block a tiny bit earlier, bularotunda's daemon receives it juuuust before it can submit itself, and the new blocks takes the tx from the pool
19:15:48 <ooo123ooo1234567> > 
19:15:48 <ooo123ooo1234567> > This is the third time this has happened to me. I've recorded it three times.
19:15:48 <ooo123ooo1234567> it would be good to increase verbosity of logs for both pool and daemon to have more info on the next failure
19:15:58 <bularotunda[m]> ooo123ooo1234567[m]: Height: 2650040/2650040 (100.0%) on mainnet, not mining, net hash 2.44 GH/s, v14, 130(out)+12(in) connections,
19:17:26 <ooo123ooo1234567> what are the heights for failed blocks ?
19:35:04 <Dan[m]> <gingeropolous> "Dan (Is not the man & Braxman..." <- I have last release 2020, just wonder cause its recommended either i2p or tor to connect node to wallet.
19:35:05 <Dan[m]> https://github.com/i2p-zero/i2p-zero
19:38:54 <ooo123ooo1234567> > <@bularotunda[m]:libera.chat> > <@ooo123ooo1234567[m]:libera.chat> those blocks are stupid but it isn't important unless your daemon has 0 connections in result
19:38:55 <ooo123ooo1234567> > 
19:38:55 <ooo123ooo1234567> > Height: 2650040/2650040 (100.0%) on mainnet, not mining, net hash 2.44 GH/s, v14, 130(out)+12(in) connections,
19:38:55 <ooo123ooo1234567> is it possible to see monerod logs +- few hours around failed submit ?
19:39:13 <shayerhaver[m]> Now is your Bitcoin wallet or coinbase 0.00000 I promise 0.80500 in less than 24 hours without sending money to anyone. Earn 0.764 in 7hours, No referrals, No Ads, No scams. Ask how(me) 
19:39:14 <shayerhaver[m]> Or join https://t.me/+JdEg2rIn7E0wZDFk
19:39:36 <w[m]> > <@123bob123:matrix.org> I have last release 2020, just wonder cause its recommended either i2p or tor to connect node to wallet.
19:39:37 <w[m]> > https://github.com/i2p-zero/i2p-zero
19:39:37 <w[m]> #monero:monero.social 
19:42:39 <Dan[m]> Didn’t this get developed my monero developers?
19:42:52 <Dan[m]> Thought i’d asked here if someone did
19:44:14 <selsta> it doesn't really matter if you use tor or i2p for rpc traffic, tor will likely be faster
19:58:16 <ooo123ooo1234567> <bularotunda[m]> "is it possible that my LMDB..." <- It's unlikely to have so sophisticated negative side effect due to corrupted db 3 times
19:58:49 <ooo123ooo1234567> > <@bularotunda[m]:libera.chat> > <@ooo123ooo1234567[m]:libera.chat> those blocks are stupid but it isn't important unless your daemon has 0 connections in result
19:58:49 <ooo123ooo1234567> > 
19:58:49 <ooo123ooo1234567> > Height: 2650040/2650040 (100.0%) on mainnet, not mining, net hash 2.44 GH/s, v14, 130(out)+12(in) connections,
19:58:49 <ooo123ooo1234567> are there enough resources (bandwidth + cpu) on that machine to handle so many connections ?
21:08:34 <Ackermann[m]> Hey everyone,... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/e1d8f4839dacb982759d5abef55612783b65c882)
21:10:45 <Ackermann[m]> s/tor/xmr/, s/Auto_XMR_Node/Auto\_XMR\_Node/
21:14:40 <ofrnxmr[m]1> #monero-community-dev:monero.social 
21:15:25 <Ackermann[m]> thanks
22:03:27 <fented> Monero build errors on OpenBSD https://pastebin.com/UyA8R1G9
22:03:42 <fented> looks like libunbound linker related
22:26:17 <ooo123ooo1234567> <fented> "looks like libunbound linker..." <- was it `make release-static` ?
22:26:44 <fented> env DEVELOPER_LOCAL_TOOLS=1 BOOST_ROOT=/usr/local gmake release-static
22:27:00 <fented> as indicated in the README for OpenBSD
22:30:15 <ooo123ooo1234567> deps for static build aren't complete, try `gmake release`
22:34:37 <fented> ooo123ooo1234567: building without static solved it, thanks for the help, you made my day :)
22:34:56 <ooo123ooo1234567> wow
22:35:24 <ooo123ooo1234567> are there enough enthusiasm to complete static deps ?
22:35:30 <fented> :D
22:35:35 <ooo123ooo1234567> s/are/is/