Exchanges usually have wait for a certain number of confirmations before crediting your account there. The number of confirmations depends on the currency and exchange.

With Bittrex, you can normally see that you have incoming funds from the first confirmation, and how many confirmations until it is available to you.
Last time I used Livecoin, I remember not seeing anything showing up for maybe 30 minutes, and then suddenly, it's there. I suppose Livecoin wasn't scanning their SHIFT wallet as often.

Just make sure to send to the correct address. If you see the transaction in the explorer. The exchange has most likely seen it too.

So true, It's been quite a ride so far!

Closest thing to "staking" would be voting for delegates that will pay for those who vote for them.
There is at least one:

https://pool.shiftnrg.org/

I guess you could compare payouts from a voter address with about 8k... Currently 8k looks to be about 0.32% of the pool voters. I believe 32 Shift/day is what a delegate should earn if it manages to forge all blocks, so about 0.1 Shift per day with the current rate and assuming no pool fee.

Could also run your own delegate. A delegate needs enough votes to be in the top 101 in order to Forge. Each forging delegate has the opportunity to earn the same amount, this depends on the delegate maintaining its vote weight in the top 101, running smoothly and having the correct version of software.

That's interesting. In this case, Coinmarketcap's method of sorting exchanges by volume is a bit unfortunate as it doesn't show up just under Bittrex. I would have missed it if I didn't scroll down.

Elected delegate nodes ( 101 of them ) take turns forging coins.  A new coin is forged every minute assuming that all the delegates are running.

Info about the reward on the masternode info  page.

http://178.254.23.111/~pub/DN/DN_masternode_payments_stats.html

I almost exclusively use the cli (in this case "pivx-cli" ) for most crypto. If you use the GUI things may be different...

There is the "account" system which I guess most coins derived from bitcoin have inherited. The account system lets you put address into accounts.

What I have done when making may masternode address is:

$ pivx-cli getaccountaddress "account"

So the rewards to the masternode accout show up under the account:

$ pivx-cli listaccounts
{
    "" : 553.08646764,
    "mn01" : 10004.68000000,
    "mn02" : 10000.00000000,
}

You could use:

$ pivx-cli setaccount "pivxaddress" "account"

The account system has it's flaws.... and you can end up with misleading numbers.

pivx-cli listunspent 6 9999999

Will show all your unlocked transactions.

It could be less, for example, if some other masternodes are shut down or have a misconfigured firewall perhaps.

I'm not sure about the consensus algorithm for how the winning masternodes are chosen. I have had a masternode get no payments for a bit longer period and then have rewards come in more quickly. But it should average out.

At the moment I count 380 masternodes that haven't received payments. I may try to collect some more data and see how the situation changes.

EDIT: For me, masternode payments have started coming in after 90 hours.

Once the masternode gets the first block, the next ones come in turn according to the number of masternodes.

The transactions for the masternode(s) are "locked" when you start your wallet. (pivxd reads the transaction list from the masternode.conf file).

If you comment or remove those lines from the masternode.conf and restart the wallet, transactions that were reserved for the masternode will be able to stake. After those transactions stake, they will not be able to be used for a masternode so you would need to go through the process of setting up the masternode again.

I think the the block rewards would be about the same or maybe a tad more than the equivalent time staking. The three+ day wait is a bit painful considering that the block reward is scheduled to halve when we reach "PoS Phase X: [blocks 648000-Infinite] 05 PIV (90% SEESAW ~ 10% BUDGET)". Certain upgrades need a restart and then all who run masternodes need to wait some time. This is longer than before but there are more masternodes now than when I was running this before.

Myself, I had been staking for the last while since running masternodes needs a bit more effort and attention. I put some pivx back into masternodes for this upgrade a bit over 3 days ago, thinking I would get a bit more in this last month with the higher reward. It's hard to say what the best decision would be there's another 21+ days to go until the block reward halving.
 
With 2037 masternodes, a masternode payout should about about every 1.4 days.

According to one of my masternodes about an hour ago, here's a list of the largest uptimes  for unpaid masternodes in seconds....

  325883
  325933
  325984
  326057
  326120
  326139
  331264
  340139
  345954
  408003

The last one seems to be an outlier, it's possible that it is misconfigured.  (Yesterday when I looked the oldest ones were in the 360000 seconds range.

At the moment, the oldest unpaid masternode was started 113 hours (4.7 days) ago and the next one 96 hours (4 days).

I would say be patient and don't mess with anything if you started less than 4 days ago.
Can't say for sure how long it would take if a masternode was restarted today.

If you would like to check that the masternode is running ok can try running the following on the masternode.

"$ pivx-cli masternode debug
Masternode successfully started"

If it is more than four days, you might want to have a check that how many peers are connected and that other peers are able to connect to it.

Maybe someone with more technical knowledge here can could provide some more detail for things to check.

I suppose... it is ok for a masternode to not have any inbound peers as long as masternodes are able to make connections to the masternode's port 51472 at its advertised IP address or TOR address.

Time to vote for pivx on cryptofolio...

https://cryptofolio.info/welcome/vote

Best that you send a message to ShiftConnect about exchanging them.

Ok, that's really good to hear... The wallet with the problems has a slowish disk and occasional network hiccups. Hopefully it's just that...

.....

[/quote]



Had no issues with the switch to PoS level 4  -  3 wallets +15 MN
 

[/quote]

Had no problems here either. Payouts running smoothly.
[/quote]

