00:26:23 <Infinity8> Hello.
00:26:38 <Infinity8> Is it generally a good idea to use a new sub-address after every withdrawal from an exchange?
00:45:22 <Kronovestan> "BLOCK ADDED AS ALTERNATIVE ON HEIGHT" ... oh boy haven't seen that in a while!
01:39:46 <moneromooo> Doesn't matter since the exchange already knows it's the same person since it's the same account.
01:48:58 <sethsimmons> Sub-address per exchange would be good, but as moneromooo said per withdrawal doesn’t help you at all.
03:29:29 <h2017> i'm looking at the tari home page
03:29:41 <h2017> i do not know what merge-mined means?
03:30:07 <h2017> let me ask this will tari activity contribute to xmr mining difficulty?
03:44:53 <sethsimmons> h2017: https://tlu.tarilabs.com/merged-mining/merged-mining-scene/MergedMiningIntroduction.html
03:51:12 <h2017> so by briefly skimming this it looks like the tari chain submits transactions to the monero chain which are indistuinguishable from other monero transactions and all of the mining is done on the monero chain and the tari software has to monitor the monero blockchain for mined tari blocks
03:51:14 <h2017> something like that
03:52:15 <h2017> this makes monero technically unaware of tari
03:52:32 <h2017> but possibly the monero may have to have modifications in order to do its job, no?
03:56:32 <locustlord> anyone here experienced in building web-applications on monero?
03:56:59 <locustlord> so far I'm thinking I'm going to be using shell_exec for my website
03:57:06 <locustlord> since I need it to connect to the node
03:57:39 <locustlord> the way I've daemonized the monero node is using tmux
03:57:51 <locustlord> so that when I end the ssh session monerod is still running
03:59:44 <locustlord> I must say though it is syncing pretty quickly
04:02:26 <nioc> h2017: the monero and tari chains have no interaction
04:02:41 <nioc> as far as transacyions go
04:03:56 <nioc> if you choose to do so and the pool you are on supports it then mining either mines both
04:35:19 <gingeropolous> one should be able to use pruning for a public remote node right?
04:50:16 <monerouser1144> Hi all, I noticed that selsta updated the block.txt list of bad nodes, but today I noticed an IP (165.22.236.24) which was always 2 blocks ahead of the other 11 peers.
04:53:42 <nioc> monerouser1144: did you use the daemon command sync_info
04:55:37 <nioc> it will also show syncing as well as 2 blocks ahead for one of those bad nodes
04:59:06 <monerouser1144> Yes, it was "syncing" all day today (at least, I wasn't monitoring it the last week) http://paste.debian.net/1175800/
05:01:01 <nioc> yep another one
05:01:10 <monerouser1144> I mention it, because it was not included in the latest list of bad nodes by selsta.
05:02:34 <nioc> thx
06:15:16 <endor00[m]> <locustlord "so far I'm thinking I'm going to"> Dude, are you *asking* to get hacked? Because that's exactly how you get hacked
06:16:33 <endor00[m]> https://www.getmonero.org/resources/developer-guides/daemon-rpc.html this is how you interact with monerod from your application
08:14:58 <alphabetatester[> hi all
08:38:38 <qzesvgacztxw> Monero BADCACA nodes are proudly sponsored by Ryo Currency dev fund.
11:02:03 <Kronovestan> would not surprise me
11:48:54 <selsta> monerouser1144: updated, thanks
11:59:50 <Guest17775> selsta: have you considered using git to store the banlist? so that people can simply pull the updated version and commit new malicious know when they find them
12:00:22 <Guest17775> *malicious nodes
13:13:18 <selsta> Guest17775: could make sense, but with the next point release it will be less important to keep the ban list 100% up to date
15:11:48 <Mochi102> binaryFate, the blog post that xmr.to link to when the VPN warning text pops up 404's (https://test.xmr.to/blog/blogging-and-logging)
15:12:32 <Mochi102> if you take the test off it doesn't 404 :D
16:42:48 <binaryFate> thanks I'll pass along
16:55:22 <Tonux> binaryFate: I was under the impression you were not longer associated with xmr.to?
17:01:16 <moneromooo> Oh. That'd be good to know. The default assumption is whoever runs a cryptocurency business is a scammer, so if it's been transferred, that needs knowing :)
17:03:49 <Mochi102> lol
17:15:02 <Tonux> I mean, I'm open to being wrong. However I sware I remember reading somewhere that some service that was run by a Monero maintainer had been taken over by another corporation.
17:28:19 <honigkuchen> what do I do for not reconnecting always and always but getting always a few chunks from the chain
18:21:54 <locustlord> where is the blockchain stored in the linux cli version?
18:22:07 <locustlord> I need to know so I can delete it because my hard drive wasn't big enough for it
18:26:11 <FenderQ> $ du -hd 3 | sort -h
18:26:21 <FenderQ> $ du -hd 3 ~ | sort -h
18:26:24 <FenderQ> :D
18:27:22 <moneromooo> $HOME/.bitmonero
18:58:25 <locustlord> thanks moneromooo
19:43:06 <nos411> <hyc "can't prevent sybils from connecting...only make it expensive for them to do so." Is this the idea around comments I've seen about "p2p pow" on node connect?
19:44:54 <nos411> Looks like there was ideas from gingeropolous to try and do something with economic incentive with https://github.com/monero-project/monero/issues/3049
19:46:06 <moneromooo> That already exists.
19:46:21 <binaryFate> Tonux: I can pass info along whether I'm directly involved or not
19:46:48 <moneromooo> 2018, not sure whether thst exited at the time, though it's been a long standing thing I wanted to do.
19:46:52 <nos411> <moneromooo> "Randomx is too heavy to verify sadly.
19:46:53 <nos411> It will likely be Equix, or if not, keccak."
19:47:19 <nos411> Doesn't seem like it'd be providing any economic incentive it not able to do it in randomx though, no?
19:47:49 <moneromooo> If it's your electricity, it does.
19:48:26 <moneromooo> To be claer, those two things are different, not sure if you realize it.
19:49:01 <nos411> I'm really trying to surmise if this is an attempt to create a cost to "bad" nodes that could be used for sybil attacks
19:49:57 <binaryFate> <moneromooo> Oh. That'd be good to know. The default assumption is whoever runs a cryptocurency business is a scammer, so if it's been transferred, that needs knowing <--- nah, or I would say so. I'm just not personally operating much nowadays
19:50:27 <moneromooo> Thanks, sounds good.
19:50:42 <gingeropolous> nos411, yeah, that issue is for RPC remote node service. but yes, there are talks about p2p pow, which is different
19:50:45 <moneromooo> nos411: the PoW on connect is.
19:52:14 <nos411> Ok, I had an inkling that could be the case, but didn't have anything to go on aside from the 2-3 times I'd seen p2p pow mentioned since I made my way to IRC
19:53:52 <nos411> So to summerize, the p2p pow idea is to provide an economic cost (electricity usage) by forcing nodes to run some equix/keccak hashs on their side each time they connect to another node?
19:54:18 <nos411> Or if there's an issue/pr I could just read that'd be swell too.
19:54:57 <moneromooo> The idea is that it places a roadblock to the amount of assholery you can do.
19:55:14 <nos411> By forcing ALL nodes to pay the price?
19:55:20 <moneromooo> If you use a botnet, it's someone else's electricity anyway.
19:55:22 <moneromooo> Yes.
19:55:54 <nos411> It's creating a roadblock because it'll cost more to run many assholery nodes?
19:56:09 <moneromooo> Kinda.
19:56:36 <nos411> So there's more to it than just the additional electricity used to produce said hashs?
19:56:42 <moneromooo> It's on *connect*. It costs more to connect more. Honest people don't connect much. An asshole may connect a lot.
19:56:51 <nos411> Ah
19:57:35 <nos411> So, with the combination of the ban list and the need to rotate bad acting nodes IPs there will be lots of re-connecting required by bad nodes. I think I'm gronking it now.
19:58:01 <nos411> In addition to whatever other reasons a bad node would have to connect a lot.
20:00:37 <hyc> the physical resource cost isn't so much a factor as the time cost. it will slow them down.
20:00:39 <nos411> Would this raise the cost on the nodes though if they're cloud hosted?  Aren't those VMs typically charged by runtime?
20:00:56 <nos411> Oh, time is the real penalty then. ok
20:02:17 <moneromooo> If you wanted the penalty to be monetarily crippling, it'd take a *lot* of PoW.
20:02:57 <nos411> Yeah, I think I just conflated the economic incentive angle of the RPC remote node service onto the p2p pow idea and hadn't untangled them.
20:03:00 <moneromooo> And it'd be a self inflicted DoS really.
20:03:44 <moneromooo> One good way to see it is the ratio of bytes sent vs time spent rejecting that data (assuming it's bad).
20:03:48 <moneromooo> Keccak is pretty good for that.
20:04:06 <moneromooo> Equix much less.
20:04:31 <moneromooo> Another is the amount of CPU time the attacker has to expend vs the amount of CPU time you have to expend.
20:05:10 <moneromooo> That's selectable by a difficulty system. Equix has the advantage of preventing massive multithreading.
20:05:54 <nos411> I assume then it'll have to be more time/effort intensive to produce the hash than to verify it to work?  What's even going to be the source input to be hashed, some data sent from the node your trying to connect to?
20:05:57 <moneromooo> It's not super clear to me it's better, but since Tor is considering it rather than simply keccak, I'm piggybacking my preference on the assumption they thought about it already :)
20:06:11 <moneromooo> Yes.
20:06:34 <hyc> keccak is symmetric
20:06:43 <hyc> verifying is the same step as generating the hash
20:06:50 <hyc> which makes it poor from a PoW perspective
20:07:10 <moneromooo> Sure, that's why you put a dificulty thing.
20:07:45 <hyc> ... and also keccak is widely used, which means there's great incentive to accelerate it
20:07:48 <moneromooo> If you took a hash that took an hour to calc one hash and take a second to verify, it'd still be a bad hash to use, since one second.
20:08:08 <locustlord> how do I change the directory for the monero daemon to store the blockchain on the linux cli?
20:08:21 <hyc> and keccak is designed to be efficient in hardware, which means ASICs will far outclass CPUs
20:09:02 <moneromooo> --data-dir
20:13:01 <nos411> and the discussion of ASICs is with regard to the ability to possibly offload the p2p pow hashing work to hardware that can mitigate the time impact of doing the work?
20:13:59 <moneromooo> Yes.
20:45:43 <locustlord> when syncing my node running under stagenet, does it still download the whole blockchain?
20:46:33 <hyc> the whole stagenet blockchain, yes
20:46:37 <hyc> that's what syncing means
20:46:50 <locustlord> ok but it doesn't download the mainnet blockchain?
20:47:04 <hyc> you said it was stagenet
20:47:11 <hyc> whay would it touch the mainnet blockchain?
20:47:51 <locustlord> listen I just want to know whether I'll need to resync when I'm in production or not
20:48:05 <locustlord> the answer is yes from what you've told me so thank you
21:09:53 <gingeropolous> and equix is designed to be asic resistant methinks
21:11:30 <gingeropolous> ah yes that was mentioned
22:13:28 <xmrmatterbridge> <rayb> can anyone help with restoring my wallet. Im about to pull my hair out with it
22:35:43 <moneromooo> Do you have your seed (25 words) ?
22:36:05 <moneromooo> If so: monero-wallet-cli --restore-deterministic-wallet
22:36:11 <moneromooo> Then follow instructions.