"Investors" should be happy to see the fundamentals holding strong and that development pace is doing very well.
The official forum is also quite active and the community keeps growing at a slow & steady rate there.
Daytraders and PnD'ers are probably better off looking elsewhere. 

Sei lá eu!    Confesso que vendi uma parte do Monero que detinha durante esta tremenda subida, mas ainda assim, mantenho uma posição/investimento. É daqueles casos em que realmente ainda vejo potencial de subida - se favorável - eu imagino que o marketcap de Monero um dia esteja ali às turras com o do Ethereum.

No entanto, o preço está no que se costuma chamar de "discovery mode", porque realmente é território novo. Dito isto, acho que pode bem subir bastante, como pode descer bastante.

De notar, não é apenas os mercados negros que atraem para Monero. O SIGAINT (serviço de e-mail anónimo/seguro) é um exemplo muito importante nas comunidades que tem que lidar com opressão da opinião publica - anunciou recentemente que estava a correr um node de Monero.

XMR - Monero : Pela privacidade efetiva do protocolo, e ser um projeto desenvolvido sem tretas (contrariamente às varias alternativas ditas anónimas). Investimento de alto risco neste momento, atendendo ao quanto subiu de valor recentemente. 

DCR - Decred : Pelo sistema realmente novo de híbrido entre PoW e PoS, e sistema de financiamento a projetos e desenvolvimento de longo prazo. Pelo sistema de governação distribuída - que ainda não permite praticamente nada do que tem em potencial - portanto está numa situação muito favorável ao crescimento. Este considero investimento de baixo risco (tudo claro é muito relativo), particularmente a médio/longo prazo, e participando no processo de voto (staking).

Mantenho distância dos muitos projetos que prometem mudar o mundo amanhã, sem qualquer sustento ou seriedade. Sem duvida que alguns vão proporcionar altos ganhos para alguma malta (e igualmente tremendas perdas para outros), mas como se diz por cá, dinheiro não é tudo.

@Dcrstats: That reads quite misleading to me. Large pool profits can be reinvested, but there's absolutely no assurance of that always happening. On the other hand it hints at the idea that small pools might not afford to invest in their infrastructure or services, which is not a fair statement, because a tiny pool might have a comfortable budget isolated from ticket/user profits.

Such is the case with StakePool.eu.
We operate a tiny pool with healthy budget. We top your services since we do 25/7 support! 

Importantly, voting should be as distributed as possible, for a healthier and more robust voting network.

Note: Your pool currently holds as many tickets as all the other pools combined. You run an awesome stats dashboard that will always attract users to your pool (and I am a regular dashboard user btw, great job there). It's just frustrating to see these claims & adverts on top of it all.  Anyhow... I'll stay clear of further discussion about pools and such. Happy voting all.

Welcome IncludeBeer,

For ticket fees using the command line, wallet command:
getticketfee / setticketfee

The value you enter to setticketfee is per KB. So the absolute amount in DCR that you pay as ticketfee will vary according to the actual transaction size (which in turn varies depending on the number of inputs & outputs used).

For example:
https://mainnet.decred.org/tx/b12b14c10bff51b89194be57ddbdfc558f406fc84937c3ab82e57d50cf6b52c6
This ticket purchase (just a random pick off recent blocks), shows a ticketfee of ~0.101 DCR per KB, while in effect, the absolute fee amount paid was 0.03 DCR.

There's also a txfee, though the default value there should not cause you any trouble, and finally a poolfee, which you include in your ticket purchase command or wallet configuration (you will have certainly seen the instructions on the pool regarding this one).

Loosely related side note & advert:
Folks, please be mindful of not all picking the pools with the most users/tickets. A widely distributed ticket network, is a healthy ticket network. Kindly consider signing up with the stakepool on my signature, or any one of the (even) smaller ones.
Note also that pool size (in number of tickets) is perfectly irrelevant towards your chances of staking/voting. The pool is simply voting on your behalf so that you don't need to keep a wallet up at all times.

When you're buying tickets, thinks work much the same way as with any other transaction, but with the extra nuance that each block allows at most, 20 new tickets to be bought/mined. Until your ticket purchase is mined, it's as if it never happened. If you were trying to buy during a period where ticket prices were quite low (as it was the case), then most likely, you just had your fees too low to get a good enough position in the queue. Folks with their ticket fees set higher, will have bought all the available slots during that price period, as miners will pick their ticket buys 1st.

When your tickets get mined (at least one confirmation), they'll move from ownmempooltix, into immature, and given enough confirmations, they finally move to live. If they don't get mined until the next ticket price swing, then the transaction is dropped from the mempool and your balance is returned (minor txfees).

There are cases where you might successfully buy tickets, yet they will not be showing up on the pool, notably, this will happen if you set your pool fees incorrectly (too low). In that case, the pool will not vote for you, unless the pool admin is notified and takes some manual intervention. In such instances however, you'd see your immature/live tickets going up, and your balance would only be returned after voting.

Cheers.

Transaction change that is returning to wallet a once it reaches enough confirmations.

All - mempool for everyone's tickets waiting to be mined/confirmed
Own - your own tickets on the mempool waiting to be mined/confirmed

What problem Slava_K ? Stratum seems to be responding just fine, I see new blocks coming through, shares accepted. The pool also found a block just 15 minutes ago, and miner payments have been coming through as well...   

If you trust the person providing the miner (which is me in this case), and/or if you have a "disposable" environment, meaning, a box where you can safely run the miner without risk of compromising any wallets/coins/data, then by all means run it and evaluate the behavior, to see if there's anything at all looking abnormal.

