Please add EXECoin to BTER!  Along side VTC, EXE is positioned to absorb the mining community that will be left stranded when scrypt ASICs come out en mass.  Thanks to its nscrypt implementation, EXEcoin is likely to see significant adoption and uptake in the following months as GPU miners search for a new algorithm to call home.

If someone wants to buy a large chunk of EXECoin from me, say at 4200sat, I will put all the BTC back up as a buy order.  PM me if interested.  Plus, there's no way to buy this much EXECoin at market unless you want to pay crazy prices.

The halving is already built into the current price....  when are people going to figure out that the markets react to predictable events BEFORE the event...

Probably clevermining.

Wafflepool is WTjhV634jGnEWMKdRVorNooHgbLCnseSYq

This an open source project - all of the code and data is publicly available.  Anyone or any group could takeover the project and even hardfork it if there is enough support from miners and community.

Whitecoin isn't hidden anymore.

Litecoin is obviously going to be the dominant scrypt network, just as bitcoin is the dominant sha network.  Litecoin simply maintains too much of the hash power and marketcap already, that there's little chance of it being unseated.  And when massive hashing power from ASICs come around, small coins with pitiful network hashrates will get attacked left/right/center similar to SHA altcoin destruction. I think we will be comparing profit vs litecoin for a long time to come.

Looks like profitability algorithms coming to the same conclusion.

Curious that one of the block change notifications was several seconds faster on one pool - they must have been the ones to find the previous block, I suppose.

Let's make the buy wall at 3650 the floor!  If you believe in EXE, then throw even a .1BTC buy order up at 3650.  A few BTC stacked close on the buy side is what this coin needs to keep the network power up and this coin strong.

Heh, looks like the RON network is over 1MH/s again.  The random rewards from solo-mining RON with an old CPU have been fun.

The great dev team is definitely one of EXECoin's big advatages.  With scrypt ASICs coming en mass this year, it is going to be a very interesting time for EXE and other alternative algorithm coins.

If you are a crypto speculator, holding EXE just makes sense - and at these prices, it's a great time to buy in.

Nice to see nscrypt buyers picking up a bit.  Interesting opportunities there.

I do rather like idea of being able to auto-trade everything to LTC or some other coin at times.  But, keeping back coins from auto-trade is more.important I think.  If I am long on LTC, it makes little sense to trade mined LTC to BTC.

---

Bbbbbb2014: PoolWaffle's logic is sound. A sunk cost is a sunk cost.  Knowing the expected value is irrelevent.  You either auto-trade them when you can, or you speculate that given coin will go up and you stay long.

That said, I have always wanted to see some luck and expected profitability stats.  Expected profitability + luck + exchange variance data would all excite the nerd in me, heh.

Starting to build some solid buy orders again. Great to see.  Looks like thr price has likely bottomed, now hopefully we can attract some additional mining power.

Lol. I haven't been mentioning the pool by name in this thread because I am avoiding advertising for another pool in this thread... I thought I was showing some forum etiquite. (Nor have you messaged me and asked for more info)

I have observed this behavior on startup, btw.  When there wasn't an unlimited order above the p= setting, and higher orders were full, I was able to restart multiple times and observe the issue. I can try to sniff the traffic from a rig if you need. I have a solution that has been working fine for my rigs, so honestly this isn't even personally relevant.  I have made some solid profits on over 2BTC of hashing power I have purchased from here as well.  I have been more hopeful that my suggestion might bring increased power to nicehash.

Anyway, I have been trying to be helpful. I will happily leave this thread and pool if you don't want me to share my knowledge.

Buyer or a provider?

As a buyer, you are in complete control of what is being mined.

As a provider, you get work and are paid in BTC. It is completely out of your hands what you are mining (you might even be creating private chains, attacking a blockchain, etc).

The buffering I am talking about is very key. Yes, it has been done before. And you are correct that a reconnect is neccesary to change extranonce1 and possibly extranonce2_size.  Having work buffered on the server ready for the miner before you force a reconnect and update the on-connect nonce params allows you to instantly provide work when the miner reconnects, essentially eliminating switch downtime.

As for the problem with idle miners - I have not observed failed auths in these cases. I see the pool accepting the auth request with p=, but not being able to provide work. This seems to occur when there are jobs at the desired profitability, but those jobs are already maxed on miner (no slots available). The pool keeps the connection open and allows the auth innappropriately.  If I set p high enough that no jobs are available (full or not),  this doesn't happen.

Don't know what you meant about slush's proxy. The pool I am talking about has a fully custom stratum implementation and can proxy traffic at will. The miner sees only the interupted message and mining barely hiccups.

My patch is hacky and I don't plan to publish it. Besides, right now it is giving me an advantage... why would I share when you have made this system competitive instead of fair/proportional?

I also still don't think the idle issue is a cgminer bug.  The addition of stratum commands to change the extranonce params that are limited to on-connect right now would be valuable, however.  Stratum is dying for a few extension like this, as well as for pool provided algorithm and nfactor.

By buffering the next job's work before disconnecting the miner for a switch, you can get switch time down to a fraction of a second, and the risk of lost work is no worse then stales (and if you accept shares after a re-connect, then it's less).  In fact, a famous multi-pool has implemented just this so that when they proxy work to other pools, all you see is "Stratum connection to __ interrupted," and mining never skips a beat. Your post, therefore, seems an unacceptable reason for the poorly designed switching system that so far nicehash has implemented.  The current system isn't fair for providers or miners.  As a miner, I have to abuse the system to get the best rewards (constantly check if there is new work at higher pay, and reconnect whenever there is).  As a provider, there's no solid reasoning behind what bids will garner what hashrate.  I have had 1BTC unlimited rate orders and still watched someone with a 1BTC/GH lower bid continue to have a higher hashrate then my order for the following hour!  (That means over half the pool's buyers were earning less then they could have been, by a margin of over 10%). Not to mention, when bids are getting bumped around, the system will sometimes drop almost all the miners from my job, moving them up a job, and re-assign other miners to my job.  That's just flat out inefficient, and causes hashrate luls for both providers and buyers much worse then faster and appropriate switching would.

I am also not buying your guy's excuse that the idle miners are a problem with sgminer/cgminer.  Yes, you can fix it by patching sgminer...  but, your system is accepting stratum auth for miners that it should not - it accepts connections when there are jobs open but no work available.  That's a logic problem in nicehash, not in sgminer.

---

As for paying based on averages - your stats on the main page seem to show the current average BTC/GH/day rate... this is the rate that all miners should be paid, if you want a fair system.  Round robin is not working.  If you want to minimize switching, then average payment to miners is the only thing that makes sense (because then switching is irrelevant).  Just make sure you take into account reject rates per jobs vs per user when calculating proportional earnings if you want a fair system.

And don't count BTC - count shares, and then compute BTC periodically (say every 5 minutes for the previous 5 minute window) instead of on a PPS basis.  You don't have to worry about round hopping because found blocks aren't directly relevant here, so there is no reason not to use a proportional system based on short rounds.

BTC only.

Looks like a small floor wall is starting to form.  Best bet your orders in now - it looks like the price is heading up this week.

Pretty much.

Lol... you are so full of *$%@.  Your entire posting history is just shitting on this coin to try to drop the price =p.

Your account was created purely to troll in this thread.