00:06:28 <ghost_matrix[m]> Im sure this question has been asked but whats going on with the whole Chainalysis and Integra FEC shenanigans?
00:06:28 <ghost_matrix[m]> Is this seriously going to effect Moneros privacy?
00:06:28 <ghost_matrix[m]> Kind of concerning to say the least.
00:09:59 <selsta> What are you concerned about specifically?
00:14:39 <yanmaani> ghost_matrix[m]: have they provided any evidence yet?
00:15:47 <yanmaani> because if it's just a press release, odds are it's a total nothingburger
00:16:32 <selsta> They don’t have any tracing capabilities yet, IRS paid them to develop something.
00:24:15 <yanmaani> Should write up a FAQ entry. "Is it true that [entity] can trace Monero?"
00:26:56 <as2333> "should you believe the so called news?"
01:08:26 <ghost_matrix[m]> Yeah i guess no evidence has been provided as of yet. Just amazing how much money has been channelled to break Moneros privacy.
01:09:08 <ghost_matrix[m]> Usual suspects with the usual excuses lol
01:09:36 <ghost_matrix[m]> <as2333 ""should you believe the so calle"> No
01:09:57 <ghost_matrix[m]> <yanmaani "because if it's just a press rel"> I damn hope so
01:17:53 <as2333> ghost_matrix[m], ;)
01:52:45 <monerouser1144> Hi all, I was experimenting with adding a password to the 25 word seed, using cli and luigi1111's webpage (which btw has a mismatching sha256 ckecksum).Since it has been a few years since those pages were written, is it still a good idea to add a password to the raw seed? TIA.
06:13:52 <luigi1111w> hmm I should fix the checksum
08:25:56 <endor00[m]> Speaking of tracing, I noticed that there are still many pools that post all their payout transactions and amounts in their 'payments' page. That's a goldmine of information for heuristic tracing
08:26:44 <sech1> 3 top pools don't do that
08:26:50 <endor00[m]> We need to reach out to pool ops and/or the ui designers and tell them to remove all references to tx amount and tx hashes entirely
08:27:20 <endor00[m]> Top3 don't, but a bunch of the medium-sized ones do
08:29:21 <endor00[m]> It's still a large source of info
08:29:52 <endor00[m]> And the caveat is that it's often not just a ui fix, but an api fix too
08:50:06 <xmrmatterbridge> <rbrunner7> Just realized that when I am solo-mining in my daemon I have almost exactly 1 millionth of the total net hashes. Easy to calculate my chances for a block!
09:29:17 <Mochi101> endor00[m], Monero can't expect users to keep things private.
09:29:56 <Mochi101> It's not a viable strategy.
09:30:21 <endor00[m]> That's not an excuse to be sloppy about it
09:30:40 <endor00[m]> Besides, we're not talking about all users here, just a handful of pool ops
09:31:00 <algo_max[m]> <endor00[m] "Speaking of tracing, I noticed t"> Excuse my noobness, but could you explain what someone could do with that information?
09:32:16 <endor00[m]> It provides useful information to figure out who those outputs belong to
09:33:01 <endor00[m]> Plus, in some cases there are payouts with a single payee - in which case you know exactly how much is contained in that specific single tx output
09:34:04 <endor00[m]> So if you receive a tx for that exact amount (including tx fee) and that output shows up as one of the tx inputs, you can be almost certain that that's a real spend
09:34:24 <endor00[m]> And therefore you can exclude that output as a decoy from other transactions
09:34:50 <Mochi101> Grains of sand in a desert endor00[m]
09:34:55 <sech1> I doubt miner payouts are even 1% of current Monero transaction flow
09:35:41 <Mochi101> How is something like this, a site that doesn't keep track of its users, supposed to convey confidently to the user that the site has paid out then? https://monero.win/#/game/7766e9dafcad333f
09:35:46 <Mochi101> endor00[m], ^^^
09:35:57 <endor00[m]> Mochi101: still enough to deanonymize some people
09:35:59 <Mochi101> Without giving up that information.
09:36:52 <algo_max[m]> If people used sub-addresses (or separate wallets) for mining they should be fine, shouldn't they?
09:37:51 <endor00[m]> At least there are two outputs in that tx, already 50-50 chance
09:38:40 <endor00[m]> algo_max: addresses/subaddresses don't matter in this case - if I see an output in a transaction that I know is connected to you, I know it's yours
09:43:57 <endor00[m]> still, it provides some free info about the potential origin of a transaction and works in the exact opposite direction of ring signatures - the harder we can make their life, the better it is
09:44:47 <endor00[m]> and this one is a relatively easy fix that would remove a lot of useful metadata for tracing companies
09:45:37 <endor00[m]> look at it from the perspective of the swiss cheese model
09:52:32 <Mochi101> Maybe contact the offending pools endor00[m]
09:53:16 <algo_max[m]> Shouldn't that information be considered public anyway? I mean I wouldn't trust a mining pool, exchange, dark market seller or amazon. They could all be run by malicious operators who sell that info, could get hacked or whatever...? The protocol should still be safe.
09:57:12 <endor00[m]> Individual miners can always check their own payouts individually
09:58:16 <endor00[m]> And as an outside observer you have no way to prove that the info listed on the payouts page is truthful anyway, since you're implicitly 'trusting' the info contained on that page
10:01:07 <endor00[m]> So it does nothing from the point of view of spotting a malicious pool op
11:28:59 <Inge-> PSA: synching 0.17.0.1 from scratch on fairly optimal hardware = 5 hours and change.
11:43:28 <Mochi101> That's not bad Inge-
11:43:54 <Mochi101> Way better than Ethereum's >forever
11:54:13 <raecarruth> https://home.treasury.gov/system/files/126/ofac_ransomware_advisory_10012020_1.pdf
11:54:27 <Inge-> I think I could sync ethereum with this setup. But I might need to add some ssd storage
11:57:19 <Inge-> still wondering if monero synch time couldn't be reduced. Not sure what the limitation is. moneromooo? I'm running on a 3970x so I have plenty of cpu cores to go around. Also running on 3 sriped PCIe gen4 nvme drives ...
12:04:11 <Mochi101> Nice setup Inge-
12:05:53 <Inge-> Bare minimum for an ethereum node :P
12:06:26 <Mochi101> hehehe
12:06:52 <Mochi101> But that doubles sometimes tomorrow hey.
12:07:34 <Inge-> at least I can run a few FF tabs on it
12:08:01 <Mochi101> risky business
12:29:20 <charolastra> expensive setup. exit scammed lately? :p
12:29:47 <artefact> what setting did you use for db syncing? afaik that's the main source of slowness. and having to verify hashes for the last few percent
12:30:30 <artefact> if you have really good bandwidth it might be faster just to download the whole lmdb from somewhere
12:30:51 <selsta> network is usually not the bottleneck
12:31:30 <selsta> Inge-: what OS are you using?
12:31:57 <moneromooo> More batching might help a fair bit. Like, batching all BP in a 20 block span.
12:32:48 <moneromooo> Possibly also verifying a random 1/N PoW hashes for small N.
12:33:28 <selsta> I also still like the idea of using supercop ASM ECC library for initial sync
12:33:29 <Inge-> selsta: Linux
12:33:41 <selsta> Inge-: how long does wallet scan from block 0 take with your setup?
12:33:56 <Inge-> Good q. I can test that.
12:34:18 <Inge-> hm. I guess you want the monero node locally on this setup then, for that test.
12:35:41 <moneromooo> The wallet could do with a block queue too. At the moment it's simple get next blocks and parse the ones before. No queue.
12:36:09 <moneromooo> Also, rw locks for the daemon.
12:45:42 * algo_max[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/RkJdfiRFNqlVDIvSnjOaWVxA/message.txt >
12:51:17 <selsta> algo_max[m]: do you have enough storage space left?
12:52:58 <algo_max[m]> yes, 490GB of 1TB is free
12:55:43 <selsta> can you post the output of starus?
12:55:47 <selsta> status
13:29:17 <DeanGuss> [P2P5]	ERROR	default	src/common/threadpool.cpp:170	Exception in threadpool job: mprotect failed
13:29:33 <DeanGuss> ^last thing I have in my log from hours ago... what does that mean
13:31:11 <moneromooo> See github, there's a report and discussion from a couple months ago with this, can't recall exact details.
13:31:33 <moneromooo> But it should be harmless since the associated hang got fixed.
13:34:22 <DeanGuss> Well my previous log entry is:
13:34:27 <DeanGuss> [P2P5]	INFO	global	src/cryptonote_protocol/cryptonote_protocol_handler.inl:1593	Synced 2182124/2198840 (99%, 16716 left, 93% of total synced, estimated 8.1 hours left)
13:34:32 <DeanGuss> so it appears to have stopped syncing
13:34:51 <DeanGuss> on 0.17.0
13:34:54 <moneromooo> You might not have that patch then. Check if you do, and let me know if you do.
13:35:05 <moneromooo> That should have it...
13:36:14 <DeanGuss> well let me try restarting monerod then and see what it says
13:36:29 <DeanGuss> unless I should do something else to try to debug
13:36:45 <algo_max[m]> selsta: status says: Height: 1674321/1806795 (92.7%) on mainnet, not mining, net hash 563.13 MH/s, v7, 8(out)+1(in) connections, uptime 1d 19h 45m 24s
13:36:51 <moneromooo> gdb into the process, thread apply all bt
13:49:31 <DeanGuss> [Thread debugging using libthread_db enabled]
13:49:31 <DeanGuss> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
13:49:31 <DeanGuss> futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x5598915deba8) at ../sysdeps/nptl/futex-internal.h:183
13:49:31 <DeanGuss> 183	../sysdeps/nptl/futex-internal.h: No such file or directory.
13:49:50 <DeanGuss> is what gdb attach <pid> spit out
13:50:32 <DeanGuss> I'm on ubuntu 20.04
13:52:00 <DeanGuss> ^moneromooo
13:52:17 <DeanGuss> If that means anything to you
13:52:43 <moneromooo> That means you did not run thread apply all bt (or did not paste its output).
13:52:56 <moneromooo> Paste it on some site like paste.debian.net, not here.
13:53:14 <moneromooo> That particular thread's sleeping, seems fine.
13:53:25 <moneromooo> Well, unless another is stuck on the same mutex.
14:39:37 <DeanGuss> https://paste.debian.net/hidden/5f90ec2d/ <- moneromooo thanks for the guidance and taking a look! I'm #clueless
14:45:45 <moneromooo> Looks like it wasn't the same thing after all. I'll try to repro.
14:49:41 <moneromooo> And it looks like this exception is leaking through librandomx.
14:49:47 <moneromooo> We should still not hang though.
16:59:45 <Inge-> sweep_single can't be split into multiple recipients/amounts ?
17:05:05 <Inge-> hm. I have a couple of times gotten a weird error as part of a transfer (using a remote node): [1601658225] libunbound[12148:0] error: can't bind socket: Permission denied. for 0.0.0.0
17:05:34 <moneromooo> It really should not bind to 0.0.0.0...
17:07:43 <Inge-> I think I've seen this twice in monero-wallet-cli now
17:07:52 <Inge-> maybe on different machines
17:10:38 <Inge-> I've also had some cases of an outgoing transfer go from pending to failed - but then tried to re-do it and get "double spend" error - but then it was suddenly sent
17:22:42 <monerouser1144> @luigi1111 Hi, it seems that the sha256 hash of the current site.zip (at Github and at https://xmr.llcoins.net/) isn't valid anymore.
17:23:38 <luigi1111w> thanks for the report
17:25:01 <luigi1111w> monerouser1144 it matches for me
17:27:40 <monerouser1144> Hi all, I would like to ask if adding a passphrase to a raw seed (for a paper wallet) is a good idea, or if the calculation method (CN Add, CN Xor or Keccak) is still subject to change?.
17:28:10 <moneromooo> If it changes, backward would be maintained.
17:30:49 <moneromooo> And the calc method is point addition (modulo). So trivial to reimplement anyway.
17:33:48 <monerouser1144> @luigi1111 yes, now it matches for me too https://pastebin.com/TfLhPzP5 (I had a mismatch last night, maybe it was my mistake)
17:34:36 <luigi1111w> those methods will stay up indefinitely. I think the regular wallet supports the CN add (or offset)
17:35:44 <moneromooo> Oh, I assumed the question was about the wallet. I did not realize there were other ways to mangle a seed.
17:37:28 <monerouser1144> @luigi1111 the sha256 hash displayed at the bottom of your webpage, when I unzip and run it locally is different (984ad27b3759b09532dc95ad09d59fd8918cfd0bfc51f53e4dd6371eb321b6f7)
17:38:00 <luigi1111w> yeah I should just blank that one, but extra commits
17:38:01 <luigi1111w> blech
18:02:45 <bigslim[m]> can anyone check if msys update server is not working on their end
18:02:53 <bigslim[m]> https://repo.msys2.org/distrib/x86_64/msys2-x86_64-20200903.exe
18:02:59 <bigslim[m]> pacman not updating, getting timeout errors
18:03:50 <selsta> seems to time out here too
18:03:59 <bigslim[m]> dammit
18:04:02 <selsta> (the file you posted)
18:04:10 <bigslim[m]> yea
18:04:20 <bigslim[m]> pacman not working to update either
18:04:44 <bigslim[m]> looks like they have had some server hosting issues this year https://github.com/msys2/MSYS2-packages/issues/1884
18:05:45 <bigslim[m]> and of course have not updated windows build server since like January so cant build current binaries from master
18:41:18 <monerouser1144> Of the various methods for generating seeds (see https://coldbit.com/what-types-of-mnemonic-seeds-are-used-in-bitcoin/) I understand that the "official" sw (Monero cli & gui and MyMonero) use the "new Electrum" format, adapted for Monero?
18:48:19 <Inge-> selsta: How should I do the rescan to test it? recreate the wallet from seed?
18:49:07 <selsta> Inge-: restore from seed, restore height 1
18:49:19 <Inge-> ack
18:56:09 <Inge-> selsta: do you have any comparative numbers=
18:56:11 <Inge-> ?
18:56:41 <selsta> my 2014 laptop took 14 mins or so
19:00:41 <Inge-> 8 minutes flat
19:00:58 <Inge-> node is running in a docker container, not sure if that makes much of a difference
19:01:33 <ndorf> it shouldn't
19:01:36 <moneromooo> Shouldn't, unless that makes it swap substantially more.
19:01:42 <Inge-> nah no swapping
19:01:55 <Inge-> 10-15% cpu, about ~35MB/s disk activity
19:01:57 <moneromooo> Same kernel, so same amount of copies I think.
19:02:41 * ndorf guesses that Inge-'s CPU has 8 threads
19:02:46 <Inge-> try 64
19:03:09 <ndorf> really? and 10-15% CPU?
19:03:18 <moneromooo> (Windows)
19:03:19 * moneromooo runs
19:03:27 <ndorf> ah.
19:03:29 * ndorf recuses himself
19:03:36 * Inge- stabs moneromoo
19:03:37 <Inge-> Linux
19:04:02 <Inge-> when not scanning I'm seing 2-3% cpu (but I am running a VM on it that is mostly idling at the moment)
19:04:19 <ndorf> ISTR for me it fully pegged exactly one thread, so 12.5% of my 8 thread cpu
19:07:11 <Inge-> I see the scan peaks around 1000% cpu so I guess up to 10 threads...
19:09:18 <ndorf> ah, yeah. it depends on which tool you are using to measure it
19:09:41 <ndorf> some default to 0-100% and others 0-($nproc * 100%)
19:14:54 <Inge-> took another run - 7m52s so pretty close
19:48:18 <monerouser1144> Question about creating an offline wallet using the webpages kindly provided by luigi1111 or moneromoo: would you trust the PRNG of Chromium (Ubuntu/Mint/Debian) with Linux kernel v5.x, or would you prefer to create the address with monero-wallet-cli ?
19:48:39 <luigi1111w> pretty sure they are the same source
20:07:08 <azizLIGHT> how big is the blockchain? whats a good size for my vm's hdd
20:08:08 <lza_menace> ~90 GB I think
20:08:21 <Inge-> azizLIGHT: depends on if you are fine runnning a pruned node vs full node. full is 90GB now...
20:08:30 <Inge-> pruned is what, 30-35GB?
20:08:57 <lza_menace> iirc, yes
20:09:47 <monerouser1144> Pruned takes 25GB currently on my VPS.
20:11:55 <monerouser1144> I started with a clean system and ran "monerod --prune-blockchain --detach" (it took several days to finsh, I think it downloaded 60+GB but only needs ~25GB currently)
20:13:08 <monerouser1144> I'm still unclear if I still need to invoke monerod with --prune-blockchain after the initial sync, but I add it just to be sure.
20:30:24 <azizLIGHT> cant we rename accounts on the gui
20:34:41 <selsta> to?
20:48:44 <azizLIGHT> something else than what was originally put
20:49:05 <azizLIGHT> it doesnt seem like you can edit the name
20:49:12 <azizLIGHT> maybe i cant find it
20:52:16 <azizLIGHT> another question: if my blockchain is stored inside a cpu-core limited vm, but i want to do cpu mining with ryzen with the host os, would sharing the blockchain files from the vm to the host over samba be the best way to do this?
20:52:33 <azizLIGHT> any other ideas appreciated
20:57:34 <artefact> cpu mining on your own?
21:08:32 <dixie__flatline[> <selsta "I think so :/ We have taken down"> Holy shit
21:28:51 <Inge-> azizLIGHT: you can run a pool. only the pool node needs the blockchain