02:56:24 <Steven_M> Hi all. Is the fork late?
02:58:04 <selsta> the fork happened already
02:58:27 <selsta> there will be a second fork tomorrow
03:04:34 <DeanGuss> in monerod.conf I have: p2p-bind-port=18080 and p2p-bind-ip=127.0.0.1 and my onion points at blah.onion:18080 -> 127.0.0.1:18080
03:04:56 <DeanGuss> I also have anonymous-inbound=blah.onion:18083,127.0.0.1:18083,64
03:05:17 <DeanGuss> Are they both necessary?
03:06:28 <DeanGuss> I also have the same blah.onion pushing 18083 and 18081 (rpc) connections to 127.0.0.1
03:07:01 <DeanGuss> I gather that remote rpc is required for me (or others) to use my node as a remote node - is that true?
03:21:42 <hyc> yes
03:22:25 <hyc> I wouldn't publish port 18081 though
03:22:36 <hyc> I'd only publish the restricted-rpc port
03:28:25 <DeanGuss> That is my restricted rpc port
03:30:22 <DeanGuss> but ok so ignoring 18081 for now, why are there 2 different things to do the same thing?  Are they just 2 different ways of saying the same thing (considering how I have my p2p-bind-port and p2p-bind-ip set?
03:31:49 <hyc> what two different things?
03:32:19 <DeanGuss> p2p-bind-port and p2p-bind-ip, along with anonymous-inbound.  Last I checked I couldn't put them on the same port
03:32:54 <hyc> sure you can
03:33:03 <hyc> aren't you already putting them on 18080?
03:33:42 <DeanGuss> I'm putting p2p-bind-ip on 18080 and I am putting anonymous-inbound on 18083 as suggested when that config option came out
03:34:06 <DeanGuss> iirc I wasn't able to put them on the same port. Glad to hear I can, I'll try it
03:34:35 <hyc> ahh
03:34:47 <hyc> yeah I have mine on 18083 as well
03:36:43 <DeanGuss> FATAL	net	contrib/epee/include/net/abstract_tcp_server2.inl:1277	Error starting server: Failed to bind IPv4 (set to required)
03:36:44 <DeanGuss> ERROR	daemon	src/daemon/main.cpp:364	Exception in main! Failed to initialize p2p server.
03:37:03 <hyc> yeah they have to be separate
03:37:49 <hyc> p2p-bind-ip / p2p-bind-port is only for clearnet
03:38:17 <hyc> any other network (tor, i2p) requires its own port
03:38:31 <selsta> you don't anything onion on 18080
03:39:07 <DeanGuss> selsta: why not?
03:39:18 <DeanGuss> anonymous-inbound=blah.onion:18080,127.0.0.1:18083,64
03:39:40 <DeanGuss> ^ I just did that and it seems to have worked... at least externally.  I had to go with 127.0.0.1:18083 internally there
03:39:47 <hyc> yeah that can work, because it's really using 18083 on the local machine
03:40:13 <hyc> the outside world talks to onion:18080 but tor forwards it to local:18083
03:42:33 <hyc> on one of my nodes I'm using onion:18083 -> local:18084 because zmq-pub is already on local:18083
03:43:43 <DeanGuss> So if I totally leave out anonymous-inbound=... if I were to connect to say another .onion node, would it see my IP as a tor exit node's public ip?  And anonymous-inbound makes it so that they see my .onion?  Or how does it go?
03:44:03 <hyc> it means what it says
03:44:16 <hyc> anonymous-inbound only sets how other peers can connect to you
03:44:26 <hyc> has no effect on how you connect to them
03:44:32 <DeanGuss> How do they learn that .onion name?
03:44:48 <hyc> it's published in peerlists like everything else
03:45:42 <DeanGuss> K.  And if I had no anonymous-inbound option, and just used a hidden service and p2p-bind-ip=127.0.0.1 and p2p-bind-port=18080, what would they see then?
03:45:46 <hyc> so it only can get published because you first contacted a clearnet peer. like one of the seed nodes
03:46:20 <hyc> monerod doesn't know anything about your hidden service unless you tell it via anonymous-inbound
03:46:39 <hyc> if you don't use that flag, nobody tries to contact you there.
03:47:03 <DeanGuss> OK.  Do they try to contact me at all or can I only do outbound with that config?
03:47:15 <hyc> clearnet ...
03:47:57 <DeanGuss> woah... so you're saying I'm connecting to outbound peers via clearnet?
03:48:06 <hyc> yes
03:48:09 <DeanGuss> even with p2p-bind-ip=127.0.0.1 ?
03:48:24 <hyc> bind-ip only affects incoming connections
03:48:32 <hyc> has no impact on outbound connections
03:49:20 <DeanGuss> wow so... I *still* have to use torify if I want monero to use tor?
03:49:24 <DeanGuss> after all this time
03:49:46 <hyc> you use --tx-proxy to tell it to use tor outbound
03:49:59 <DeanGuss> that's only for when I submit transactions to peers I thought
03:50:00 <hyc> but monerod always uses clearnet
03:51:03 <hyc> if you want everything outbound to go thru tor then yeah, use torsocks or whatever
03:51:25 <DeanGuss> my jaw is on the floor right now
03:51:31 <DeanGuss> how can that still be true
03:51:36 <hyc> ?
03:51:56 <DeanGuss> that we still can't proxy outbound connections via tor somehow within monero
03:51:59 <hyc> in general, tor is too slow
03:52:45 <DeanGuss> I don't buy that.  It's fine.  All my bitcoin traffic goes through tor just fine.  It's not like monero has more transactions than bitcoin
03:53:50 <hyc> there's also the problem of fending off sybil attacks if everything is going thru tor
03:54:10 <DeanGuss> Not if you use tor exit -> clearnet
03:54:16 <DeanGuss> I'm not trying to only use .onion
03:54:26 <DeanGuss> just I need everythign going through tor and actually
03:54:29 <DeanGuss> I think it already does that
03:54:32 <selsta> DeanGuss: --proxy flag
03:55:06 <DeanGuss> I just did a netstat and grepped for monero and I see there is not a single clearnet connection.  Everything is to 127.0.0.1:9050
03:55:37 <DeanGuss> selsta: hrmm... I seem to recall that, but thought it was fazed out when anonymous-inbound and tx-proxy came around
03:55:45 <selsta> no
03:55:47 <hyc> so you're already using tx-proxy
03:55:56 <selsta> but --proxy will use exit nodes
03:56:01 <DeanGuss> hyc: yes of course
03:56:17 <selsta> since we don't support p2p via onion, only transactions
03:56:23 <DeanGuss> does tx-proxy apply to every tx that I relay as well as submit?
03:56:49 <hyc> yes
03:56:56 <selsta> relay from other nodes?
03:57:04 <DeanGuss> selsta: yes
03:57:11 <hyc> there'd be no point if the txs were treated differently, that'd make them traceable
03:57:14 <DeanGuss> hyc well if that's true why would I need torsocks?
03:57:29 <selsta> quite sure they got propagated to clearnet
03:58:19 <hyc> sounds like you don't need torsocks, I prob misspoke earlier
03:58:33 <hyc> didn't understand your setup
03:58:58 <DeanGuss> and what is the difference between --proxy and -tx-proxy ?  --proxy is for outbound fetching of txs/blocks?
03:59:16 <selsta> proxy is a normal proxy, it does not understand tor
03:59:34 <selsta> tx-proxy has specific tor / i2p support and is specifically for tx
03:59:50 <DeanGuss> What do you mean understand tor?  You mean get .onion transport/name resolution?
04:00:10 <hyc> help for tx-proxy says it only affects local txs. didn't notice that before
04:00:29 <selsta> it will use the tor exit nodes, it does not connect to onion p2p nodes
04:01:04 <DeanGuss> selsta: Why would it care?  Does it not implement socks4a/socks5h (where the proxy does the name resolution)?
04:01:50 <hyc> but my daemons routinely log "unable to send tx to tor" and I haven't sent a txn t that time. I suppose it's relaying via dandelion+
04:02:18 <selsta> hyc: i think there might be 1 hop before they get to clearnet
04:02:36 <selsta> DeanGuss: what do you want to do exactly?
04:03:53 <DeanGuss> selsta: I want to advertise to the network that they can connect p2p for blocks and transactions at my onion, I want to connect to .onion and clearnet ips (but only via tor), and I want to submit transactions via tor.  I want everything to go out and come in over tor and I want clearnet in the mix to protect against sybils.
04:04:21 <DeanGuss> and I want restricted rpc available over my .onion as well
04:05:31 <hyc> you can't say "everything go out and come in over tor" *and* "clearnet in the mix"
04:05:44 <DeanGuss> yes I can, why not?
04:05:44 <hyc> to keep clearnet in the mix, something has to go out and come in over it
04:05:49 <DeanGuss> I want to reach clearnet via tor
04:05:53 <DeanGuss> not just .onion
04:06:18 <hyc> ah
04:06:28 <hyc> then we're back to using --proxy as selsta mentioned
04:07:47 <hyc> no idea how that looks in the peerlist
04:08:40 <selsta> like I said before, you can't sync blocks over onion, it will use exit nodes to connect to other clearnet nodes
04:09:09 <selsta> .onion nodes are only supported with --tx-proxy
04:09:09 <Wallet> selsta: Your default coin is now set to XMR. Change with coins command.
04:09:10 <Wallet> selsta: ≈$0.0588 • ≈ value of: 1 ONION • Source: cmc/ccc/altm
04:09:21 <selsta> you can use both --proxy and --tx-proxy
04:10:21 <hyc> what inbound addr:port is advertised to the peerlist when you use --proxy?
04:10:57 <selsta> the one from the exit node I would guess
04:11:10 <selsta> and inbound port is always random from what I remember
04:11:59 <hyc> monerod creates the peerlist entry, not the proxy. and the proxy isn't bidirectional
04:12:16 <hyc> monerod doesn't know its exit node address
04:15:10 <DeanGuss> selsta: so --proxy is for proxying to clearnet and --tx-proxy is for proxying to .onion, but I can't fetch whole blocks from .onion nodes?  Or do you just mean I can't fetch from .onion nodes with --proxy?
04:15:22 <selsta> yes
04:15:48 <selsta> I meant yes to the first
04:16:18 <selsta> there are no .onion pees with --proxy
04:16:20 <selsta> peers
04:20:49 <DeanGuss> hyc: I dunno a log about monero (so thank you and selsta for explaining at length), but if you have `bitcoin-cli getpeerinfo` handy it might be worth looking into how they do it:  For each peer they list eg. "network": "ipv4", "addr": "ip_of_peer:8333", "addrbind": "127.0.0.1:port", "addrlocal": "tor_exit_ip:port" where I have bitcoin setup to always use tor and connect to .onion and any ipv4 ip via tor.
04:21:03 <DeanGuss> s/log/lot/
04:22:35 <DeanGuss> selsta: ok cool.  So it sounds like I can achieve what I want if I use --proxy and --tx-proxy (everything goes through tor and I can talk to .onion and clearnet via tor)
04:23:36 <selsta> yes
04:24:28 <DeanGuss> Thanks.
04:25:55 <DeanGuss> So is there a concept of a reindex in monero? What if something goes wrong with the database index?
04:35:02 <DeanGuss> Maybe the need for such rpc calls is obviated by lmdb somehow
04:37:24 <Steven_M> selsta: oh, sorry. I didn't know about the 2nd fork.
04:48:19 <Steven_M> selsta: Is 0.18.0.0-release sufficient for the next fork?
04:56:08 <DeanGuss> Steven_M: Looks like yes unless you're using trezor or ledger with monerod: https://www.getmonero.org/2022/08/11/monero-0.18.1.0-released.html
04:59:31 <Steven_M> DeanGuss: that's what I thought, but figured I'd double check. Thanks. :-)
05:00:58 <Mochi101> Almost up to 9 hours here selsta and am at 81%
05:01:21 <Mochi101> about 1/2 a million blocks to go
05:01:37 <Steven_M> So why are there two hard forks so close together instead of a combined one?
05:03:13 <Mochi101> To make sure the network clears of any old style txs
05:03:20 <Mochi101> befire totally blocking them
05:03:55 <Mochi101> It's way overkill... but this is Monero. ;)
05:07:33 <Steven_M> Mochi101: Monero, finishing the job that Bitcoin left half-done. ;-)
05:08:13 <Mochi101> yes
09:41:52 <solinux_> Hello everyone
09:49:12 <rbrunner> Hello. "Everyone" is still a bit thin on the ground on this quiet Sunday :)
09:56:27 <solinux> rbrunner: he he :)
14:12:37 <hyc> DeanGuss: nothing can go wring with an LMDB index
14:12:44 <hyc> wrong*
14:14:13 <DeanGuss> cool, figured
14:14:37 <hyc> \bitcoin needs that because the DB it uses doesn't do atomic transactions
14:14:50 <hyc> so it can get interrupted in the middle of an update and leave stale index info
14:21:12 <moneromooo> < hyc> DeanGuss: nothing can go wring with an LMDB index    <-- windows can
14:21:39 <moneromooo> IIRC it was found to reorder some writes ?
14:30:40 <hyc> reordering doesn't matter as long as fsync happens when intended
14:31:11 <hyc> in safe:sync mode
14:31:14 <moneromooo> Except if it crashes in the middle. Which it does.
14:32:08 <moneromooo> And I suspect there's still a bug somewhere in db_lmdb.cpp, there's just too much report of corruption.
14:32:26 <hyc> hmm. I have an upstream patch for Windows to do unbuffered writes, that may solve any reordering issue
14:32:38 <hyc> corruption only on windows?
14:33:06 <hyc> I've never had any corruption on my nodes but they're all linux
14:35:04 <hyc> might try this commit da0527ac75b811419b7007202799f96b2edb5aef
14:35:15 <moneromooo> Mostly windows at least. Never had any either.
14:35:32 <hyc> and the one after it 147582b5dcd86d1d92bb9a3fda9eb640300ccae3
14:35:50 <moneromooo> Which repo is that exactly ?
14:36:02 <hyc> openldap and lmdb repos
14:36:38 <hyc> https://github.com/LMDB/lmdb
14:37:00 <hyc> might need the off_t patches right after taht too, don't remember
14:37:45 <hyc> https://github.com/LMDB/lmdb/commit/da0527ac75b811419b7007202799f96b2edb5aef
14:38:28 <hyc> doing write-thru writes means we don't even need to do an explicit flush/fsync
14:39:31 <moneromooo> ty
14:39:53 <moneromooo> Most windows users probably can't apply but hey, I'll mention them anyway.
14:40:06 <hyc> might be worth doing an experimental build
14:40:33 <hyc> but I don't have any machines that would run windows longterm
15:43:35 <selsta> binaryFate: https://community.rino.io/blocks/frequencies/ seems down
16:01:57 <selsta> hyc: can you look up if the off_t patches are required and link to them?
16:02:26 <selsta> then i can make windows binaries and i'm sure there will be a windows user who can test them
16:03:35 <Mochi101> Still syncing.. 92%
16:28:29 <nioc> Go mochi go
16:32:34 <Torr> Mochi101: Should change the nick to "Mochi92".
16:33:21 <Mochi101> A little over 20 hours
16:33:33 <Mochi101> selsta, you synced in 8 hours?
16:33:47 <selsta> yep
16:34:02 <Mochi101> Which ssd?
16:34:26 <selsta> Windows probably slows you down
16:34:46 <Mochi101> I have an 860 EVO in this.
16:35:18 <Mochi101> So I should upgrade to Gentoo?
16:44:02 <selsta> Mochi101: so it probably is a combination of your SSD not being the fastest and Windows
16:47:28 <Mochi101> Old hardware...
16:49:12 <selsta> the Mac Mini I used has a fast CPU and NVMe SSD, so basically ideal conditions
16:49:48 <Mochi101> I have an NVMe in my other laptop.
19:03:25 <hyc> selsta: yeah seems like it. basically use all of the commits from April 24-25 2020
19:04:05 <hyc> also https://github.com/LMDB/lmdb/commit/45745fcd072f1d78eb399417513c7ce0c6663d57
19:15:44 <selsta> hyc: will try that. what would happen if we update our lmdb to master?
19:16:02 <selsta> do we have any monero specific patches?
19:20:29 <hyc> no, there are no monero-specific patches, everything in our tree originally came from mdb.master
19:21:22 <hyc> we could prob just merge current mdb.master, I did a few full resyncs of that tree in the past
19:31:02 <selsta> hyc: opened this now but will need testing first https://github.com/monero-project/monero/pull/8501
19:31:03 <hyc> hmmmm. maybe. looks like b6420e12a967b8e96fd87a86dd8d105962bfdf8b
19:31:15 <hyc> is missing from upstream
19:33:55 <selsta> what patch is this?
19:34:38 <Mochi101> If you can get me a Win binary with that patch I can sync and see if there are any performance gains.
19:34:57 <Mochi101> Once this current sync is done I'll have something to compare it to.
19:35:00 <hyc> that was one mooo made to tweak errcodes
19:35:37 <hyc> and looking over the history, there are a few commits in our tree that came from mdb.master3 - the rawpart stuff, specifically
19:35:45 <hyc> that are deleted in your PR
19:42:29 <hyc> I've pushed mooo's patch upstream just now
19:53:20 <selsta> ok, will readd both
19:59:53 <Mochi101> selsta, didn't bother you the other day some housekeeping and all the requests to close on Github did it?
20:03:09 <selsta> Mochi101: github housekeeping is always good
20:03:20 <selsta> hyc: should the patches apply cleanly from master3 to master?
20:03:58 <selsta> Mochi101: if you see something to close you can comment or PM me the issue
20:40:32 <hyc> selsta: I don't recall now, they might have had some conflicts to resolve. best just to re-add the patches from our tree
20:43:19 <hyc> or I suppose I can push those into mdb.master. I really was only intending for bugfixes and not new features to go into mdb.master now tho
20:47:31 <selsta> hyc: maybe easier if I close my PR and you do it locally? then you don't have to push to master
20:48:34 <hyc> ah, just create a new local branch to PR?
20:48:37 <hyc> sure
21:06:29 <hyc> so yeah the question is whether this gives a noticeable perf boost on windows.
21:06:41 <hyc> it should...
21:07:04 <hyc> and should also fix write ordering
21:08:10 <selsta> Mochi101: did sync finish for you?
21:08:16 <selsta> then you can try the new one
21:09:00 <Mochi101> 123910 blocks to go
21:09:07 <selsta> will also try sync from scratch with it on Mac
21:09:15 <Mochi101> Will be a nice test.
21:29:58 <selsta> starting sync now
21:31:52 <hyc> Mac behavior should be unchanged
21:58:43 <Mochi101> Daemon is telling me that I have just over 3 hours left to sync over here.
21:58:52 <Mochi101> Going on 25 hours.
22:13:15 <selsta> Mochi101: mine is 49% already
22:13:37 <Mochi101> The first half goes super quick. Lots of empty blocks.
22:13:44 <Mochi101> ;)
23:17:40 <garth> Typical tx size pre bulletproofs was 13kb haha https://xmrchain.net/tx/03efa4e5c5c6d18758549c9154e1029e215d3bdfb95cd5b088fba308d9e5a02f
23:18:01 <garth> 1in2 out tx
23:23:39 <selsta> Mochi101: https://github.com/selsta/monero/suites/7809203879/artifacts/329641006 release-v0.18 with the lmdb patch
23:25:45 <selsta> yea the blockchain would be over 1TB without bulletproofs
23:32:35 <hyc> they were a miracle, badly needed