 Show Posts
|
|
Pages: [1] 2 3 »
|
ChainRadar seems to be stuck. |
|
|
|
I do remember clearly the times with 400k XMR on sale.
It's probably about the same amount nowadays too, just spread across more exchanges. |
|
|
|
Is it even possible to enable OpenCL on the GPUs on a command-line-only linux, without X.org installed?
Sure it is, it's called headless install all my linux rigs are setup that way. Would you mind pointing me towards some guides on how to do it? |
|
|
|
|
Is it even possible to enable OpenCL on the GPUs on a command-line-only linux, without X.org installed?
|
|
|
|
I've been wanting to give Monero a try for a long time but I have an issue - I need a good Electrum-like "light wallet", I can't download a large blockchain and I refuse to use web wallets. Is there any choice for me? Thanks in advance
You can use the wallet (CLI or GUI) with an external daemon. There are a few open for everyone to use. |
|
|
|
... many smarter users starting watching the blockchain for encrypted payment IDs arriving at our addresses... How do you do that with cryptonote coins? Do they publish viewkeys? |
|
|
|
Created in 2013, monero is a privacy-centric cryptocurrency ... 2013, really? |
|
|
|
Plus ya got the coolest avatar on the board LOL
Pretty cool indeed, but smooth's is the coolest  |
|
|
|
The transaction got sent in the end, this morning I can see first few confirmations. (feuw!)
Was probably in mempool competing with a higher than usual number of other transactions for a spot in a block. |
|
|
|
Thank you. I was sending to Poloniex two hours ago and nothing is showing on any end. I don't understand why I can't see the transaction in the gui wallet in history or anywhere to be able to check whether it was sent or not at all...very confusing.
The transaction not showing at Poloniex may not mean anything now because they have been under much heavier traffic than they were prepared for. I would wait a bit more on an update from them. On your end though, the outgoing transactions are being logged locally by the wallet software. Since it crashed right after sending, it might not have managed to do it. I'm not using the graphical wallet software, but on the command line one I would issue the command "rescan_bc" and wait. Perhaps someone familiar with the GUI wallet can provide the equivalent. How long has it been since you tried to send? Did you send to an integrated address? (how many characters did the address have?) |
|
|
|
Hello. Just had a strange issue with the monero gui wallet. Tried to send the transaction, but wallet crashed when making it. When i tried again after restarting i had error message that there was a double spend and I was not able to send the coins again, but balance was still there. now I have tried rescan spent and the coins are gone. Was that to propagate the transaction again and the coins will be sent now again right? Just to be sure. Its quite a chunk of money and made me quite uneasy.
Really looking forward to time when there is smoothly working Monero wallet.
Thanks for help
Your wallet probably managed to broadcast the transaction onto the network before crashing. I would wait a couple of hours, then re-scan the blockchain to make sure the transaction went as planned. As a rule, never resend unless you've confirmed (preferably on a different instance of the wallet) the initial attempt didn't go through. |
|
|
|
"proprietary approaches"? (@min.40) |
|
|
|
0.3 XMR per minute. Now that block times are 2 minutes, the subsidy is 0.6 XMR.
Ah, forgot about the block time change. Thank you. |
|
|
|
1) It has an adaptive blocksize limit with a minimum emission of 0.6 XMR. ...
I think I remember correctly that it was 0.3 XMR, not 0.6. |
|
|
|
thx, yup adaptive read ahead and write through is my setup. 512MB cache doesn't seem to matter either. I will be upgrading to ryzen soon anyway.
More system memory may help. If you can cache the whole blockchain in RAM that would speed things a lot. Get at least 32GB on that Ryzen machine and create a 16-20GB ramdrive (since you're on Windows, try imdisk). Put the bockchain there and when you're done syncing, dump it back to disk. |
|
|
|
Perc 6i raid 5 ~300MBs
RAID5 doesn't have fantastic random IOPS performance. For the daemon, random IOPS (few writes among a lot of reads) is what you want. What have you set the write cache policy to in your PERC6/i, writeback or writethrough? What about the read ahead setting? I would suggest no read ahead or adaptive read ahead. |
|
|
|
... insignificant value compared to just being their, bags full, when the moves come.
Tz-tz-tz aminorex, I know this is a speculation thread going through an exciting period, but one must not throw away proper spelling, must he not? I'm only mentioning this because I know you'll appreciate it. |
|
|
|
Thanks for letting us know. If the devs need any info from me, or to beta-test a future fix, I'll be happy to help. |
|
|
|
Could you check in the logs whether there are any "Block fails to get added" messages? It's probably easier to spot if you restart monerod with --log-level 1.
I've tried --log-level 3 as well, but it's the same deluge. However, with --log-level 2 it's easier to spot the important things. What intrigues me is this message: 2017-05-16 20:44:22.197 [P2P8] INFO net.cn src/cryptonote_protocol/cryptonote_protocol_handler.inl:981 [IP:50350 INC] Block verification failed, dropping connection "IP" is different every time. (over a couple of minutes worth of logs this is present dozens of times) I don't see any messages like "Block fails to get added". EDIT: Actually, this is even more relevant: 2017-05-16 20:41:19.797 [P2P9] ERROR verify src/cryptonote_core/blockchain.cpp:3185 Block with id: <82e8a00ebb396dcafc9ba5b44e9aad367bbc8f886736b0a49dd506c114b621fa>
does not have enough proof of work: <2e55a37fb07a0813b6fa36e541e677d538c9d6b8105f6d60e07682af4239abfb>
unexpected difficulty: 60 And this repeats for every peer. |
|
|
|
Which OS? I presume Linux / Mac OS X, but I'd like to know for sure. Anyway, it should be in $HOME/bitmonero. The directory itself may be hidden, so you have to manually browse to it. Alternatively, on Linux you can unhide directories by using CTRL + H.
I've tried your suggestion with "--block-sync-size" (even a value of 1) and it doesn't get it past 1200001. I'll delete the blockchain and let it resync from scratch. I'm running the same linuxarm7 build as monerostruggles1111 EDIT: Stopped the daemon and tried to run it on the testnet, to see if it syncs. I got the same behavior, only this time it's stuck on block 3, hehe. EDIT 2: I've restarted it with "--log-level 4" in hope the details might shed some light on the problem. Right now it's dumping a 100MB log file every 2 minutes mostly with messages like: 2017-05-16 18:47:27.212 [P2P0] TRACE blockchain src/cryptonote_core/blockchain.cpp:2105 Blockchain::have_block
2017-05-16 18:47:27.212 [P2P7] TRACE blockchain.db.lmdb src/blockchain_db/lmdb/db_lmdb.cpp:1434 BlockchainLMDB::block_exists
2017-05-16 18:47:27.212 [P2P7] TRACE blockchain.db.lmdb src/blockchain_db/lmdb/db_lmdb.cpp:2445 BlockchainLMDB::block_rtxn_start
2017-05-16 18:47:27.212 [P2P7] TRACE blockchain.db.lmdb src/blockchain_db/lmdb/db_lmdb.cpp:1445 Block with hash 170fd80f88150c79fb52776d5088f253c8cbf9cc7257ba467cada590586a827f not found in db
2017-05-16 18:47:27.213 [P2P7] TRACE blockchain.db.lmdb src/blockchain_db/lmdb/db_lmdb.cpp:305 mdb_txn_safe: destructor |
|
|
|
|
