 Show Posts
|
|
Pages: [1]
|
Pool: Thank you for testing the pool. We are over 500% of estimated shares finding a block. I suggest you move your miners back to your wallets if we don't find a block in the next few hours, might be waste of cpu power right now. I will have a look on the logfiles and the shares that got submitted, maybe i can find the reason why we didn't find a block yet. I applied 0% pool fee, fixed on the accounts, on all registered miners. The pool will get checked by me again in 2-3h and i will post here again. If we didn't find a block please move your miners, i don't want you to burn your powers  Nice too see, that VRM is on bittrex, price is much higher than i thought it would be I don't know if you went with unomp but did you set up blocknotify or similar? https://github.com/UNOMP/unified-node-open-mining-portal/blob/master/README.md#optional-recommended-setting-up-blocknotifySorry if silly question  Edit: I had another read over it and it doesn't do what I thought just alternate way to read new blocks I think |
|
|
|
Good news!
Thank you So far we have 6 registrations/tester for the pool. As a bonus for all the testers, investing hashrate and energy i would like to offer you 1 month 0% pool fees if you want to mine more on my pool. Of course you don't have too but maybe you want to  effectstocause has spotted some problems with email notifications/registration email. I have unlocked all registered persons (sry for that) and i will have a look on the emails this evening. Here is a screen of the pool, we didn't find a block yet but let's hope the settings are right  Informations: - Personal share rate: kh/m - Pool share rate: kh/m (got fixed this evening, that you effectstocause for informing me ) - Shares: Because the difficulty is so low, it seems like MPOS has some problems with showing the shares. Every submitted share (atleast for me) is about 0.002 of 1 share. I will have a look on this and change it to a more reliable value, because i know we all want too see on pools, that we are actually transmitting shares - Pool workers: this is actually showing the right amount of miners - Global Hashrate: MPOS has some configs for receiveing the current global hashrate. Sadly, on Verium (i am not blameing the devs  ) this command got removed. I have some ideas how to get global hashrate, but so far please use your own wallet for global hashrate checks I have a linux machine (cpuminer-verium) and windows machine connected currently (windows using generic miner with -a scrypt:1058476) connected to pool fine! For fun of it compiled cpuminer-verium on Raspberry Pi B+ and it is submitting shares, but in the worker configuration tab it has an X next to it, most likely hashrate is too low! Now all that's left is to find some blocks together =) To be honest I really hope getting listed on an exchange is delayed as much as possible because it gives us time for us early adopters to mine the hell out of it first.
It's a double edged sword IMO if the early mine goes too long and people think they've 'missed out'
EDIT: @testbug Incase it helps, my miner logs indicate that the rejected shares happen right after a new block is issued - so most likely the miners are submitting a couple of shares for the old block which are getting rejected - I have similar reject rate to pool as whole so far.  |
|
|
|
Are these your machines? If so what are you running |
|
|
|
This is good news |
|
|
|
It seems like the blockchain hates my guts, I'm mining at 900 H/m and last block I found was 2 days ago  , maybe I should start a new wallet. One of my miners is a similar hash - hasn't found anything in ~48 hours either but it doesn't mean it's broken! It's hard to get accurate sampling in statistics from one node, I haven't found a pattern or even 'best machine' from my miners - the most blocks I have found are on my lowest hashrate! These things need time and stability to even out even mining for a few weeks isn't long enough IMO to settle into the rhythm hope this coin will be in bittrex soon
Yeah you guys can't wait to dump it asap Or to find out market value to help with calculating mining cost/profit |
|
|
|
Hey guys,
looking into problem. The blockchain froze so we are on pause till we resolve the issue, it looks like someone submitted a block with a future timestamp and that threw the difficulty calculation off. I'm looking deeper into the problem, but likely we will need to release an updated wallet that handles this problem specifically before we get going again. Thanks for your patience while we work this out.
Thanks for the update, I'll keep my miners off until is resolved then |
|
|
|
true, there were big bounces in the past 24hours. Can someone tell me why am I syncing from only one source ? 
[
{
"addr" : "104.197.90.102:42596",
"services" : "00000001",
"lastsend" : 1473373151,
"lastrecv" : 1473373469,
"conntime" : 1473373150,
"version" : 80000,
"subver" : "/Veritoshi:1.0/",
"inbound" : true,
"startingheight" : 2394,
"banscore" : 0
},
{
"addr" : "209.181.66.82:57134",
"services" : "00000000",
"lastsend" : 0,
"lastrecv" : 1473374536,
"conntime" : 1473374536,
"version" : 0,
"subver" : "",
"inbound" : true,
"startingheight" : -1,
"banscore" : 0
}
]
if there is any new connection, it looks like the 2nd, no version/subversion/ height -1 and it lost after a few seconds. Right now I got a few new connections with version and I'm stuck at block #2000 That's odd, did you resync from scratch or from bootstrap? The one miner I did refresh blockchain on I started with bootstrap it's now connected to ~24 peers and stuck again on the 2394 block |
|
|
|
...
For the last couple of hours of activity there has been a lot of hashpower mining on and off every few blocks. Perhaps someone is trying to fork the chain? I did not notice anything alarming with a drastic increase hashpower Network hash rate was going up to 600 Mhs, then down to 130 again and again. I didn't see this either, but that is a lot of hash power... |
|
|
|
Same problem here, all wallets had last block synced about 2.5h before.
I am running the 1.0.1 wallet on windows and linux, same problem.
I tryed redownloadeing the blockchain over the menu -> same problem
Strange thing is, that if the wallet keeps running it is getting more connections and the miner can be turned on
As Kazadar pointed out, Block explorer is paused also any many of us share issue - most likely wont be anything we can do our end right now. I was about to cycle this on my miners but did it on one and got the same result as you  edit:
Maybe the 40 minute ago #2392 block has something to do with it?  |
|
|
|
Is network down? Whats happening? Wallet is not syncing. Last block was 2 hours ago.  No issues here...Did you restart the wallet? Updated to new version? My miners are stuck on this block too, going to try reload blockchain |
|
|
|
miner for windows
Can mine from Windows wallet - personally as I haven't had luck getting the pool running yet I am running my machines from the GUI wallet |
|
|
|
Just use scrypt, I've hard-coded all the other parameters already Thanks for all your help in this topic + verium miner, I don't think I would have found this info otherwise =) I am just playing around with the standalone miner.
Its getting any work. I am guessing I have something wrong in my .conf file.
Could someone post their .conf file code for using the external miner please?
For the veriumd? Mine looks like addnode=vrmsupernode.vericoin.info
addnode=vrmsupernode3.vericoin.info
gen=1
daemon=1
rpcuser=CHOOSEUSERNAME
rpcpassword=CHOOSEPASSWORD
rpcallowip=127.0.0.1
rpcport=2300
server=1
|
|
|
|
You can use any "normal" scrypt-n pool soft, just edit the Scrypt-Scratchpad Buffer in scrypt.cpp or scrypt.h to meet the (insane) setting of Verium and pass "19" to the N factor of the miner when mining..
In unomp files I edited Scratchpad Buffer to the value i found in verium scrypt.h - the miners i've found need N factor to be power of 2 so can't pass 19  out of passing random powers as N factor I have 11 accepted shares and ~600 failed XD Any chance you can elaborate on your last post?
UPDATE I ended up getting shares submitted / accepted using scrypt:4096 on miner, Is the daemon rejecting 'blocks' because of this incorrect N factor? |
|
|
|
Hi everyone, I am trying to set up a mining pool using UNOMP for Verium Mining which uses scrypt² algo - in the current setup when connecting a single miner about 95% of the hashes are rejected, just looking for some feedback on my thoughts of what to try to resolve this 1) Perhaps I need to modify UNOMP to support scrypt² in some way 2) Maybe my settings for difficulty and timing need tuning to find the correct values 3) Server could be not powerful enough Using this modified miner: https://github.com/ocminer/cpuminer-veriumwhich I found in VRM thread, has output like:  Any help is appreciated |
|
|
|
Nice,
mining try was like, huh i have it says 600blocks, but the next line starts saying
less blocks each time i start the wallet, on another system also, start mining, current blocks like 600, the total blocks going down
on both systems..
Sounds like the blockchain is still syncing According to the blockchain explorer as of this post there are 574,653 VRM in existence. How many are left to be mined?
This post says 2.7 million eventually: How many total coins?
~2.8 million total supply via mining for years. Could take anywhere between 6 and 64 years or so to reach total of 2.8 million VRM. At launch via ICO and promotions about 800k max will be available supply. |
|
|
|
Ok I'm a little confused. I mined a few Verium on launch so now what can I do with these Verium? Do I swap them for Vericoin somehow? Do I hold them for some future purpose?
We are waiting for VRM pairing to be added to exchanges then I am told we can exchange using swap in the wallet. I just filled out the link by souljah1h above, It can't hurt the process |
|
|
|
|
