nioc:yeah, I want to make sure I understand the implications of using a remote node

and I dont wnat to run a local one becuase I don't wnat to download the entire blockchain

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

I don't think I have enough space for it on this machine nayway, I deleted it a while ago to free up space

I guess you know that you can sync the blockchain in pruned mode which will be about 1/3 the size

still 25GB+

is there a way to disable the "I locked your Monero wallet to protect you while you were away" message? or increase the timeout?

hey erikd docs show set inactivity-lock-timeout 600

0 disables entirely

Bill48105: is that not availabel as a command line option?

and is that in the daemon or in the cli wallet?

erikd, cli wallet

thanks Mochi101 amd Bill48105

just have to set it once and it remembers

per wallet

there's not much need to lock daemon eh

glad you got it sorted

Always best to lock up your demons 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

yea

i chose not to disable it but to increase the timeout to 600 seconds

nice plan

better to have that safety net with minimal inconvenience

good work on the fork

<3 bigslim[m].

went smooth it looks like

you guys find any issues?

<vie> monero network hash so heigh now

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"

Is that normal?

I can post complete information if you need

xie did you look at how wallet_rpc_server.cpp fills in "transfers"?

It can find the same txid multiple times. The ones with "pool" type are unconfirmed pool payments.

you need to check unlock_time to see when it will be confirmed

The transaction has been confirmed

"confirmations": 39

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

so it's unconfirmed transaction in mempool

"id": "0", "jsonrpc": "2.0", "result": { "transfer": { "address": "85nC8EEXBgLGKbc73fDZj1GPckq4VVCzXYX9RCtsYWKBco8jxibdZLxUYYFN5bJBkFdzNc4e8JYLSQRhg1oMkBc4MByzrW6", "amount": 12340000, "confirmations": 19, "double_spend_seen": false, "fee": 25030000, "height": 1979842, "locked": false, "note": "",

"payment_id": "0000000000000000", "subaddr_index": { "major": 0, "minor": 60007 }, "subaddr_indices": [{ "major": 0, "minor": 60007 }], "suggested_confirmations_threshold": 1, "timestamp": 1575273569, "txid": "af67e83d8d6cdae2f93d30de85ce7f3b458c1a34ff43be4cda027361961011ec",

"type": "in", "unlock_time": 0 }, "transfers": [{ "address": "85nC8EEXBgLGKbc73fDZj1GPckq4VVCzXYX9RCtsYWKBco8jxibdZLxUYYFN5bJBkFdzNc4e8JYLSQRhg1oMkBc4MByzrW6", "amount": 12340000, "confirmations": 19, "double_spend_seen": false, "fee": 25030000, "height": 1979842, "locked": false, "note": "",

"payment_id": "0000000000000000", "subaddr_index": { "major": 0, "minor": 60007 }, "subaddr_indices": [{ "major": 0, "minor": 60007 }], "suggested_confirmations_threshold": 1, "timestamp": 1575273569, "txid": "af67e83d8d6cdae2f93d30de85ce7f3b458c1a34ff43be4cda027361961011ec",

"type": "in", "unlock_time": 0 },{ "address": "85nC8EEXBgLGKbc73fDZj1GPckq4VVCzXYX9RCtsYWKBco8jxibdZLxUYYFN5bJBkFdzNc4e8JYLSQRhg1oMkBc4MByzrW6", "amount": 12340000, "confirmations": 0, "double_spend_seen": false, "fee": 25030000, "height": 0, "locked": true, "note": "", "payment_id":

"0000000000000000", "subaddr_index": { "major": 0, "minor": 60007 }, "subaddr_indices": [{ "major": 0, "minor": 60007 }], "suggested_confirmations_threshold": 1, "timestamp": 1575273548, "txid": "af67e83d8d6cdae2f93d30de85ce7f3b458c1a34ff43be4cda027361961011ec", "type": "pool",

"unlock_time": 0 }] }}b

just don't ask for mempool in your request (set req.pool = false)

will try your suggestion

the one you got with type=pool has confirmations=0 which is normal for tx mempool

not sure why it ended up in the response if it has already been mined

it has something to do with how wallet refreshes, need someone more knowledgeable to clarify it

The balance has beed updated accutally

Maybe this is a display issue

!Horla Thomas J. Stanley - Millionaire Women Next Door (epub).epub

Invalid command, try !help

xie: supposedly fixed in cbec8eb10bd0f0d82b6524df2b4af714b1b3599a, are you running an older version ?

I am using this one

Ah, 0.1 is out

there is a newer tag xie github.com/monero-project/monero/releases/tag/v0.15.0.1

