03:30:52 <user85> i saw monero exist in debian rep however i am yet to reproduce build
03:32:52 <user85> is anyone here?
03:32:52 <user85> at all
03:33:17 <user85> ArticMine: ?
03:34:36 <user85> ...
03:34:58 <plowsof> alot are asleep right now, give it several hours 
07:12:47 <rbrunner> Yesterday moneromooo cooked up a small C++ standalone program using Monero code like stuff from epee and crypto-ops.h: https://paste.debian.net/hidden/e0f00deb/
07:13:03 <rbrunner> What's the simplest way to compile, link and run something like that?
07:13:46 <rbrunner> I checked how MoneroExamples was doing it back in 2017, and collecting the .a files and the .h files seems quite complicated: https://moneroexamples.github.io/access-blockchain-in-cpp/
07:14:07 <rbrunner> I am sure there must be a much easier way for such trivial programs, right?
07:22:55 <moneromooo> g++  -I src/ -I contrib//epee/include/ test-mul.c  build/Linux/cc/release/src/ringct/libringct_basic.a build/Linux/cc/release/src/crypto/libcncrypto.a build/Linux/cc/release/contrib/epee/src/libepee.a  build/Linux/cc/release/external/easylogging++/libeasylogging.a -lsodium
07:23:35 <moneromooo> And then just ./a.out, it doesn't take any parameters.
07:26:03 <rbrunner> Thanks. Surprising.
07:27:01 <moneromooo> What is ?
07:27:12 <rbrunner> And with slightly more complex programs just adding -I and .a until the linker complains no more.
07:27:21 <moneromooo> Yes.
07:27:45 <moneromooo> For complex ones, I usually put the command line at the top in a comment :)
07:27:52 <rbrunner> It's suprising on how primitive a level you do this, at least for me.
07:28:14 <rbrunner> But well, this is new for me, maybe that's my problem.
07:28:15 <moneromooo> As in... brute force ?
07:29:19 <rbrunner> So the MoneroExamples approach to collect *all* .h and .a in some directories or directory structures to access them easily actually is not that dumb
07:30:39 <rbrunner> Other than probably constantly produce errors by forgetting to update the copies after compiling Monero :)
07:42:23 <TrasherDK[m]> On testnet, binaries DL'ed from p2pool v0.18, in CLI, I can't use `set` command:
07:42:24 <TrasherDK[m]> [wallet 9uYsHx]: set ask-password 0
07:42:24 <TrasherDK[m]> Wallet password: Error: failed to read wallet password
07:42:24 <TrasherDK[m]> [wallet 9uYsHx]: viewkey 
07:42:24 <TrasherDK[m]> Wallet password: Error: failed to read wallet password
07:43:51 <TrasherDK[m]> When the inactivity timeout hits, I get never ending :
07:43:53 <TrasherDK[m]> Locked due to inactivity. The wallet password is required to unlock the console.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/4e86938ae2739dea7f16d7a40250ef8b3e7054e9)
07:49:56 <TrasherDK[m]> When not launched in a screen session, it works.
07:55:54 <sech1> and v0.17.3.2 doesn't have this problem?
07:56:20 <moneromooo> I'd be worried given the password is read in raw mode IIRC.
08:14:08 <TrasherDK[m]> NO, v0.17 release don't have this problem.
08:14:44 <TrasherDK[m]> A wallet created before v18, opened in v18 don't have the problem.
08:15:27 <sech1> so the problem is password input doesn't work in screen session?
08:15:39 <sech1> how did you even open the wallet in the first place?
08:15:46 <sech1> it requires entering the password
08:16:05 <TrasherDK[m]> --password 'password'
08:16:23 <sech1> that's not safe, everyone can see it in htop or other tools
08:16:25 <moneromooo> If used in screen (and it works), the password is bound to end up left over somewhere in memory...
08:16:51 <TrasherDK[m]> I know, but I'm only on stagenet and testnet.
08:16:54 <sech1> so it shouldn't work in screen and it's for safety. v0.17 was broken then and v0.18 is correct?
08:18:59 <TrasherDK[m]> Well, I can open the wallet, halt the the output with ctrl-s, enter the password, resume ctrl-q. This is the inactivity-timeout thing.
08:20:50 <TrasherDK[m]> the set commands complain the password can't be read: `Wallet password: Error: failed to read wallet password`
08:40:29 <TrasherDK[m]> So a password in a config-file is considered secure?
08:42:40 <moneromooo> In the same way as a bundle of notes in your home is secure. Do you leave the bundle on the table with an unlocked door ? Or hide it somewhere in a locked safe ?
08:43:29 <moneromooo> Same here. If someone else has root on that machine or the hypervisor, or if you set read rights to group/others, it's not very safe.
08:45:55 <TrasherDK[m]> "If someone else has root on that machine " in that case I would be in trouble. I'm the only user on the host/hypervisor and all guests/vps.
09:31:08 <user85> moneromooo: any ideas why make is failing on debian when compiling cli wallet?
09:31:55 <user85> now its day time in europe
09:32:02 <user85> can someone address a question lol
09:34:53 <user85> why its some fucking complex?
09:34:57 <user85> should just compile
09:35:02 <user85> *so
09:40:00 <moneromooo> If you're polite, maybe I could look at a paste.
09:40:57 <user85> all it does is 
09:40:59 <user85> fatal: path 'external/miniupnp' does not exist in 'HEAD'CMake Error at CMakeLists.txt:273 (message):   Submodule 'external/miniupnp' is not up-to-date.  Please update all
09:41:08 <user85> resynching does not work
09:41:53 <moneromooo> Try:
09:42:11 <moneromooo> git submodule sync; git submodule init; git submodule update
09:42:13 <moneromooo> Then make again.
09:42:44 <moneromooo> If it complains about external/miniupnp being not up to date, dirty, being unable to pull, etc, then:
09:42:52 <moneromooo> cd external/miniupnp; git reset --hard; cd -
09:42:56 <moneromooo> Then:
09:42:59 <moneromooo> git submodule sync; git submodule init; git submodule update
09:43:04 <moneromooo> Then make again.
09:43:16 <user85> will try now
09:43:27 <moneromooo> This assumes you have made no modifications to external/miniupnp: if you have thy'll be lost, so save them first.
09:45:23 <user85> also all deps including vendored are built from source right? i did check deps makefile seems so
09:46:48 <moneromooo> Depends. Some are fallback IIRC.
09:47:08 <user85> what do you mean by fallback?
09:47:28 <moneromooo> To be used if one is not found on your system already.
09:47:41 <user85> yes of course
09:47:51 <user85> those fall back ones are all compiled from source?
09:48:44 <moneromooo> From hte monero repo, yes. IIRC on Mac they use some binary SDK from apple.
09:49:12 <user85> well i am using monero repo
09:52:07 <user85> also have you tried cake wallet? i did sent a bit of btc here, connecting via tor exchange is yet to work
09:52:59 <moneromooo> No.
09:53:53 <moneromooo> I believe it uses wallet2, so it'd log if you set logs up, in case it's an error from our code.
09:54:03 <user85> okk
09:54:12 <user85> maybe exchanges have min amount to swap?
09:54:17 <user85> i will check later on soon
09:54:31 <moneromooo> If they don't have a setting for logs, you can run with hte MONERO_LOGS=2 env var.
09:55:14 <user85> cool
10:13:41 <user85> https://github.com/monero-project/monero/tree/master/src is this a code for all deps?
10:15:12 <user85> in depends make file SOURCES_PATH ?= $(BASEDIR)/sources
10:15:16 <user85> no such dir
10:23:05 <user85> cake wallet no logs setting
10:25:14 <user85> moneromooo: can you suggest any btc xmr exchange that does not use js
10:25:21 <user85> then i dont need cake wallet :)
10:25:45 <moneromooo> No. Ask in #monero. I thikn theres also a #monero-markets for this.
10:26:12 <afungible[m]> Hi. Wanted to know if running monero daemon on "my own VPS server" and connecting to it remotely on a port, will have any advantages in speed & reliability than running monerod on my local machine?
10:26:12 <afungible[m]> I wanted the block sync to be on 24x7 and my local machine isn't on all the time.
10:27:16 <moneromooo> The VPS is likely always online, so never has to catch up when you need it.
10:27:32 <ofrnxmr[m]> Your advantage is in the "on all the time"...
10:27:32 <ofrnxmr[m]> Of course a lan/local node will be faster 
10:28:40 <afungible[m]> In terms of sending/receiving transactions from my wallet (on host machine), would there be visible delays, with above approach e.g. if I use VPS for daemon.
10:28:59 <ofrnxmr[m]>  Syncing your wallet, yes
10:29:16 <ofrnxmr[m]> Send/receive, no
10:29:18 <moneromooo> The VPS's owner will be able to see which transactions you send.
10:29:49 <user85> if app did require some libs where would it store them after make is done?
10:30:19 <ofrnxmr[m]> user85:  https://xyproblem.info 
10:30:23 <afungible[m]> moneromooo: That's a good point. Thanks.
10:30:34 <moneromooo> Are you asking "where does the monero build system put its files ?" If so, in build, where you ran cmake.
10:31:18 <moneromooo> Which doens't have to be even called build, but I guess you know that if it's your case.
10:32:31 <user85> i did run a search for libunbound
10:32:38 <ofrnxmr[m]> afungible: "my local machine isnt on all the time"
10:32:38 <ofrnxmr[m]> Spare Android devices work
10:32:43 <user85> there is on in ./external nothing in built
10:32:48 <user85> build
10:33:00 <moneromooo> Are you sure you have no libunbound on your system already ?
10:34:29 <moneromooo> Oh, I also remember it got removed recently, in favour of always using the system version.
10:34:50 * moneromooo not quite sure of the details there
10:35:09 <user85> i am using later version 17
10:35:12 <user85> latest
10:35:39 <user85>  find . -name "libunbound" only shows one file in monero ./externak
10:35:43 <user85> ./external
10:36:24 <moneromooo> You want \*unbound\* to be sure.
10:36:59 <r4v3r23[m]> <user85> "fatal: path 'external/miniupnp..." <- im getting same issue. i had to copy miniupnp from prev build but now its says cant find libunbound
10:37:14 <r4v3r23[m]> i also get this error: `make: *** [Makefile:139: release-static-android-armv8-wallet_api] Error 1`
10:37:40 <moneromooo> Did the issue survive submodule sync/init/update ? If you did not try it, do so.
10:39:39 <r4v3r23[m]> <moneromooo> "git submodule sync; git submodul..." <- doing this give me empty miniupnp folder
10:40:03 <moneromooo> cd external/miniupnp ; git checkout master; cd -; git submodule update
10:41:29 <moneromooo> (and check you're not out of disk space)
10:41:41 <user85> ok i have found what I wanted to find
10:41:59 <user85> https://github.com/monero-project/monero/blob/master/contrib/depends/packages/unbound.mk :)
10:42:06 <user85> is was there all along
10:42:55 <r4v3r23[m]> moneromooo: miniupno/randomx/rapidjson/supercop are all empty folders 
10:44:02 <moneromooo> Even after checkout ?
10:44:08 <r4v3r23[m]> yes
10:44:23 <moneromooo> ls -a external/miniupnp
10:44:32 <moneromooo> Does this show a .git directory ?
10:44:38 <HenryHollingwort> you need the --recurse flag on the submodle init IIRC
10:45:23 <r4v3r23[m]> moneromooo: "external/miniupnp": No such file or directory (os error 2)
10:46:17 <moneromooo> Did you make a typo in "miniupno/randomx/rapidjson/supercop" ? ie, s/o/p/ ?
10:46:56 <moneromooo> If the directory is here and seemingly empty but ls -a causes that error, your filesystem is likely FUBAR.
10:47:10 <moneromooo> How did you check the directory was empty ? Not ls ?
10:48:08 <r4v3r23[m]> filesystems fine, works fine on 0.17.3.2 branch
10:49:12 <r4v3r23[m]> ok miniupnp folder lists a load of files now
10:50:07 <r4v3r23[m]> `CMake Error at CMakeLists.txt:113 (message):
10:50:07 <r4v3r23[m]>   Could not find libunbound`
10:50:16 <r4v3r23[m]> gettng same error as user85
10:50:44 <user85> not same
10:50:47 <user85> :)))
10:50:57 <user85> also you can compile libunb
10:51:10 <user85> https://www.nlnetlabs.nl/downloads/unbound/ choose latest and make
10:51:13 <user85> haha
10:51:39 <moneromooo> Or install from your OS repo, it likely has it.
10:52:03 <moneromooo> (the devel version)
10:52:06 <user85> moneromooo: which exchange do you use?
10:52:43 <r4v3r23[m]> moneromooo: yeah i already have unbound installed
10:53:06 <ofrnxmr[m]> user85: #monero exchange 
10:53:33 <moneromooo> Monero will want the headers, some distros dump headers and require instlaling a -dev/-devel package on top to have a non kneecapped version.
10:53:44 <ofrnxmr[m]> <moneromooo> "No. Ask in #monero. I thikn..." <- Stop asking questions already answered 
10:53:44 <ofrnxmr[m]> https://matrix.to/#/!LmpzSzbSMKFmPbCpHe:monero.social/$D_DqGxk4llLO6ODNge9l53685BwDJrWbFvKQuxtX988?via=monero.social&via=libera.chat&via=matrix.org
10:53:53 <user85> ofrnxmr[m]:  no one replies there
10:53:59 <ofrnxmr[m]> * user85: 
10:54:38 <ofrnxmr[m]> Try #monerotopia:monero.social 
10:55:03 <moneromooo> IF you do have the headers and they're still not found, try removing any CMakeCache.txt in the build tree. cmake can be a pita with that cache.
10:58:03 <r4v3r23[m]> moneromooo: how do i check if i have headers? i dont see any CMakeCache.txt files
10:59:13 <user85> Run the full node and wait until it syncs up with the network (may take up to a few days - can I connect to some extrernal server instead? how many gb is chain?
11:03:08 <r4v3r23[m]> here's the error output after fixing miniupnp: https://pastebin.com/pscKKGZX
11:08:15 <r4v3r23[m]> submodule update/sync doesnt grab unbound
11:08:37 <moneromooo> r4v3r23[m]: check for /usr/include/unbound.h
11:08:53 <moneromooo> user85: IIRC abot 130 GB, very roughly. More like 45 if pruned.
11:09:03 <user85> moneromooo: not too bad
11:09:17 <user85> currenly using torsocks cli random node :)
11:09:34 <moneromooo> r4v3r23[m]: unbound was removed from the monero tree recently.
11:09:45 <r4v3r23[m]> moneromooo: yep i got it
11:11:57 <user85> how many transfers from 1 address to another is enough to make funds untraceable?
11:12:05 <r4v3r23[m]> so what am i missing here
11:12:16 <user85> i will be sending monero from exchange to local monero running here
11:12:29 <r4v3r23[m]> user85: wrong room
11:12:45 <user85> r4v3r23[m]: wrong answer 
11:13:06 <user85> good luck with such attitude Xd
11:13:43 <ofrnxmr[m]> You too.
11:13:55 <user85> manners
11:13:58 <user85> ;)
11:14:00 <sech1> Good luck with such ignorance, this room is for dev related matters, not a tech support 
11:14:10 <sech1> Ask in #monero
11:14:21 <user85> there are diff ways to say it
11:14:22 <user85> lol
11:15:26 <ofrnxmr[m]> It has been said by 5 different people. 
11:15:26 <ofrnxmr[m]> Wrong room. Ask in #monero
11:15:26 <ofrnxmr[m]> WE might answer you there. We also might not.
11:56:55 <moonshots[m]> How can i contact operations manager of montero? 
11:57:15 <moonshots[m]> s/montero/monero/
12:08:33 <gingeropolous> u gotta call corporate
12:26:58 <ofrnxmr[m]> Hey, any idea when we release v18.0.0? Were 1 month out
12:26:58 <ofrnxmr[m]> Huobi etc planned to close withdrawals today due to confusion 
12:39:11 <selsta> we have binaries already, i have to write release notes and then bF has to upload them to the website
12:44:35 <user85> bf?
12:47:19 <selsta> binar yFate, someone from core team who can update the website
12:47:44 <user85> aha
12:48:28 <ofrnxmr[m]> Bf = my bestfriend....
12:48:28 <ofrnxmr[m]> selsta:  yea, my build took 17 hours :) lolol. Also did master-beta for android
12:48:28 <ofrnxmr[m]> Awesome, so possible today?
12:50:23 <ofrnxmr[m]> Possibly*
13:14:02 <user85> what's new in 18.0?
13:21:04 <rbrunner> Larger rings. 16 members instead of 11.
13:22:51 <ofrnxmr[m]> - View Tags (decrease wallet scan/restore time by up to 30%)... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/08170a69352874b05e6e6a49e1d567186a340d5b)
13:27:38 <plowsof> bulletproofs+, and most important one, the Monero GUI now displays wallets that have a "." in their name (and finally has scan_tx feature added 🦄)
13:49:49 <r4v3r23[m]> ofrnxmr
13:49:49 <r4v3r23[m]> "time to build a transaction decreased by 80-90%" - this is that DNS thing right
13:53:12 <ofrnxmr[m]> Yup
14:17:50 <moneromooo> That is dishonest since it just cuts a timeout if your DNS was borked. 
14:18:32 <moneromooo> Wait, that's what it was, right ?
14:21:56 <ofrnxmr[m]> No, no dns anymore at all
14:22:39 <ofrnxmr[m]> Previously 9c with dns (first request) second would not ping dns and would he 1-2seconds
14:24:08 <moneromooo> Are you suggesting it was very slow even if your DNS was working properly ?
14:24:14 <ofrnxmr[m]> Over tor, 1-5minutes of constantly trying to connect to dns, is now simply skipping dns entirely and connecting to your node, downloading the 1.5mb which is under 9sec seconds which includes onion latency etc
14:24:24 <moneromooo> Oh, tor.
14:24:40 <ofrnxmr[m]> moneromooo: With dns working correctly, yes, 10-20seconds
14:24:42 <moneromooo> Ah, yes, I remember the discussion.
14:24:47 <ofrnxmr[m]> With no dns 3sec
14:24:59 <moneromooo> Still dishonest, tor use is so dependent on your circiots.
14:25:15 <ofrnxmr[m]> 20s to 3s is 80-90%
14:25:53 <moneromooo> I mean, it's like putting your chain on a floppy and saying monero's slow to read from the db, right ?
14:26:11 <moneromooo> People will read this and think we somehow optimized stuff madly, and we didn't.
14:26:14 <ofrnxmr[m]> Nono. Over clearnet is slowed immensely too
14:26:27 <moneromooo> Hmm. OK. Why ?
14:27:28 <ofrnxmr[m]> No idea. Makes like 15 connections before trying to get the data from the node
14:27:58 <moneromooo> So nobody tried to fix it, just removed and claimed a speedup ?
14:28:21 <moneromooo> I mean, I didn't try to fix it either, but I'm not trying to put lipstick on a pig.
14:28:22 <ofrnxmr[m]> The moneropulse dns ping is a privacy leak
14:28:29 <moneromooo> Irrelevant.
14:28:33 <moneromooo> My point is about the misdirection.
14:28:36 <moneromooo> It's not honest.
14:29:09 <moneromooo> But, if you're saying it was slow in the normal course of things, with working DNS, then OK, I think you're right on second thought.
14:29:23 <ofrnxmr[m]> Feather wallet has had their dns calls removed for a year, which isbwhybfeatherbusers dont see the UX speed issue
14:29:36 <moneromooo> I didn't realize that, and it is what should be fixed. So I changed my mind, sorry, speedup's OK in that case.
14:30:54 <moneromooo> Sorry, I get a bit twitchy with disingenuous claims. I rememver someone claiming N% tx verification speedup, but that was on a cherry picked case that's uncommon.
14:31:55 <ofrnxmr[m]> No problem :)
14:31:55 <ofrnxmr[m]> Yes, over clearnet was slow as well. I believe Seth was timing 23 seconds over clear with dns enabled, 3 seconds with --no-dns
14:49:08 <r4v3r23[m]> why those DNS calls where in there in the first place is beyond me
14:52:25 <ofrnxmr[m]> On the node too..
14:52:38 <ofrnxmr[m]> --check-updates
14:52:43 <ofrnxmr[m]> Calls moneropulse 
14:52:49 <ofrnxmr[m]> So I was like what tha fack
14:53:07 <ofrnxmr[m]> I disable dns checkpoints, disable dns blocklist,  run over tor
14:53:26 <ofrnxmr[m]> Check logs and my node is making internet connections over dns to moneropulse.
14:53:26 <ofrnxmr[m]> 'Ile STOP THIS BS
14:53:54 <ofrnxmr[m]> My node supposed to connect to other nodes.
14:53:54 <ofrnxmr[m]> Tldr. 🚮 that shit dont fly in my monero 
14:54:48 <sech1> huh, never seen this before: https://paste.debian.net/hidden/a277105f/
14:54:54 <sech1> this is v0.18 binary
14:56:35 <rbrunner> Cool.
14:56:38 <ofrnxmr[m]> sech1:  fwiw no issues on my end 
14:57:01 <rbrunner> That will be the size of the blockchain in the year 3000.
14:57:12 <sech1> my node keeps running fine
15:01:24 <selsta> sech1: sounds like an invalid tx?
15:02:11 <sech1> The last line is from 5 seconds later, it's probably unrelated
15:04:12 <selsta> 15:49 <r4v3r23[m]> "time to build a transaction decreased by 80-90%" - this is that DNS thing right <-- that was just the case with some weird DNS setups
15:04:21 <selsta> i never had any delay with DNS enabled
15:12:50 <selsta> sech1: ok, i did see similar portable storage messages months ago, it's likely someone playing around with source code. should be harmless.
15:14:00 <r4v3r23[m]> selstawas v0.18 build tested on arch? im getting an error with unbound even tho i have it installed
15:14:54 <selsta> error with release binaries? or custom installed?
15:16:31 <r4v3r23[m]> im using master branch to update monerujo and it fails here: https://pastebin.com/pscKKGZX
15:18:05 <selsta> we removed the unbound submodule because it was outdated and full of security issues (they had an audit). this will be annoying once for those who depend on it but then it shouldn't be an issue anymore in the future.
15:19:17 <selsta> how do you build monerujo? do you have unbound in ${PREFIX}/lib ?
15:22:04 <r4v3r23[m]> selsta: i do. headers as well in usr/include
15:23:59 <r4v3r23[m]> i applied m2049r's monerujo diffs to the v0.18 code, linked that to monerujo external-libs, and then run make there
15:28:55 <selsta> UNBOUND_LIBRARIES UNBOUND_INCLUDE_DIR exist as cmake options
15:29:25 <selsta> you can also try to set `UNBOUND_ROOT=${PREFIX}/include` env var like you do with `CMAKE_INCLUDE_PATH`
15:29:30 <selsta> but not sure if that's enough
15:37:57 <hyc> hm, my i2pd keeps dying
15:38:23 <r4v3r23[m]> <selsta> "you can also try to set `UNBOUND..." <- in `monero/CMakeLists.txt`?
15:45:03 <selsta> r4v3r23[m]: try the env var as a first step
15:46:27 <moneromooo> The DNS calls for monerod were a safety measure for forks from bugs. Never got used in practice. For monero-wallet-cli, defence against some asshats who forked the chain to a scam and tried to get people to spend their coins twice with different rings (unless that was just a side effect of the scam).
15:46:55 <moneromooo> The latter is not needed anymore. The former... well... never needed so far :)
15:48:06 <moneromooo> The latter got added in a hurry to protect people who tried to use the scam as it was were not one, since them spending twice with different rings would weaken everyone else's rings that used their coins.
15:48:40 <moneromooo> Sordid shit. But obsolete now. I wouldn't mind seeing this code gone. It's too complex.
15:49:20 <hyc> wondering if there's a way we can leave the code in, disabled, and only activate it near a hardfork
15:58:33 <moneromooo> That'd keep the complexity. And we need it when some asshat reuses the chain, not when we fork. Less likely now I guess, with a 130 GB chain :)
16:01:52 <hyc> I just assume it's most common for "classic" chains to spring up right after a hardfork
16:02:01 <TrasherDK[m]> On mainnet zmq_pub I got this:
16:02:03 <TrasherDK[m]> [... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/7c2d28cfe894e905f250883b1c5faa335e2cea8a)
16:02:57 <TrasherDK[m]>  * \[... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/fc7a73a2eeb10a81a914a4e2641dcc7abf9eb3fd)
16:03:26 <TrasherDK[m]> What am I looking at? Emty transactions?
16:09:29 <selsta> i looked at one of them, they look like a regular tx on xmrchain, no idea why it says blob_size and weight 0
16:16:09 <sech1> that's an old issue
16:16:55 <sech1> Some transactions don't get proper zmq notifications. It's rare, p2pool just ignores them when it happens
16:21:39 <BusyBoredom[m]> Oof, that's inconvenient. I was gonna add zmq support to my payment gateway lib, but missing payments would be a big deal. Is that documented anywhere yet? 
16:22:48 <selsta> but it's not missing from what i can see? just some data seems missing (blob_size / weight)
16:23:39 <BusyBoredom[m]> Is the rest of the data correct even though the size and weight are wrong? 
16:28:19 <sech1> The rest is correct
16:28:45 <sech1> IIRC blob size and weight just don't always get filled in
16:28:55 <sech1> in the place where zmq takes data from
16:35:15 <r4v3r23[m]> <selsta> "r4v3r23: try the env var as a..." <- having an issue setting it. looking into it
17:34:14 <zoom0ut> when the DNS discussion recently happened I tested with the -no dns flag,  local node on same machine, all other settings were default   
17:34:24 <zoom0ut> there was no change in transaction generation time   
17:34:30 <zoom0ut> for each transaction I made sure nothing was cached 
22:39:23 <hyc> re: anonymizing networks and sybil attacks https://www.sciencedirect.com/science/article/abs/pii/S1389128615004168
22:43:28 <sech1> in other words, to fix issues with a decentralized and trustless network, let's introduce trust and make it centralized
22:44:28 <hyc> yeah maybe their solution isn't the best available, but the references to related work is useful
22:45:05 <hyc> and trust doesn't mean centralized. PGP trust isn't centralized.
22:47:16 <vtnerd__> sech1 BusyBoredom[m] : there are missing txes? this shouldn't happen unless the tcp conn maxes out
22:47:58 <vtnerd__> my expectation was that this would only happen during syncing, its basically just blasting txes over zmq in that state
22:48:16 <sech1> are you referring to zmq notifications with 0 tx blob size and weight reported?
22:48:57 <sech1> no, I think it's just some bug with the source of zmq data, transactions themselves are not missing
22:49:07 <vtnerd__> I saw a comment about missing txes, but it wasn't clear that this was in reference to these empty txes or a larger set
22:49:20 <selsta> the tx were not missing, data was missing
22:49:42 <vtnerd__> ah crap I don't even know how that would happen atm
22:50:05 <selsta> blob_size and weight, fee and txid was correct
22:50:15 <BusyBoredom[m]> vtnerd__: no missing txs, I was just concerned that the data coming over zmq might me malformed enough that an application consuming it would end up missing txs. 
22:50:40 <selsta> the first two were missing*
22:50:46 <vtnerd__> yes, if the receiver cannot keep up there will be drops
22:51:05 <vtnerd__> the only way to detect this it to monitor the chain publications, and check hashes
22:51:17 <vtnerd__> the chain pubs will always have seqence number and prev_hash to keep track of state
22:52:28 <vtnerd__> yeah the missing data is the concern, I don't see how that would happen, unless it was a copy-constructor/copy-assignment error or something :/
22:53:02 <selsta> vtnerd__: sample log https://libera.ems.host/_matrix/media/r0/download/libera.chat/7c2d28cfe894e905f250883b1c5faa335e2cea8a
22:53:16 <selsta> only the last two tx have all data
22:57:10 <vtnerd__> ah thanks. its irritating that this was the truncated mode, so less info, but thanks
22:57:18 <sech1> I just checked my p2pool logs (I keep everything) and it's a very rare occurrence, at least on my node: https://paste.debian.net/hidden/07b64b9d/
22:57:45 <sech1> So it didn't happen at all since October last year
22:59:08 <sech1> But id does seem to happen when many transactions pop up at the same exact moment. Maybe after a reorg?
23:03:42 <sech1> Okay, it looks like it happened around the same time I restarted my Monero node and "SYNCHRONIZED OK" message appeared in bitmonero.log
23:04:27 <sech1> and I restarted it several times on Oct. 2 at that time, not sure what I was doing :D
23:05:19 <sech1> IIRC I popped blocks to fix something with my node
23:06:30 <vtnerd__> yeah and whats interesting is that some in that array have dat
23:07:30 <vtnerd__> because that array chunk should be a single call into the zmq_pub code (the zmq_pub code doesn't do a wait+gather and instead handles each request indepdently)
23:07:35 <sech1> ah, it was that time when someone did a lot of fat transactions and mempool was super full: https://libera.monerologs.net/monero-dev/20211002#c35201
23:07:59 <sech1> so I restarted my node with mempool limitation to unstuck it
23:08:10 <vtnerd__> yeah worse case its a bug in the tx or pool code itself :/
23:11:18 <sech1> maybe it didn't happen on my node anymore because I run it with --max-txpool-weight now
23:28:17 <TrasherDK[m]> Not all pool-add events show up on zmq_pub, but do show on target `show_transfers in` almost instantly.
23:53:11 <vtnerd__> selsta jberman[m]: https://github.com/monero-project/monero/compare/master...vtnerd:monero:replace_p2p_serialization has been rebased
23:53:50 <vtnerd__> not all do? this might be related to tor and/or dandelion++
23:54:34 <vtnerd__> I recall (attempting) to make sure its not alerted externally if in the earlier phases
23:55:31 <vtnerd__> hmm or maybe not, its not mentioned in the documentation I wrote in `docs/
23:56:43 <TrasherDK[m]> https://github.com/monero-project/monero/pull/8427
23:59:59 <vtnerd__> yeah I dunno if thats the correct behavior, but I could see why the change was proposed