00:14:01 <Hail_Spacecake> nioc:yeah, I want to make sure I understand the implications of using a remote node
00:14:10 <Hail_Spacecake> and I dont wnat to run a local one becuase I don't wnat to download the entire blockchain
00:14:33 <Hail_Spacecake> I was doing the local thing at one point a long time ago but I'd have to remind myself of how that was set up and also redownload the blockchain, which I don't want to do
00:14:45 <Hail_Spacecake> I don't think I have enough space for it on this machine nayway, I deleted it a while ago to free up space
00:15:49 <nioc> I guess you know that you can sync the blockchain in pruned mode which will be about 1/3 the size
00:16:06 <nioc> still 25GB+
04:36:51 <erikd> is there a way to disable the "I locked your Monero wallet to protect you while you were away" message? or increase the timeout?
04:40:20 <Bill48105> hey erikd docs show  set inactivity-lock-timeout 600
04:40:27 <Bill48105> 0 disables entirely
05:07:06 <erikd> Bill48105: is that not availabel as a command line option?
05:07:34 <erikd> and is that in the daemon or in the cli wallet?
05:08:39 <erikd> https://monero.stackexchange.com/questions/11737/how-can-i-slow-down-or-disable-cli-wallets-automatic-locking-due-to-inactivity/11738#11738
05:08:58 <Mochi101> erikd, cli wallet
05:09:12 <erikd> thanks Mochi101 amd Bill48105
05:09:38 <Mochi101> just have to set it once and it remembers
05:09:57 <Mochi101> per wallet
05:13:35 <Bill48105> there's not much need to lock daemon eh
05:14:10 <Bill48105> glad you got it sorted
05:17:32 <Mochi101> Always best to lock up your demons Bill48105
05:33:47 <Bill48105> i release my demons regularly but last i checked monero daemon is just the block chain and has no access to your wallet. that's why you need to run cli or rpc to actually use your wallet
05:39:24 <louipc> yea
05:43:30 <erikd> i chose not to disable it but to increase the timeout to 600 seconds
05:51:35 <Bill48105> nice plan
05:52:05 <Bill48105> better to have that safety net with minimal inconvenience
06:39:06 <bigslim[m]> good work on the fork
06:41:17 <rottensox> <3 bigslim[m].
06:42:20 <bigslim[m]> went smooth it looks like
06:42:44 <bigslim[m]> you guys find any issues?
07:36:52 <xmrmatterbridge> <vie> monero network hash so heigh now
09:09:12 <xie> Hi, I have a question about "get_transfer_by_txid". The same transfer was shown twice in filed "transfers", the difference is filed "type", one is "in" and another is "pool"
09:09:43 <xie> Is that normal?
09:10:46 <xie> I can post complete information if you need
09:31:47 <sech1> xie did you look at how wallet_rpc_server.cpp fills in "transfers"?
09:33:15 <sech1> It can find the same txid multiple times. The ones with "pool" type are unconfirmed pool payments.
09:33:53 <sech1> you need to check unlock_time to see when it will be confirmed
09:35:23 <xie> The transaction has been confirmed
09:35:50 <xie> "confirmations": 39
09:36:58 <sech1> that's strange, "pool" means tx mempool as far as I can see in the code, but I'm not very familiar with this part of the code
09:37:14 <sech1> so it's unconfirmed transaction in mempool
09:37:45 <xie> "id": "0",  "jsonrpc": "2.0",  "result": {    "transfer": {      "address": "85nC8EEXBgLGKbc73fDZj1GPckq4VVCzXYX9RCtsYWKBco8jxibdZLxUYYFN5bJBkFdzNc4e8JYLSQRhg1oMkBc4MByzrW6",      "amount": 12340000,      "confirmations": 19,      "double_spend_seen": false,      "fee": 25030000,      "height": 1979842,      "locked": false,      "note": "",
09:37:45 <xie> "payment_id": "0000000000000000",      "subaddr_index": {        "major": 0,        "minor": 60007      },      "subaddr_indices": [{        "major": 0,        "minor": 60007      }],      "suggested_confirmations_threshold": 1,      "timestamp": 1575273569,      "txid": "af67e83d8d6cdae2f93d30de85ce7f3b458c1a34ff43be4cda027361961011ec",
09:37:45 <xie> "type": "in",      "unlock_time": 0    },    "transfers": [{      "address": "85nC8EEXBgLGKbc73fDZj1GPckq4VVCzXYX9RCtsYWKBco8jxibdZLxUYYFN5bJBkFdzNc4e8JYLSQRhg1oMkBc4MByzrW6",      "amount": 12340000,      "confirmations": 19,      "double_spend_seen": false,      "fee": 25030000,      "height": 1979842,      "locked": false,      "note": "",
09:37:46 <xie> "payment_id": "0000000000000000",      "subaddr_index": {        "major": 0,        "minor": 60007      },      "subaddr_indices": [{        "major": 0,        "minor": 60007      }],      "suggested_confirmations_threshold": 1,      "timestamp": 1575273569,      "txid": "af67e83d8d6cdae2f93d30de85ce7f3b458c1a34ff43be4cda027361961011ec",
09:37:47 <xie> "type": "in",      "unlock_time": 0    },{      "address": "85nC8EEXBgLGKbc73fDZj1GPckq4VVCzXYX9RCtsYWKBco8jxibdZLxUYYFN5bJBkFdzNc4e8JYLSQRhg1oMkBc4MByzrW6",      "amount": 12340000,      "confirmations": 0,      "double_spend_seen": false,      "fee": 25030000,      "height": 0,      "locked": true,      "note": "",      "payment_id":
09:37:47 <xie> "0000000000000000",      "subaddr_index": {        "major": 0,        "minor": 60007      },      "subaddr_indices": [{        "major": 0,        "minor": 60007      }],      "suggested_confirmations_threshold": 1,      "timestamp": 1575273548,      "txid": "af67e83d8d6cdae2f93d30de85ce7f3b458c1a34ff43be4cda027361961011ec",      "type": "pool",
09:37:48 <xie> "unlock_time": 0    }]  }}b
09:37:57 <sech1> just don't ask for mempool in your request (set req.pool = false)
09:38:40 <xie> will try your suggestion
09:40:14 <sech1> the one you got with type=pool has confirmations=0 which is normal for tx mempool
09:40:27 <sech1> not sure why it ended up in the response if it has already been mined
09:43:50 <sech1> it has something to do with how wallet refreshes, need someone more knowledgeable to clarify it
09:45:18 <xie> The balance has beed updated accutally
09:45:20 <xie> Maybe this is a display issue
10:07:04 <caveman22> !Horla Thomas J. Stanley - Millionaire Women Next Door (epub).epub
10:07:04 <tippero> Invalid command, try !help
12:20:44 <moneromooo> xie: supposedly fixed in cbec8eb10bd0f0d82b6524df2b4af714b1b3599a, are you running an older version ?
12:39:55 <xie> https://github.com/monero-project/monero/releases/tag/v0.15.0.0
12:40:00 <xie> I am using this one
12:40:49 <needmonero90> Ah, 0.1 is out
12:40:54 <gingeropolous> there is a newer tag xie https://github.com/monero-project/monero/releases/tag/v0.15.0.1
12:41:32 <needmonero90> Was trying to find it on mobile, ginger beat me :(
12:41:49 <dEBRUYNE> I guess the issue is that it hasn't been marked as latest release yet
12:41:51 <xie> So this is fixed in v0.15.0.1?
12:43:05 <xie> I did notice v0.15.0.1, but thought it is not a stable version
12:45:19 <selsta> xie: It is a stable version, the Github release page just has to get updated.
12:46:37 <moneromooo> It is fixed in 0.15.0.1.
12:47:16 <xie> Cool, just want to confirm. Glad to know it has been fixed in the latest release
12:47:20 <xie> thank you guys
13:09:11 <xie> I found some transactions still contain paymentId according to get_transfer_by_tx
13:09:24 <xie> get_transfer_by_txId
13:09:59 <xie> But I have set paymentId as ""
13:10:23 <xie> It's strange, most of new transactions is good
13:49:16 <needmonero90> You can safely ignore the payment IDs returned, an encrypted payment ID is attached to every tx so it doesn't stand out when you actually use one.
13:49:59 <xie> Ok, will ignore it
15:39:25 <mfed3[m]> Hey guys anyone have a good usb / live linux distro that is configured to basically auto mine as soon as it boots up
15:39:25 <mfed3[m]> My use case is basically put the configuration on the distro and then when I boot it from usb media it will just start to mine with those preconfigured settings
15:39:25 <mfed3[m]> headless, does not need any gui...is there a such thing as like a xmrig preconfigured distro?
15:42:35 <asymptotically> mfed3[m]: you could create something like that with buildroot. or start off with someething else like alpine linux
15:43:19 <mfed3[m]> So nothing already preconfigured, but this would be me essentially installing linux to a usb drive marked as bootable
15:43:25 <mfed3[m]> Then only installing a minimal package set
15:44:29 <asymptotically> i think i remember someone sharing a project like this on reddit a few months ago but i'm not sure if they ever updated it to support RandomX
15:44:40 <mfed3[m]> It is one possible solution, I was hoping someone maybe knew of an appliance distribution built for this purpose
15:44:54 <asymptotically> DIY isn't too hard though. a few people do that in #monero-pools and then pxe boot the image on all of their miners
15:52:28 <`Didrole> Add xmrig to buildroot and voila.
15:54:52 <asymptotically> libuv, hwloc and openssl are already packaged for buildroot so its barely any work ^^
16:59:30 <xmrmatterbridge> <learninandlurkin> I believe the project you're thinking of was called Pickaxe OS,  and I don't think they upgraded to RandomX yet
17:04:38 <gingeropolous> mfed3[m], its honestly best to figure it out yourself. anything premade by someone prolly won't get maintained and they prolly incorporated some dev fee or something
17:22:46 <hv-bridge> <\​x> needmo: cope
17:23:41 <mfed3[m]> <gingeropolous "mfed3, its honestly best to figu"> Probably right, I would not mind if I needed to compile any packages or configure it, but I guessed this would be the right place to ask if it existed or not
17:24:08 <mfed3[m]> Before I waste my time reinventing the wheel haha
18:20:29 <gingeropolous> is selena here? is that the person that did monero primo? Would be cool to carry that over to general software / licenses etc.
18:21:06 <gingeropolous> for some reason i was reminiscing of the 90s, getting key crackers for adobe software etc... im sure stuff like that exists now as well
18:21:14 <gingeropolous> but you can't fake PoW
18:21:37 <hyc> you want to use PoW as a software key?
18:21:49 <hyc> would kinda suck having to wait every time you startup a program
18:21:56 <gingeropolous> not as a key, but as a pay-for-service
18:22:10 <gingeropolous> well, surely there'd be a separate service that accumulates credits
18:22:48 <gingeropolous> so there'd be like a monero app store. everything in the store can be used with monero credits
18:23:14 <gingeropolous> or u just buy credits. i dunno
18:25:44 <moneromooo> What I'd like to see is this plugged into bittorrent. Incentivize people to keep seeding stuff.
18:25:57 <moneromooo> Or even just for priority.
18:27:12 <moneromooo> Like the first yggdrasil release ^_^
18:28:01 <gingeropolous> yeah, a lot of possibility applications of it.
18:28:34 <gingeropolous> i realized, however, that it might not be as much as a pool-deterrent as i originally thought
18:28:49 <gingeropolous> someone will eventually code up a version where the client can just send shares to a pool
18:29:04 <moneromooo> Well, it doesn't deter pools, it adds an alternative source of hash, really.
18:29:42 <moneromooo> What would this bring, compared to what pool miners do now ?
18:29:43 <gingeropolous> yeah
19:31:09 <gingeropolous> ah ok. automagic node discovery is only done via bootstrap node mode
19:49:31 <gingeropolous> i wonder if its safe to say that a pruned node will need 25 GB storage for like 10 years
19:49:59 <moneromooo> It's safe to say to a person who's at least 10 kg lighter than you.
19:50:42 <moneromooo> I expect it'll increase by... 90% to 70% of the unpruned chain increase, roughly.
19:50:44 <Mochi101> Quite the riddle
19:51:19 <skrech> hey guys, after 5 days of syncing the lmdb failed again at around 85%
19:51:25 <skrech> this happens for second time
19:51:39 <moneromooo> What errors, if any ?
19:51:57 <skrech> erm, now it's Input/Output Error
19:52:08 <moneromooo> That's usually "your disk is shot".
19:52:21 <gingeropolous> spinny skrech ?
19:52:25 <moneromooo> But I think liblmdb reuses it for something.
19:52:44 <skrech> so... tonight I'm coming from work
19:53:15 <skrech> I see that for 5 hours it was outputing something like: for the last 90 mins there is no incoming blocks
19:53:22 <moneromooo> There's some bug where something writes to the lmdb file by mistake. You're possibly hitting this.
19:53:24 <skrech> I stopped the daemon and restarted it
19:53:52 <skrech> and it started to sync again, but was using all my CPU cores while I've specified --prep-blocks-threads=2
19:54:04 <skrech> so decided to restart my pc
19:54:21 <skrech> and after the restart it's this error
19:54:26 <skrech> I'm really confused
19:55:34 <skrech> maybe I can play with --db-sync-mode
19:55:39 <skrech> so it's more secure?
19:56:15 <skrech> I use the default (eg. not specifying this option) which I think is fast:async:250000000
19:56:19 <moneromooo> That will help against hardware/OS breaking. It won't against a stray fd write. It seems you're hitting the latter.
19:56:40 <skrech> this is some new bug?
19:56:47 <moneromooo> Apparently so.
19:57:22 <skrech> hm...
19:57:31 <skrech> if I download the blockchain.raw
19:57:46 <skrech> and then import it... will this make a difference?
19:58:13 <moneromooo> Probably not to the likelihood of the bug appearing. But definitely to the bandwidth load.
19:58:50 <skrech> what bandwidth load? memory? cpu?
19:59:29 <moneromooo> Network.
19:59:38 <skrech> network is not a problem
19:59:59 <moneromooo> It'll likely be very similar for CPU/memory.
20:01:29 <skrech> is there a bug report about this "fd" bug?
20:01:41 <skrech> so I can't read more about it?
20:02:22 <gingeropolous> i don't think there is.
20:03:50 <moneromooo> Some backlog in -dev earlier today. It's not known exactly what it is yet, just suspected to be a stray write.
20:04:24 <moneromooo> Possibly from libunbound, since the stray data was an unbound message.
20:06:39 <skrech> so somebody else is having a similar problem like mine?
20:08:33 <skrech> and just to be sure - there is nothing I can do to try to fix the db? My only option is to start over?
20:08:43 <gingeropolous> yep. took down xmrchain.net node :(
20:12:19 <moneromooo> skrech: are you running with --detached ?
20:17:32 <skrech> moneromooo: yes
20:18:18 <moneromooo> Try without it then. It's possibly a cause.
20:22:28 <skrech> I decided to update some packages now that I restarted the PC, and see:
20:23:30 <skrech> unbound: 1.9.4 -> 1.9.5
20:27:30 <skrech> moneromooo: I'm also using --enforce-dns-checkpointing
20:44:31 <moneromooo> That one is irrelevant I'm pretty sure.
21:34:47 <kinghat> jtgrassie: https://www.coindesk.com/a-plan-to-decentralize-bitcoin-mining-again-is-gaining-ground
21:53:36 <selsta> 21:18 <moneromooo> Try without it then. It's possibly a cause. <-- mine crashed without detached
21:53:47 <selsta> skrech: Did you self compile or use release binaries?
22:44:18 <skrech> selsta: I use binaries
22:45:55 <selsta> hmm ok
23:09:32 <spoke0> can i revert a integrated address into it the standard address and the payment_id without any other information?
23:09:41 <selsta> yes
23:10:59 <moneromooo> "integrated_address $address" in simplewallet
23:11:09 <moneromooo> Or there's a split_integrated_address RPC.