Was trying to find it on mobile, ginger beat me :(

I guess the issue is that it hasn't been marked as latest release yet

So this is fixed in v0.15.0.1?

I did notice v0.15.0.1, but thought it is not a stable version

xie: It is a stable version, the Github release page just has to get updated.

It is fixed in 0.15.0.1.

Cool, just want to confirm. Glad to know it has been fixed in the latest release

thank you guys

I found some transactions still contain paymentId according to get_transfer_by_tx

get_transfer_by_txId

But I have set paymentId as ""

It's strange, most of new transactions is good

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.

Ok, will ignore it

Hey guys anyone have a good usb / live linux distro that is configured to basically auto mine as soon as it boots up

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

headless, does not need any gui...is there a such thing as like a xmrig preconfigured distro?

mfed3[m]: you could create something like that with buildroot. or start off with someething else like alpine linux

So nothing already preconfigured, but this would be me essentially installing linux to a usb drive marked as bootable

Then only installing a minimal package set

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

It is one possible solution, I was hoping someone maybe knew of an appliance distribution built for this purpose

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

Add xmrig to buildroot and voila.

libuv, hwloc and openssl are already packaged for buildroot so its barely any work ^^

<learninandlurkin> I believe the project you're thinking of was called Pickaxe OS, and I don't think they upgraded to RandomX yet

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

<\​x> needmo: cope

<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

Before I waste my time reinventing the wheel haha

is selena here? is that the person that did monero primo? Would be cool to carry that over to general software / licenses etc.

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

but you can't fake PoW

you want to use PoW as a software key?

would kinda suck having to wait every time you startup a program

not as a key, but as a pay-for-service

well, surely there'd be a separate service that accumulates credits

so there'd be like a monero app store. everything in the store can be used with monero credits

or u just buy credits. i dunno

What I'd like to see is this plugged into bittorrent. Incentivize people to keep seeding stuff.

Or even just for priority.

Like the first yggdrasil release ^_^

yeah, a lot of possibility applications of it.

i realized, however, that it might not be as much as a pool-deterrent as i originally thought

someone will eventually code up a version where the client can just send shares to a pool

Well, it doesn't deter pools, it adds an alternative source of hash, really.

What would this bring, compared to what pool miners do now ?

yeah

ah ok. automagic node discovery is only done via bootstrap node mode

i wonder if its safe to say that a pruned node will need 25 GB storage for like 10 years

It's safe to say to a person who's at least 10 kg lighter than you.

I expect it'll increase by... 90% to 70% of the unpruned chain increase, roughly.

Quite the riddle

hey guys, after 5 days of syncing the lmdb failed again at around 85%

this happens for second time

What errors, if any ?

erm, now it's Input/Output Error

That's usually "your disk is shot".

spinny skrech ?

But I think liblmdb reuses it for something.

so... tonight I'm coming from work

I see that for 5 hours it was outputing something like: for the last 90 mins there is no incoming blocks

There's some bug where something writes to the lmdb file by mistake. You're possibly hitting this.

I stopped the daemon and restarted it

and it started to sync again, but was using all my CPU cores while I've specified --prep-blocks-threads=2

so decided to restart my pc

and after the restart it's this error

I'm really confused

maybe I can play with --db-sync-mode

so it's more secure?

I use the default (eg. not specifying this option) which I think is fast:async:250000000

That will help against hardware/OS breaking. It won't against a stray fd write. It seems you're hitting the latter.

this is some new bug?

Apparently so.

hm...

if I download the blockchain.raw

and then import it... will this make a difference?

Probably not to the likelihood of the bug appearing. But definitely to the bandwidth load.

what bandwidth load? memory? cpu?

Network.

network is not a problem

It'll likely be very similar for CPU/memory.

is there a bug report about this "fd" bug?

so I can't read more about it?

i don't think there is.

Some backlog in -dev earlier today. It's not known exactly what it is yet, just suspected to be a stray write.

Possibly from libunbound, since the stray data was an unbound message.

so somebody else is having a similar problem like mine?

and just to be sure - there is nothing I can do to try to fix the db? My only option is to start over?

yep. took down xmrchain.net node :(

skrech: are you running with --detached ?

moneromooo: yes

Try without it then. It's possibly a cause.

I decided to update some packages now that I restarted the PC, and see:

unbound: 1.9.4 -> 1.9.5

moneromooo: I'm also using --enforce-dns-checkpointing

That one is irrelevant I'm pretty sure.

jtgrassie: coindesk.com/a-plan-to-decentralize…coin-mining-again-is-gaining-ground

21:18 <moneromooo> Try without it then. It's possibly a cause. <-- mine crashed without detached

skrech: Did you self compile or use release binaries?

selsta: I use binaries

hmm ok

can i revert a integrated address into it the standard address and the payment_id without any other information?

yes

"integrated_address $address" in simplewallet

Or there's a split_integrated_address RPC.