Ok, that's really good to hear... The wallet with the problems has a slowish disk and occasional network hiccups. Hopefully it's just that... [/code]

Might want to check for forks...

I had a staking wallet that got stuck at block 390756 it appears it has forked at block 390747. Will reload the blockchain on this one.

BAD:


GOOD (matched the masternodes stats blockhash at block 391442):

http://cryptocoin.cc/ would be an interesting site for SHIFT to try to be listed on. To the point, release information, good feeds.

Yep, sounds right.

Happy, that you appreciate my answer. It feels good to be able to write something helpful.

Myself, I had produced shares worth about 0.00001 to a z address while figuring out how compile and run get the miner working... Switched to the t address early enough. It might have almost been worth a coffee at a gas station if I started mining on the the first day and sold for 200 BTC/Zcash. :-)

Good questions... that could use a bit of explanation.

Question 2:

The wallet file contains a database containing private keys, their associated public addresses and some metadata about them for example, date first used, a label for the key (if you use the "account" system to put different addresses into groups known as accounts), the state if the key ( used or or reserve ).

A private key allow you to sign transactions to transfer certain coins (coins that have been sent to or mined by a corresponding addresses).

The wallet file contains many keys, which can be in use (have been perviously  used in a transaction) or in reserve
- one that are currently used and may be used to transfer coins if there is a balance
- reserve keys are stored for future transactions, for which addresses have not been seen on the chain yet. normally a pool of reserve keys is generated when the wallet software is started in order to quickly have a pool of ready addresses to use. (Generating these on the fly as needed would slow things down)


Question 1:

How safe it is to send this file depends on the value of what is in the wallet. (are there coins "in" the wallet)

If someone else were to get access to this file, or the privates keys,  they would also have control over coins to and would be able to sign transactions to send those coins elsewhere.

If there is value in the wallet. (either now, or if you expect coins to be sent to addresses in that wallet in the future) then it is not "safe" to send.

Question 3:

"Empty" the wallet by sending all coins to addresses in another "new wallet". If you expect more coins to come to addresses in that wallet, (eg another pool mining to an address in that wallet).

The New wallet should have completely different keys and addresses than the "Empty" or to be emptied wallet. The Empty wallet should not be used again (as someone else potentially has control over coins sent there). The keys from the old wallet should not be used in a new wallet.

Why do it this way??

The pool maintainer asks for the wallet as proof that the address is or was under your control to you. Then he can be relatively certain that to Address you say was used in the pool actually belongs to you. He asks that the wallet is empty because it is possible that if you send it by email, or private message,  in the process of being transferred the message along with the private keys may be sent in the clear over the network or may at some point be stored on in a file that someone else has access to. After someone else has potentially seen your wallet dat, it's security has been compromised. (the are of course other ways for the security to be compromised)

backups

You should keep a backup of your old wallet in case coins end up there.  Label the backup so it is not mixed up with others ( use a descriptive and accurate name, like zcash_to_be_emptied_november2016.dat ). Store backups safely.... (don't use a USB stick the you will allow others access to in the future)

new wallet..

Maybe sending your coins to an exchange you can trust for long enough.

After backing up the old wallet... you could erase the old wallet restart zcashd which will make a new wallet...

Fiddling with wallets is error prone so it is probably safer to use a separate user account or machine for the new wallet... and keep backups of that too.


If anyone is interested in testing anonymous transactions... here is a z-address:
zc9UA9ec5C1FHU1QzKKF8mH7iwiCVBdepRQxaMyVpG2kFTZPd6QcjivrcLaTANqacuQWspbEhSSUajZ yPnBqzpBXRwKa2w7

For tax purposes, any transaction sent there will be considered a gift.

Block rewards are going up too, but now the difficulty has recently been 170000-230000 as opposed to 90000-120000 a day or two ago.
 

Hi,

Currently mining with two NVIDIA GPUs... a 970 and a 750Ti. ( ./zcashgpuclient_silentarmy )

I guess that the miner starts 2 threads per GPU for collecting the results.

The 970 works fine (GPU0,1)  but the 750Ti  (GPU2,3) it seems can't handle 2 threads....

[GPU 0] T=-1C A=-1% sols=10.723
[GPU 1] T=-1C A=-1% sols=10.151
[GPU 2] crashed!
[GPU 3] T=-1C A=-1% sols=8.748


When starting the miner, the behaviour of the 750Ti is intermittent.  If it doesn't mine, usually, stopping and starting the miner will fix the problem, and it will mine as GPU2 or GPU3

Here the 750Ti doesn't mine at all.


Here, it mines well (with one thread, ~8 sol/s is acceptable I think)


I fiddled with the threads and work size and it seems that "threads: 512, work size: 256" for the 750Ti works well.

Any ideas for better settings or if it would be possibly to set the number of threads used for a GPU?

I'm mining here now because this was the first pool software I could get working well with Linux.  
The pool seems to be working well enough (probably no more hiccups than other pools) and  
paying out, so for the time being, I will continue mining here. The "Minimal Payout" adjustment works for me.  

It would be nice to see more statistics about the pool and a description of the payout scheme. Transparency
would increase the amount of trust from the miners. 4% pool fee is maybe a but higher than usual, but being
able to compare performance with other pools would be nice and could justify the fee.

What would be nice to see in terms of stats would be:
- count of shares per miner
- shares per block or round

I'd also like to say that so far, I am satisfied with the results from this pool. Initially I was a bit wary about
using pool since the software is unique to this (ZEC) pool.