07:00:17 <azy> https://paste.debian.net/plain/1162729
11:59:34 <anicow> https://www.tecmint.com/create-own-ipsec-vpn-server-in-linux/
12:35:15 <orion> Hi. How do I send the entire contents of my wallet to a friend using the CLI? I need to take in to account network fees.
12:35:31 <asy> orion: you can use the sweep_all command
12:35:35 <asy> sweep_all yourfriendsaddress
12:35:55 <asy> you might need to add index=all if some of the coins are "in" a subaddress
12:36:23 <artefact> if you lave lots of separate inputs, might be better to do multiple transactions
12:37:06 <orion> asy: Thanks!
12:37:12 <orion> artefact: What is the technical reason for that?
12:38:55 <asy> orion: one reason might be that if you spend multiple inputs at once, it links the ownership of them together. another is that the transaction can get big, but i think in that case the wallet will offer to split it up for you
12:39:30 <orion> Ah, good point.
12:41:36 <orion> How long does it usually take to complete a "sweep_all" command? It's been about 2 minutes and I haven't gotten any response since entering my password.
12:44:33 <orion> Aww... segmentation fault. :/
12:45:09 <asy> D: i don't think it's meant to do that
12:46:33 <asy> if it happens again it might be helpful to the devs if you can attach a debugger and get it to print a stack trace
12:58:55 <selsta> orion: are you using a hardware wallet?
13:00:59 <orion> selsta: Yes, Trezor.
13:01:27 <selsta> Latest firmware? Also using v0.16.0.3?
13:04:03 <orion> Yes. No: v0.16.0.0-release
13:10:56 <orion> I've restarted the CLI, and I was prompted to allow a "Refresh" of my Trezor. This operation is taking quite a while.
13:11:45 <orion> Is it accurate to say that the wallet file stored on disk is really just a cache that can be re-generated at any time?
13:11:55 <orion> (So long as the Trezor is present)
13:12:29 <selsta> some data can not be regenerated but you will have access to your funds, yes
13:13:36 <Inge-> orion: the un-regeneratable wallet data includes destination addresses you send to and any tags you have given to addresses etc. But funds are safu with the HW wallet only (or the mnemonic seed)
13:13:57 <orion> Makes sense.
13:15:26 <selsta> HW wallets have slow processor so sweep_all taking ages is normal, depending on the amount of inputs. Segfault should not happen.
13:17:40 <orion> I see.
13:22:08 <orion> The last message printed before it crashes is "Please confirm the transaction on the device"
13:22:33 <selsta> Did anything show up on device?
13:22:43 <orion> No.
13:23:53 <orion> I've restared the CLI, and it's doing the refresh again. If I exit the CLI gracefully, will it write out the results of the refresh to disk so I don't have to wait >20 minutes between invocations?
13:24:12 <selsta> yes
13:24:21 <selsta> also please try to update to v0.16.0.3
13:25:45 <selsta> also just to confirm, you have Trezor firmware 2.3.3?
13:29:23 <orion> Confirmed. I just tried for the third time and it worked. *shrug*
13:29:50 <Inge-> ahaha. I tried sweep_all with like 100 inputs. That was a no-go with a HW wallet
13:29:56 <Inge-> it just died
13:29:58 <Inge-> trying
13:31:10 <Inge-> orion: fortunately you can do sweep_below and tune it to a manageable size and multiple operations, so you hw_wallet has a chance to do its thing
13:31:33 <orion> I see, thank you.
13:45:59 <yonatanbls[m]> What’s up
13:46:08 <raecarruth> the sky
16:50:32 <azy> https://paste.debian.net/plain/1162729
17:23:23 <Thominus> so.. if using tx-proxy via tor: Does the node ID get sent over tor connections? - and if so: is it still the same as that used on the clearnet side?  - I saw 4-year old post about it in reference to using torsocks, and wondering if that was maybe addressed in the tx-proxy implementation?
17:26:37 <moneromooo> It is sent. And it's not the same.
17:26:52 <Thominus> oh excellent
17:31:59 <duso> Is someone able to link me or ELI5 what difficulty and effort means with mining?
17:33:23 <moneromooo> difficulty is how many hashes are expected on average to find a block. A difficulty of 1 -> Every nonce will yield a valid block.
17:34:05 <moneromooo> Difficulty of 12 -> A twelvth of the nonces will yield a valid block on average.
17:34:08 <smak> ya its like the sliding scale that evens new issuance of coin with distribution among mining participants
17:44:47 <Thominus> Any suggestions how to find .onion peers for use with tx-proxy? So far the only list I have discovered is the ones on the moneroworld page
17:46:06 <duso> Thanks moneromooo , that was simple and clear, unlike any of the sites I had googled so far. So effort is how many attempts it took against current difficulty, so if currently difficulty is 12, and I solve the hash on the 6th attempt, 50% effort, but if it takes me 24 attempts, then 200% effort. ok, I get it
17:49:07 <asy> duso: just to confuse you, some pools show luck instead of effort. 0% luck would be 100% effort
17:53:32 <duso> I must be doing something wrong with xmrig though, cause in the forums they talk like 7500h/s and I only average 1200h/s with a xeon e3. bbiab
17:59:06 <duso> so yeah, xeon e3-1230v6 @ 3.5GHz and I get 1200h/s, I thought I would get a lot more.
18:03:49 <moneromooo> Huge pages ?
18:16:37 <duso> http://ix.io/2wej
18:16:44 <duso> Huge pages are supported
18:18:10 <ndorf> i don't think that cpu can do 7500. https://www.betterhash.net/Intel(R)-Xeon(R)-CPU-E3-1230-v6-⊙-5h says 1455
18:18:20 <ndorf> looks like it only has enough L2/L3 for 4 threads.
18:19:35 <duso> I am not too concerned, I have xmrig running in a jail on a file server that I keep running 24/7 anyway. I just thought a xeon would get better  hashrate
18:20:33 <duso> then I hear about people running amd 3300 etc getting 7500h/s and I get sad panda
18:21:22 <hyc> all intel CPUs suck at randomx
18:21:26 <ndorf> yup, ryzens get the best hashrate
18:21:28 <hyc> they're all lacking on-chip cache
18:21:34 <ndorf> i hope you are not paying the electric bill for that file server, lol
18:23:13 <duso> I am, its my home/work lab and would be running 24/7 anyway, so I don't think running xmrig on it would add too much extra costs
18:23:32 <sech1> 4 cores, 8 MB cache, you should be doing somewhere around 2.5 kh/s
18:24:04 <ndorf> duso: it will definitely consume more power under load, than when idle
18:24:32 <sech1> of course if it's a dedicated server and not some VM. 1200 h/s in a VM is a good result
18:27:09 <duso> mainly doing it to contribute to the distributed monero community, especially now that the gov't is banning privacy coins here in Australia
18:28:59 <duso> Interesting about the claims of ciphertrace claiming they could trace monero payments, glad it all turned out to be fud
18:29:39 <epoch> Out of curiosity, why do you opt to chat over IRC as opposed to other encrypted alternatives i.e. matrix?
18:30:10 <selsta> duso: I don’t think gov has banned privacy coins in Australia.
18:31:30 <ndorf> they've been delisted from exchanges there, presumably in response to some kind of government pressure
18:31:44 <selsta> AFAIK it was due to a bank used by these exchanges.
18:31:49 <duso> I think we had this discussion the other day. I could not find any actual legislation but somehow they are threating to debank any exchanges that are authorised to operate in australia if they allow privacy coins
18:32:51 <duso> which reminds me, I wanted to learn more about atomic swaps
18:33:11 <ndorf> epoch: what exactly would be the point of encrypting a public chat that is open to all?
18:33:45 <ndorf> selsta: pure speculation of course, but wouldn't they just get a different bank if it were that simple?
18:33:46 <anicow> i use irc because im not at home any damn way..
18:33:58 <anicow> do your worst...
18:34:12 <selsta> ndorf: I would guess there aren’t too many banks that are crypto friendly.
18:34:51 <endogenic> workin on that
18:35:12 <ndorf> selsta: sure, but if there isn't even one, i suspect it's because they're all being pressued by their regulators, rather than coincidentally all share some deep ideological opposition to it
18:36:58 <bonedaddy> whats the purpose of huge pages fro monero minin?
18:37:51 <ndorf> bonedaddy: make it faster
18:38:16 <bonedaddy> is there a max number at which higher increases provide reduce performance? or can i set to some outrageous number like 1024
18:38:50 <bonedaddy> on linux that is using sysctl (sudo sysctl -w vm.nr_hugepages=1024)
18:38:52 <ndorf> ideally you want 3 1GB pages and $num_threads regular (2MB)
18:39:11 <epoch> @ndorf to stop your isp snooping on your chat and to engage in conversation whilst remaining anonymous
18:39:29 <ndorf> epoch: you can connect to freenode over tor
18:40:06 <epoch> ndorf: ok, thanks
18:40:45 <ndorf> epoch: they have a hidden service, https://freenode.net/news/tor-online
18:41:21 <ndorf> bonedaddy: this is the optimal huge pages setup: https://github.com/xmrig/xmrig/blob/master/scripts/enable_1gb_pages.sh
18:41:41 <bonedaddy> neato
18:41:42 <bonedaddy> thanks
18:42:03 <ndorf> bonedaddy: if you can't or don't want to use 1GB pages, you will want enough of the regular 2MB huge pages to make up for that.
18:42:56 <epoch> ndorf: thanks
18:48:15 <bonedaddy> interesting that script lowered my hashrate
18:48:29 <duso> https://fee.org/articles/australia-s-unprecedented-encryption-law-is-a-threat-to-global-privacy/
18:48:33 <bonedaddy> sudo sysctl -w vm.nr_hugepages=4096 boosted it by about 1.75kh/s
18:49:22 <ndorf> the only way it should lower your hashrate is if the 1GB part fails
18:49:32 <ndorf> that might happen if your system has been up for a while and in use. run it right after rebooting
18:50:06 <ndorf> assuming you restarted xmrig after running it, if not, definitely do that first
18:51:14 <bonedaddy> yea i restarted xmrig
18:51:28 <bonedaddy> i wonder if its because it set nr_hugepages to lower than 4096, it set it to 56
18:51:48 <bonedaddy> im kinda just fucking around and setting nr_hugepages as high as it goes before the machine crashes and ecah time i increase it higher hashrate goes up lol
18:51:55 <ndorf> yes, because with the 1GB pages, you only need 3 of those plus one 2MB page per thread.
18:52:05 <bonedaddy> ah ok
18:53:04 <ndorf> without 1GB pages, you need a lot more of the 2MB ones.
18:58:45 <bonedaddy> well not too shabby about 15kh/s increase from this
18:58:45 <bonedaddy> tyvm
18:59:12 <ndorf> 15k increase? wow, what is your total hashrate?
18:59:32 <bonedaddy> without waiting for the charts to update im guessing right now 40kh/s
18:59:37 <ndorf> sick
19:00:10 <bonedaddy> still got 1 last machine to test this out on, which will bei nteresting because it doesnt have AES cpu processor and its only getting about 1.5kh without this huge page stuff
19:00:58 <ndorf> no AES? is it like 10+ years old?
19:01:26 <bonedaddy> yea
19:01:27 <bonedaddy> lol
19:10:57 <derpy_bridge_> <[discord] Yonatan#6948>: What CPU doesn't come with AES modules?
19:11:10 <derpy_bridge_> <[discord] Yonatan#6948>: Isn't it a basic thing?
19:11:14 <selsta> Raspberry?
19:11:30 <derpy_bridge_> <[discord] Yonatan#6948>: They don't come with AES modules?
19:11:44 <duso> My old pentium didn't have AES
19:12:08 <selsta> Yonatan: afaik no
19:13:31 <derpy_bridge_> <[discord] Yonatan#6948>: Lmao
19:17:01 <endor00[m]> nope, RPi doesn't have hardware AES
19:17:11 <endor00[m]> Pine64 does
19:17:42 <endor00[m]> maybe the RPi 4 does though, can't remember, but up to the 3B they definitely didn't
19:18:13 <ndorf> i had an old server with xeon L5520, released 2009 with no AES. replaced with L5630, <1yr newer, which has it
19:22:46 <sech1> Intel CPUs starting with Westmere (2010) have AES
20:30:35 <Inge-> looks like Arm-V8 has AES and sha-2 instructions. rpi4 is Cortex-A72 which is Arm-V8 if I understood things
20:32:17 <Inge-> on the other hand it doesn't look like it has been licensed/activated in the rpi4
20:47:31 <endor00[m]> https://raspberrypi.stackexchange.com/a/111285
20:47:31 <endor00[m]> That looks to be the case. No license, so it is not enabled in hardware
22:05:24 <hyc> none of the raspberry models have AES
22:06:49 <hyc> which IMO makes them utterly useless
22:06:58 <hyc> everything on the internet uses AES in TLS etc
22:12:19 <artefact> i've seen camelia used in the wild a few times in TLS