You'll need to add some exception/exclusion to your anti-malware software, otherwise I presume it will block and/or delete the miner before you get to do anything with it.

In any instance, take caution with posts being quoted, as this is a common practice used to replace the original download link with a malicious one!

Better yet, you can easily compile ccminer yourself, in which case you don't need to trust anyone, you can inspect the sources and verify them to be clean. IIRC, you really just need Visual Studio 2013 w/Cuda 6.5 or 7.5 to build it. I'll only add that you'll get the same false alarm regarding the trojan though 

On what grounds are you claiming that it is not a fake alarm? ...   
This binary has been used by other folks for nearly a year without any account of issues or malware at all.

I'll be happy to investigate if you have anything going beyond 'its not fake alarm'. Err... Not nice buddy. 

My only suggestions:
a) Either release it in the open, knowing you'll never get adequately rewarded for your work, or
b) Release it within a private group of folks you trust enough not to leak it, assuming the potential for donations if XCN is back in a profitable situation, or
c) Set a price and sales volume cap, such that by reaching the number of sales that you have set, you stop selling, and so you've sold to a limited group of people that will hopefully be smart enough not to leak it (they paid for it afterall), or
d) Don't sell it at all & don't publish it either. You'll be in a position to mine it yourself at better profits than most, however small the earnings might be. No fuss, no customer support to deal with! 

Personally, I have no interest in the coin, as I was around since its early days, and saw it being too neglected for my taste, only to come back in full pump and dump swing for no reason. I'll rather keep my distance, as money is not everything. I'll anyhow be happy to donate for your work in other areas Pallas, just not this particular one.

Just my 2 cents Pallas. Not meant as judgement or critic in any way, just how I read it...

My Windows build environment is fine again, can compile just about any ccminer fork I tried, setup with VS2013 and Cuda 7.5.
I still can't get past the multitude of issues while trying to compile this one. Will have to put it on hold until further notice, next few days I have no chance of spending any time on it, and even if I had all the time in the world, it looks to be more than I can handle... 

My 1080's do 340+ MH/s with TDP @ 85% (~150w) with the open source version.
Without stating the clocks and/or power usage, 384 MH/s doesn't tell much at all...

sp_ : you do realize that a lot more people would be using your miner (thus more fees for you to earn), if you were not charging upfront as well, right? Not saying that one thing is better over another, but really, if you look at Claymore's example, it's quite obvious that he's got good earnings  from his miner fees.

@pallas: My build environment is broken, so no Win build from me at the moment. I do plan on fixing the damn thing, will just take me a couple days or so to get to it... From long ago, I recall some complications with MPIR being a dependency for Windows specifically, though it might no longer be needed? Once I can fix my build environment, I'll have a go at this.

Yep. As they say ... sell low ... buy hi... no, no, wait a minute!!! 

Nice. Thank you for the details there @bathrobehero.

I'm a bit more focused on efficiency than raw hashrate, as my electricity cost is at €0.20 kWh, as well as many times I am mining at loss (or rather, not strictly mining for a BTC output, or mining for low key hoarding).

But the other thing I would highlight, especially with the larger cards (1070/80, 970/80), is that sometimes, and only to moderate extent, you might lower your power usage without any loss of hashrate. This is a function of operating temperature, clock & voltage controls.

The default clocks for my cards (factory OC'ed), achieve roughly ~340 MH/s @ 180W, with the cards running in the range of 70°C.
I can't overclock them much at this range, without hitting temperature and/or TDP throttling. A little increase is possible, but marginal, and with a good deal of power usage increase.

My tweaked settings run at the factory OC, then +140 clock, -1000 memclock, and 85% TDP, which comes out a temperature of 65°C (fan settings unchanged).
The hashrate stands exactly the same as the factory settings, yet my power usage is down by at least 15%.

Obviously results will vary across different cards, vendors, power circuits, ASIC quality, etc. But the gist of it is, that most times, for any given absolute max hashrate at default settings, you can usually get away with better settings to produce the same hashrate at lesser power usage.
I haven't ventured in similar testing for memory intensive algorithms though, I only ever tweaked to any meaningful extent on compute heavy algorithms.

In your case, the 1070 G1 with +50 Mhz OC at 100% Power limit. Would probably be perfectly stable with a tighter power limit, lowered memory clock, and higher core clock - again - producing the same hashrate, but with lesser power usage. It's not something that would interest everyone though... Things will quickly get messy as one changes from algo to algo, with the cards behaving quite differently from one to the other, and sometimes requiring significant reconfiguration.

Enough mining chatter, weekend here I go! Cheers 

Wrong thread to post about this?
I've pinged Epsylon3 anyhow, he should check it shortly...

Edit: Folks still mining LBRY, would you care to post your efficiency ratings for whatever GPUs you have? I've tweaked for a bit, and wondering if I should waste any more time chasing improvements. My stats: GTX 1080 @ ~340MH/s & 150W, so roughly 2.27 MH/W. I wonder also how the AMDs compare, but that's really just curiosity, I have none of those.

The power usage is as reported by the Nvidia driver. I'm wired up with a reasonably good UPS, which is actually reporting lower power numbers (after accounting for the rest of the PC components), and it includes any PSU efficiency losses, so, go figure... I know I have a wall monitor somewhere around here, so when I find the bugger, I'll have that as well to better confirm the effective power usage.

Happy Mining!

Seems to be working fine just now. Have you tried again?
If still not working, it'll help if you post some more details as to what error/trouble you have.