00:23:20 <BarrySB> Who is very good with CLI?
00:26:10 <nioc> I am only very good at napping
00:26:24 <nioc> I now the CLI a bit
00:26:28 <nioc> know
00:27:13 <moneromooo> The lock command makes it go have a nap.
00:28:19 <nioc> trying to get through today on only 1 nap
02:30:42 <eck> how high does monero-wallet-cli want the mlock ulimit to be?
02:40:26 <BarrySB> how do i run daemon through tor on cli
02:49:15 <gingeropolous> BarrySB, there's a privacy network readme thing on the monero github
02:49:46 <gingeropolous> https://github.com/monero-project/monero/blob/master/ANONYMITY_NETWORKS.md
02:52:41 <BarrySB> I tried those commands they dont work for some reason
02:57:26 <gingeropolous> hrm
02:57:32 <gingeropolous> unrelated.. "'%s'
02:57:32 <gingeropolous>                                         will be replaced by the block hash
02:57:32 <gingeropolous> "
02:57:49 <gingeropolous> what does this mean...
03:01:44 <BarrySB> And how do i limit monerod cpu usage --max-concurrency does not work
03:04:03 <gingeropolous> there are various ways. are you still in initial block download?
03:04:13 <gingeropolous> syncronizing from scratch?
03:04:21 <gingeropolous> nice works the best if your in linux
03:05:01 <gingeropolous> but u can fiddle with upload and download rate limits, that can affect cpu usage.
03:14:54 <gingeropolous> well damn, %s doesn't mean it comes in as $1 for bash scripts...
03:17:15 <gingeropolous> oooh fuck yeah this worked: block-notify=/home/user/imascript.sh %s
03:26:32 <gingeropolous> ah shit. im gonna need to have an almost syncd chain for each instance of checking
03:31:13 <gmaxwell> Is there any coin-control hidden in the cli wallet to help avoid being tracked by a deanonmizing dust attack?
03:33:02 <gmaxwell> The attacker's pattern is to repeatedly make pairs of tiny payments to addresses that are known to him (public, maybe also leaked by exchanges and what not)..  if a transaction spends both of those outputs then it's really likely authored by their target.
03:34:49 <viperperidot[m]> Has anyone synced the blockchain on a raspi, if so about how long did it take?
03:35:52 <gingeropolous> gmaxwell, i think this command does that : "  sweep_single [<priority>] [<ring_size>] [outputs=<N>] <key_image> <address> [<payment_id (obsolete)>]
03:35:52 <gingeropolous> "
03:36:52 <gingeropolous> knaccc, ^
03:38:09 <gingeropolous> though this would mainly be a concern for subaddresses right?
03:39:58 <gingeropolous> <viperperidot[m]> Has anyone synced the blockchain on a raspi, if so about how long did it take? <<< i've done a pine64 on a 5400 rpm. it took about a week.... many years ago...
03:43:34 <gmaxwell> gingeropolous: thanks, I'll look into it.
03:58:34 <knaccc> gmaxwell that's a very interesting attack, thanks for mentioning it, i don't think we have any dust threshold. what gingeropolous mentioned is simply a command to spend all available outputs, so that you can spend dust into a single output prior to then keeping or spending that combined output in the future
03:59:52 <knaccc> gingeropolous it applies to the main address or the subaddress. you sevearl  tiny outputs, and if you see them spent together in the same TX, you can predict with very high probability that the tx is by the owner of those dust outputs
04:01:02 <knaccc> s/you sevearl  tiny/you send several tiny
04:05:13 <knaccc> the same problem happens if you ask for payment of 1 XMR, and you are sent that 1 XMR via 4 0.25 XMR outputs. and now if you spend them all together it's obvious it is you spending them
04:05:26 <knaccc> so a dust threshold isn't a panacea
04:09:59 <nioc> knaccc: I thought in the 4 x 0.25 scenario, doing sweep single with each of the outputs first made it so that when spending them all together it isn't obvious it is you spending them
04:10:46 <knaccc> nioc if you sweep them individually and then combine, that's worse than if you sweep them all together and then spend
04:11:14 <knaccc> unless you do repeated sweeps individually first
04:11:34 <nioc> ok
04:12:35 <knaccc> nioc i meant to say: if you sweep them individually and then combine (by spending them to someone else)
04:14:51 <knaccc> i think i determined that if you want to sweep/churn outputs individually first, my recommendation is to churn outputs individually at least 3 times, and not to later combine them within 24hrs of receipt
04:16:31 <nioc> that was from the discussion in MRL a month or 2 ago?
04:16:34 <nioc> I have no sense of time
04:16:46 <knaccc> nioc that's right, well remembered!
04:16:54 <knaccc> July
04:16:58 <knaccc> or Aug maybe
04:17:39 <nioc> even if combining and sending to oneself?  aka sweep_all
04:18:24 <knaccc> nioc can you clarify the entire situation you're referring to pls?
04:19:43 <knaccc> you mean churn 2 outputs individually first, and then later combine into one output for yourself, to keep until you want to later spend?
04:19:55 <nioc> sweep_single > sweep_all to yourself
04:19:58 <nioc> # of each step recommended = ?
04:20:14 <knaccc> i think even in that situation, you'd want to wait 24hrs to combine, so it's not clear that the combined output is from the two outputs individually churned
04:20:59 <nioc> and sweep_single = 2x ?
04:21:27 <knaccc> https://gist.github.com/knaccc/78c691aa1c1e0710bb8264ef17b56768
04:21:36 <knaccc> see the MergeAnonymitySetSize section
04:21:49 <nioc> thx
04:22:08 <knaccc> if the window of churning followed by merging is tightened, that hurts your anonymity set size on the combination
04:22:26 <nioc> probably saved in my monthly monero folder
04:23:03 <nioc> nope, now it is
04:23:28 <knaccc> and btw my 3-churn recommendation only applies to situations with 2 outputs
04:23:43 <knaccc> it'd have to be more than 3 churns if you had >=3 outputs
04:25:10 <nioc> thumbs up
04:34:41 <nioc> this is for outputs know by an entity that you might be concerned about, not something that needs to be done with all outputs
04:35:34 <nioc> *know=known
04:45:45 <eck> hello friend i compiled v0.17.1.1 from source and just finished syncing the blockchain and now i get a lot of errors like this (filtered thru c++filt) in my bitmonero.log https://monad.io/vgbpjdtwa.txt is this a known issue
04:49:00 <BarrySB> CLI has no currency view?
04:49:04 <eck> for some reason it didn't dump core
04:49:20 <eck> how do i get the threads to dump core i know c++ i might be able to help
12:33:01 <midipoet> when upgrading to 17.1.1, what is this error about?
12:33:02 <midipoet> 2020-10-24 12:31:40.923	E failed to find transaction input in key images. img=<d7428752aaf65321096300e269824aeeb05e1e76558e039ec40f0f0190c90a9f>
12:33:02 <midipoet> 2020-10-24 12:31:40.923	E transaction id = <32bc8a06350db2a64d6839be1d5cab840f03e020c8ee4a011f0aac8926898a03>
14:53:02 <tficharmers> Anyone seen a 'E Difficulty drift detected' error before?
14:53:13 <tficharmers> When starting monerod
14:57:25 <moneromooo> Yes. It is bad, and thought fixed, but apparently not fixed.
14:57:43 <moneromooo> Did you start monerod on an old chain ?
15:00:19 <tficharmers> Most likely. I'm using pinode-xmr which I thought had updated to 0.17, but hadn't for a variety of reasons. So I had rebooted several times until I realised I was on the wrong chain. No worries. At least I know. I presume sync from scratch? It's not salvageable?
15:00:50 <tficharmers> --db-salvage doesn't work btw
15:02:11 <moneromooo> It *should* be automatically fixed if the problem was recent, but it has no way to know for sure that the error doesn't date from way before.
15:02:26 * moneromooo goes find the fix patch..
15:03:26 <moneromooo> 0fd6ccef2164f8a40988df16d37175a16ed27128, June 2020. If your chain was from before you updated to a daemon with that in, it's expected to get this message if your db was borked.
15:03:51 <tficharmers> Right. Well it's complaining about a block about 200,000 blocks ago.
15:03:53 <moneromooo> If your db got borked *after* you switched to a daemon with that patch in, it means the bug is not fixed.
15:04:06 <moneromooo> OK, so that must be before hte patch.
15:04:21 <moneromooo> I didn't remember it went back htat far to check.
15:04:24 <moneromooo> That's good :)
15:04:44 <tficharmers> No worries. I'll sync from the start. Cheers
15:05:18 <moneromooo> Set --out-peers to a lot more than 8, and limit-down to a lot too. Speeds things up.
15:05:31 <tficharmers> +1
16:12:54 <cdhdzpzkcj> Dear fireice_uk. I must strongly object to you reporting our great Monero community members
16:12:54 <cdhdzpzkcj> to Freenode for racism AND getting people K-lined as a result! https://i.imgur.com/R0T9GGY.png
16:12:55 <cdhdzpzkcj> THEY ARE NOT NEO-NAZI!!! THEY ARE JUST SAYING NEO-NAZI THINGS!! https://i.imgur.com/JYu44As.png
16:12:56 <cdhdzpzkcj> I know this because they have been nice to me and made me their Magical Crypto Friend!
16:12:57 <cdhdzpzkcj> If you don't cease immediately I shall throw another tantrum!
16:12:58 <cdhdzpzkcj> Monero Community Member
16:12:59 <cdhdzpzkcj> PS. You are interrupting my session of masturbation to The Man in the High Castle.
16:33:51 <ErCiccione> ryo trolls at it again?
16:47:50 <moneromooo> Poor guy. Living with that for *years* now.
16:48:28 <moneromooo> I've seen what that does to another and it ends shittily :/
16:55:35 <zib> there's good people on both sides
16:55:37 <zib> :D
16:55:41 <msvb-mob> The last Monero Village meeting before Grayhat (security conference) begins in five minutes on #monero-community.
17:53:07 <charuto> https://github.com/ytdl-org/youtube-dl/
17:53:30 <charuto> maybe it's worth giving another thought to ditching github?
17:53:50 <moneromooo> They broke the discrete logarithm problem ?
17:56:45 <charuto> if that's what it takes to consider moving to a more foss friendly and censorship resistant platform, sure, i have on good source they have
17:57:36 * moneromooo steps back carefully
18:18:30 <fluffypony> charuto: we already have stuff in play if something goes wrong
18:19:03 <fluffypony> if you read the DMCA complaint (which actually isn't a DMCA takedown, just disguised as one) it's clear that the youtube-dl authors were quite egregious
18:19:20 <fluffypony> in the readme they encouraged people use the tool for stuff that is "illegal"
18:19:39 <fluffypony> so it was only a matter of time before they pissed the RIAA off
18:25:31 <Mochi101> Really Ignorant Advertising Agency?
18:25:50 <fluffypony> Mochi101: that's the one lol
18:43:09 <asymptotically> .seen mafiaa
20:12:58 <d4ndo[m]> Check this out. https://radicle.xyz/    A nice github replacement.
20:13:34 <d4ndo[m]> Implemented in rust
20:17:01 <d4ndo[m]> But it is not ready. Still in early stage development.
20:19:10 <selsta> fluffypony: apparently these were unit tests, not the README
20:19:32 <selsta> youtube would often change how music videos are delivered so they had unit tests to see if things change
20:19:41 <selsta> probably still not a good idea to push that code to github
20:46:16 <gingeropolous> so it sounds like we need more specific output control?
20:48:00 <moneromooo> freeze/thaw does what he asked.
20:48:17 <moneromooo> (told him already)
20:49:50 <gingeropolous> ah i missed it. thanks, good to know
20:50:25 <gingeropolous> i haven't surfed the wallet-cli help recently
21:09:11 <yanmaani> Mochi101: Damn, they made you guys ban people for politics? Or it's fake?
21:09:49 <Mochi101> huh?
21:12:40 <monerouser1144> Is the Monero blockchain db file .../lmdb/data.mdb amenable to periodic rsync (meaning is new data mostly appended to its end) ? Because I re-run rsync and it started from scratch.
21:16:22 <moneromooo> What a coincidence. Someone with the same nick as yours asked that yesterday too.
21:16:50 <moneromooo> We told that person that yes, provided monerod is not running at the same time.
21:21:57 <monerouser1144> It was me :-)  As I said, I sync'ed the db while monerod was running (accepting that the db would be in inconsistent state), then stopped monerod and re-run rsync. But rsync started sync'ing from scratch ... (note: using -avP options for partial transfers).
21:23:05 <moneromooo> Could be lmdb rewrote early pages.
21:23:28 <moneromooo> Probably did, the head changes for the txn number.
21:23:37 <moneromooo> It should still skip a lot.
21:29:36 <yanmaani> Mochi101: : There was a spammer who posted this: https://i.imgur.com/R0T9GGY.png
21:30:28 <monerouser1144> When I first tested it 2 days ago (starting and stopping rsync several times), it did skip a lot indeed. However today it started from scratch and re-downloaded the first 15GB again (note: I'm using pruned db, if it makes a difference).
21:31:26 <moneromooo> if it's fireice, it's a dude with some creepy stalking obsession, ignoring's best.
21:31:38 <Mochi101> yanmaani, well... I gave up my ops in that channel... but yeah... that's how it was
21:31:51 <Mochi101> Was a long time ago though.
21:31:52 <yanmaani> When was this?
21:32:00 <yanmaani> Oh, right.
21:32:02 <yanmaani> Do you still do it?
21:32:04 <Mochi101> Over a year ago now, abouts.
21:32:22 <Mochi101> I'm not an op in that channel.
21:32:23 <moneromooo> OK, not sure what algorithm, rsync uses, but 15 GB sounds odd.
21:32:24 <yanmaani> You weren't a small project then though. Do you really think they'd have banned you?
21:32:44 <Mochi101> for sure
21:32:59 <yanmaani> It'd have pissed a lot of people in the crypto space off
21:33:30 <Mochi101> It's Freenode's house.
21:33:50 <yanmaani> Well, it's easy to threaten, but banning a channel of a major cryptocurrency with 422+ users?
21:38:17 <Mochi101> yanmaani, it's a side channel...
21:38:27 <viperperidot[m]> <moneromooo "if it's fireice, it's a dude wit"> Really? Is that the person who runs RagerX?
21:38:50 <yanmaani> Mochi101: I'd imagine it's all or none for them
21:38:50 <syntax[m]> <monerouser1144 "Is the Monero blockchain db file"> If you're after a backup, have you tried `monero-blockchain-export`? I export the blockchain file periodically to an m.2 SSD.
21:39:02 <yanmaani> If you're a small channel, yes they can tell you to get lost
21:39:16 <yanmaani> but if you're a big channel, it will cause a lot of problems for them if they do that
21:40:33 <nioc> viperperidot[m]: yes
21:41:51 <monerouser1144> @syntax[m] yes, I'm trying to find the best way to backup a node with a pruned db. So that if I have to rebuild it, I won't need to burden the network redownloading the full blockchain.
21:42:41 <jwinterm> if I want to access my remote nodes json_rpc, do I just leave off --restricted-rpc option when launching daemon?
21:42:58 <Mochi101> make a copy of it and then back that up monerouser1144?
21:43:09 <jwinterm> and what is the danger of not using --restricted-rpc?
21:43:36 <Mochi101> start_mining jwinterm's machine with my wallet address
21:43:48 <jwinterm> .hmmm
21:44:07 <azy> https://www.monero.how/how-to-run-monero-node
21:45:31 <jwinterm> --restricted-rpc # Restricts the actions that external users can perform when they are connected to the node over RPC. You will typically want to use this option.
21:45:40 <jwinterm> wow, now I understand what it does completely
21:45:57 <monerouser1144> So ... monerod exit; cp -rp ~/bitmonero ~/bitmonero.bak ; monerod --detach ; ... and rsync/backup that dir ? (it'll require double the space 2x 26GB but if there is no alternative)
21:45:59 <moneromooo> You can set two RPC ports, one you firewall out and one you don't.
21:46:06 <moneromooo> And only one restricted.
21:47:37 <zjnhvpgb> Dear fireice_uk. I must strongly object to you reporting our great Monero community members
21:47:38 <zjnhvpgb> to Freenode for racism AND getting people K-lined as a result! https://i.imgur.com/R0T9GGY.png
21:47:38 <zjnhvpgb> THEY ARE NOT NEO-NAZI!!! THEY ARE JUST SAYING NEO-NAZI THINGS!! https://i.imgur.com/JYu44As.png
21:47:39 <zjnhvpgb> I know this because they have been nice to me and made me their Magical Crypto Friend!
21:47:40 <zjnhvpgb> If you don't cease immediately I shall throw another tantrum!
21:47:41 <zjnhvpgb> Monero Community Member
21:47:42 <zjnhvpgb> PS. You are interrupting my session of masturbation to The Man in the High Castle.
21:48:00 <selsta> binaryFate fluffypony luigi1111 please ban ^^
21:50:59 <viperperidot[m]> <nioc "viperperidot: yes"> Is that not a community trusted pool? I actually have it running on one of my old laptops right now just for fun.
21:51:08 <monerouser1144> Instead of opening up RPC on the remote node running monerod, I am connecting to localhost:18081 over an ssh tunnel. After doing it, I came across an old tutorial about it: https://garlicgambit.wordpress.com/2017/01/10/monero-how-to-connect-wallet-to-remote-monero-node-with-ssh/
21:51:41 <nioc> well it is a pool
21:51:55 <nioc> and charges a very high fee
21:52:00 <selsta> ragerx is closed source too
21:53:17 <asymptotically> it's also multiple pools masquerading as one too (cryptosewer seems to be a separate pool, but your miner is controlled by the same guy). if it actually had miners i would say that it's bad for the network since it makes it seem more distributed than it is :P
21:53:21 <ndorf> monerouser1144: there's a great guide at https://github.com/jonathancross/jc-docs/blob/master/ssh_tunnel_to_full_node.md
21:53:52 <viperperidot[m]> Hmmm yeah, the reason I liked it was because I could boot it from a live usb which works on this old laptop I have, if I tried to boot the real os it would be pretty bogged down lol.
21:55:52 <jwinterm> ok I'm a dumbass
21:56:02 <jwinterm> was trying to curl on wrong port
22:03:01 <monerouser1144> ndorf: Thanks, both guides "how to connect to remote monerod over ssh tunnel" are good. Since I use only the cli wallet, my own steps are closer to the other guide.
22:10:53 <jwinterm> what is the histogram in get_transaction_pool_stats?
22:11:17 <moneromooo> How many txes waiting for how much time.
22:11:40 <jwinterm> oh I thought it was how many txs per size
22:12:08 <jwinterm> what is the time interval for each bin in histogram?
22:14:48 <moneromooo> The first column.
22:19:57 <jwinterm>  "histo": [{
22:19:59 <jwinterm>       "bytes": 3933,
22:20:03 <jwinterm>       "txs": 2
22:20:05 <jwinterm>     },{
22:20:07 <jwinterm> ?
22:22:05 <moneromooo> If from RPC, it's... /me looks it up
22:23:55 <jwinterm> syncing to test it out in local daemon but gonna be a while
22:24:08 <jwinterm> but yea that was from rpc
22:24:12 <moneromooo> the oldest timestamp (same RPC) divided by the number of quantiles.
22:24:46 <jwinterm> (current time - oldest timestamp)/number of quantiles ?
22:26:14 <moneromooo> Yes. See what it does in rpc_command_excutor.cpp
22:26:33 <jwinterm> thx mooo
23:31:35 <DeanGuss> I noticed monerod is pegging 1 core constantly at 100%
23:31:39 <DeanGuss> 2020-10-24 00:08:53.003	[P2P2]	WARNING	global	src/cryptonote_protocol/cryptonote_protocol_handler.inl:2670	monerod is now disconnected from the network
23:31:39 <DeanGuss> 2020-10-24 04:09:35.256	[P2P4]	WARNING	net.p2p.tx	src/cryptonote_protocol/levin_notify.cpp:428	Unable to send transaction(s), no available connections
23:31:52 <DeanGuss> and the last line there repeated a few more times are the last thing in the log
23:32:16 <DeanGuss> I use torsocks to start monerod from systemd.  But Tor is up fine
23:33:04 <moneromooo> sudo perf top -a
23:35:20 <DeanGuss> ok... what am I looking for?
23:38:36 <moneromooo> What's on top.
23:38:59 <moneromooo> You can zoom in monerod too, gets rid of unneeded lines.
23:39:08 <moneromooo> Select somehting from monerod, enter
23:45:12 <DeanGuss> [kernel] do_syscall_64 is @ 26%
23:45:17 <DeanGuss> monerod is not anywhere in sight
23:46:08 <moneromooo> top, check third line, see if sy% is high.
23:46:12 <moneromooo> Might be swapping.
23:46:20 <moneromooo> wa% would be the disk i/o
23:48:36 <DeanGuss> sy is 13.8, wa is 2.1
23:48:42 <DeanGuss> in htop I'm using a lot of swap
23:49:01 <DeanGuss> I only have 4g and am also running bitcoind
23:51:43 <DeanGuss> But my memory is not all used (at least anymore)... so I dunno why my swap is not reduced by now
23:54:11 <DeanGuss> when I run htop and select the offending monerod thread with strace by pressing s it just repeats this continuously:
23:54:12 <DeanGuss> select(28, [27], NULL, NULL, NULL)      = 1 (in [27])
23:54:13 <DeanGuss> recvfrom(27, "", 10, 0, NULL, NULL)     = 0
23:54:17 <DeanGuss> if that means anything to you
23:55:47 <moneromooo> select is a blocking wait, it's what typically is used to sleep waiting for something to happen. It typically means it's fine.
23:56:19 <moneromooo> recvfrom reads from I/O.
23:56:51 * moneromooo can't recall whether recvfrom is network only or for all fds. I think network...
23:57:05 <moneromooo> In any case, that doesn't seem odd at all.
23:58:32 <DeanGuss> It doesn't seem odd that a monerod thread is continuously pegging 100% of 1 core while doing not much of anything except waiting for blocks and transactions?
23:58:53 <moneromooo> It does.
23:59:19 <moneromooo> What doesn't is your htop output.
23:59:58 <DeanGuss> Ah.  Well if I can help you figure out if this is a bug let me know