09:09:53 <peter22222> hello together. I have a question. I tried to run monerod from cli, and after 99% of syncing (took ages) I got this error message:
09:10:03 <peter22222> 2020-10-14 05:33:14.797 [P2P8] ERROR default src/common/threadpool.cpp:170 Exception in threadpool job: mprotect faile
09:19:48 <selsta> peter22222: does the error persist after restarting?
09:19:55 <selsta> also are you using v0.17.0.1?
09:20:08 <peter22222> selsta yes it does
09:20:15 <peter22222> yes i use 0.17.0.1
09:23:26 <peter22222> INFO	logging	contrib/epee/src/mlog.cpp:273	New log categories: *:WARNING,net:FATAL,net.http:FATAL,net.ssl:FATAL,net.p2p:FATAL,net.cn:FATAL,daemon.rpc:FATAL,global:INFO,verify:FATAL,serialization:FATAL,daemon.rpc.payment:ERROR,stacktrace:INFO,logging:INFO,msgwriter:INF
09:24:40 <peter22222> I run it as a systemd service
09:24:46 <peter22222> worked fine till now
09:37:49 <peter22222> i just run it manually... seem to work now though very slow. thank you
09:38:02 <selsta> maybe try restarting your system or so
09:38:35 <selsta> the last percent is slow due to missing checkpoints
09:40:13 <peter22222> 2020-10-14 09:37:20.251	[P2P7]	INFO	global	src/cryptonote_protocol/cryptonote_protocol_handler.inl:1593	Synced 2192924/2208216 (99%, 15292 left, 0% of total synced, estimated 3.8 days left)
09:41:06 <peter22222> 3.8 days haha wtf... monero teaches me patience, lol. thanks for the help, selsta :-)
09:52:48 <selsta> peter22222: is this with HDD or SSD?
09:53:02 <peter22222> HDD
09:53:07 <selsta> It should take way less time with SSD.
09:53:42 <peter22222> selsta yeah I ve been reading about that too.. i ve been running it for a week already...lol
09:54:32 <selsta> peter22222: update to v0.17.1.0 which will be released today, it contains fresh checkpoints so it should speed things up
09:54:59 <peter22222> great advice selsta! thank you!
09:55:04 <selsta> peter22222: hmm with SSD it possible to completely sync up in under 4 hours
09:56:07 <peter22222> I heard that too.. but unfortunately I dont have an SSD at the moment, so i tried it with HDD...
11:12:27 <flipchan> Hey, how does monero handle deadnodes? lets say i use my node and it stores the other nodes ip and I start it again and 30% is not working
11:12:38 <flipchan> how does it handle dead nodes?
11:13:08 <dEBRUYNE> The peerlist is refreshed on every startup if I recall correctly
11:18:07 <moneromooo> It just tries others. If all the nodes you know about are not reachable, it won't connect. But it's likely at least one seed node will be available.
11:29:46 <flipchan> monoremooo: thanks
12:39:29 <TheCharlatan> binaryFate there is a merge script for the gitian.sigs repo that first checks the sigs and then makes a signed commit.
12:41:47 <binaryFate> ok I'll use next time, or better I leave that to you but it's much easier for me to check all hashes and sigs if the PRs are merged and not just open
12:42:07 <binaryFate> I'm releasing binaries now so I just went forward
12:58:42 <TheCharlatan> no worries, it's easy to use: verify-merge.py --merge --pull_id 79 --version 0.17.1.0 for example. It also checks the hashes and signatures again.
13:45:25 <pinheadmz> hey friends. curious what framework you use for the GUI ... is it Qt? Electron?
13:45:49 <asy> pinheadmz: the gui on getmonero.org is Qt
13:45:53 <pinheadmz> ty
13:59:08 <binaryFate> v0.17.1.0 is out on getmonero.org
15:14:39 <hyc> yay for no more tx_meta messages
15:14:42 <hyc> 2020-10-14 15:14:05.906 E   failed to find tx meta: <228d6e9a3de532c4711298f633d22632b64df0e3fffedcee10dd49204db840b5> (will only print once)
15:35:23 <selsta> cli release notes: https://paste.debian.net/hidden/39186ba9/
15:35:26 <selsta> gui release notes: https://paste.debian.net/hidden/4217ca44/
15:35:40 <selsta> luigi1111w: please upload them to github and set as latest release
15:36:13 <TheCharlatan> I'm amazed at the speed these releases have been baked recently, kudos selsta, binaryFate and luigi1111w!
15:38:14 <selsta> gitian is quite handy for CLI bins :P
15:55:57 <selsta> .merge+ 6862 6875 6881 6882 6886 6891
15:55:57 <xmr-pr> Added
15:56:12 <selsta> ^ these have been merged to branch
16:23:00 <binaryFate> Can anyone confirm the auto-update triggers for 0.17.1?
16:28:58 <selsta> binaryFate: I think fluffypony has to update DNS
16:29:04 <fluffypony> yeah busy with it now
16:29:08 <selsta> oki
16:29:21 <fluffypony> and it'll take a while to update for everyone
16:30:42 <luigi1111w> release notes added, will add binaries soon
16:31:11 <selsta> nice
16:32:37 <fluffypony> updates.moneropulse.co. 1   IN  TXT "monero-gui:install-win-x64:0.17.1.0:be3b1f07ba86a0d46c27f670b27d936baa5c4e7b68f3dc37349b8f91b073dc6a"
16:32:41 <fluffypony> does that look correct?
16:33:52 <selsta> yes
16:33:57 <fluffypony> ok cool
16:40:21 <fluffypony> ok records all updated
16:40:29 <fluffypony> plz check and let me know if you spot anything weird
16:41:42 <moneromooo> 2020-10-14 16:41:15.507W No DNSSEC for updates.moneropulse.co
16:41:53 <moneromooo> Longstanding. The other three do.
16:42:25 <moneromooo> And none of the seeds.moneroseeds.* do either.
16:49:19 <selsta> binaryFate: announce email sent twice, was that intended?
16:49:54 <selsta> auto updater confirmed working
16:49:57 <binaryFate> lists were down, we thought previous message wasn't sent nor in queue, but it did went out apparently
16:50:08 <binaryFate> lists are back, and message twice sorry
16:50:16 <selsta> np
17:35:11 <fluffypony> moneromooo: .co dropped DNSSEC support
17:35:17 <fluffypony> moneroseeds I'll have to investigate
17:39:08 <fluffypony> we have new moneropulse domains to add
17:39:47 <fluffypony> .fr .de .no .ch
17:39:54 <fluffypony> need to check DNSSEC on all of them
17:40:02 <fluffypony> and then we can decommission .co
17:43:15 <selsta> for seed node operators: reminder to update to v0.17 (ideally v0.17.1.0)
17:52:16 <moneromooo> None of those have it atm.
18:31:08 -xmr-pr- dariensc opened issue #6899: XMR wallet GUI not working anymore... Please HELP!!!
18:31:08 -xmr-pr- > https://github.com/monero-project/monero/issues/6899
18:51:26 <hyc> a downside of mining on my public node - random attackers, tripping fail2ban, eats enough CPU to impact my hashrate
19:11:32 <pinheadmz> "sweep unmixable outputs" -> is this required for all UTXOs created before the last hard fork?
19:13:23 <dEBRUYNE> pinheadmz: No, it is only relevant for certain outputs created before January 2017
19:15:53 <pinheadmz> dEBRUYNE ah ok thanks, im consolidating a bunch of old wallets
19:15:56 <pinheadmz> is this related? https://www.getmonero.org/2017/05/17/disclosure-of-a-major-bug-in-cryptonote-based-currencies.html
19:16:31 <dEBRUYNE> No
19:16:43 <dEBRUYNE> Before RingCT was activated, output values were in the clear
19:17:02 <dEBRUYNE> In order to be able to create 'rings', outputs were split according to the power of 10
19:17:22 <dEBRUYNE> So 12.123 XMR would be outputs of 10, 2, 0.1, 0.02, 0.003
19:17:32 <dEBRUYNE> An 'unmixable' output is essentially an output for which no ring can be created
19:17:41 <dEBRUYNE> e.g. an output with value 0.0000024123
19:17:43 <dEBRUYNE> Or some weird value
19:18:04 <dEBRUYNE> Anyway, not really on-topic for -dev, so let's continue in #monero
19:27:05 <Alex_LocalMonero> @dEBRUYNE, moneromooo, would it be unreasonable for me to request that in the future whenever you commit RPC API changes into master you add some sort of specified text to the commit message to allow developers to easily pick out the RPC API changes from the rest of the commits?
19:28:05 <Alex_LocalMonero> Such as "[RPC API CHANGE] Bla bla bla message"
19:30:16 <moneromooo> Yes, since we often forget to bump the rpc version when it should be bumped.
19:30:44 <moneromooo> Well, I do anyway. And I added the thing :/
19:31:58 <binaryFate> btw map is buggy but I think numbers of upgraded/not-upgraded nodes are correct https://community.xmr.to/network
19:32:18 <binaryFate> coverage is not perfect on all nodes, but gives an idea of proportion
19:33:27 <hyc> seems like if you care about RPC changes, you just have to check the commit logs for the RPC source files
19:33:36 <moneromooo> I was just typing that.
19:34:33 <moneromooo> They're supposed to be backward compatible anyway (unless the major version gets bumped).
19:42:44 <Alex_LocalMonero> Are there any active public testnet nodes running v0.17.1.0 to connect to? Our testnet daemon is having trouble finding peers.
19:50:17 <dEBRUYNE> What kind of information is leaked to the node if one imports key images btw?
19:50:37 <moneromooo> Which key images are yours.
19:50:58 <moneromooo> So your balance.
19:51:27 <moneromooo> Wait, not balance.
19:51:38 <moneromooo> That'd only be the case pre-rct.
19:52:14 <moneromooo> I suppose one could add random values in the main subgroup. And random key images off the chain. But really... use your own dameon.
19:52:55 <dEBRUYNE> Thanks, merely asking because someone questioned it on Reddit
19:57:47 <binaryFate> Alex_LocalMonero: public nodes at https://community.xmr.to/nodes.html are running 0.17.1 including testnet
20:57:32 <xiphon> regarding the asshole nodes: at the first glance it looks to me like an attempt to trace monero txes' origin (i.e. link a tx to ip)
20:58:04 <xiphon> they don't propogate dandelion txes so, mekes it fallback to fluff
20:59:03 <xiphon> and given that usually there are more than 1 "asshole" node connected, they then can safely link a tx to your ip
21:01:00 <xiphon> s/so, mekes/, forcing your node to fallback to "fluff"
21:05:52 <xiphon> given that they report your height
21:06:31 <xiphon> the worst case scenario is you running fully synced node
21:06:40 <lza_menace> what a bunch of dicks
21:07:29 <xiphon> so just looking at the peers' heights you can't distinguish "assholes" from the good ones
21:08:02 <xiphon> i'm thinking about increasing the default out_peers limit (it is 8 now)
21:09:33 <xiphon> at least is the easiest thing we can do to significantly reduce their chances
21:14:17 <xiphon> pfff.. or just force tor and i2p integration. But syncing over tor is forbidden in the code at the moment
21:24:33 <selsta> Is syncing over Tor required to avoid tracing tx to IP?
21:28:29 <xiphon> ^ nope
21:31:31 <selsta> I2P / Tor seed nodes are a good start I guess
21:48:26 <moneromooo> The assholes I'm talking about always claim your height when you connect to them. They also poitn to each other in their peer lists.
21:48:36 <moneromooo> They date from way before dandelion fwiw.
22:18:05 <selsta> Snipa: could you merge 6863 6867 to fix our GUI CI? :)
22:19:04 <Snipa> Sure, gimme a few.
22:23:47 <Snipa> .merges
22:23:47 -xmr-pr- 6862 6863 6867 6875 6881 6882 6886 6891
22:23:53 <Snipa> Ooof, okay then. :D
22:24:35 <selsta> yea they can wait :P 6863 6867 are important
22:25:03 <Snipa> Done.
22:25:41 <selsta> nice