Topic: [ANN] profit switching auto-exchanging pool - www.middlecoin.com - page 468. (Read 829908 times)

Good points there but don't forget the order book needs to be quite a bit more substantial to support a pool of middlecoins size. It's no issue with the more established coins of course.

Books are much less a factor for a single operator running cgwatcher+autosell.

Using autosell can present its own issues though. Occasionally Cryptsy has issues receiving/crediting deposits in a timely manner. This can cause a backlog to build up and if/when they all hit the market at near the same time it can have a temporary effect on some coins valuations. I learned this the hard way using autosell with cryptsy when I mined on multipool. This was before Cryptsy offered the autosell service.

I like Cryptsy and think it's great that they have enabled an autosell feature however I would be leery of using it unless they introduce an option to autosell at lowest ask price in addition to highest bid. My .02 anyway.

Great job today H20, another nice payout!

Hey, the pool is over 1 gh/s now! Congrats h2odysee, and everyone

And a thought about the cgwatcher+auto-sell-option on cryptsy suggestion:

Most pools these days are PPLNS. Switching coins/pools all over the place seems like it would kinda kill efficiency based on that payout model.

Of course, we are switching coins all over the place mining here, but I am assuming since we are all switching together as one pool, we are not shooting ourselves in the foot in that way....?

Whooo-hoo!   A great day mining on this pool AND no more talk about difficulty!   Win-Win!

CLAP CLAP CLAP

Seems a pretty decent run today

992.2232 .. oooh just one more refresh

i think we have reached the 1 GH now.

Thanks for letting me know, glad it's doing the job 

your addy is showing and hash rate for last hour is on its way up so looks OK for starters.

Hello,

I need some help please.

I have pointed 3 cards at this pool total of 1400kh/s, but I am not so sure if I am mining anything or not.

I see accepted OCL 0 or 1 or 2 but the diff always shows 0/0 is that normal?

Can the pool owner verify for me I am mining - username -1Afv29gzpRE1YaqiymCNYDdPedHWTkht99

Any info much appreciated guys.

So anyway .. I got one of my cards back from RMA replacement today and middlecoin seems to be going pretty well
gogo 7970s

THANK GOD... 

I've made a new thread: https://bitcointalk.org/index.php?topic=279644.new#new

No more difficulty discussions here.

Could u guys plz make a thread with this difficulty thing? i cant read it anymore.

plz.

its interesting, but its worth an own thread.

i am happy to not checking all the pools everyday if they working right.

You are absolutely correct, that they are not between 0.5 and 1.5. But if i did between 0.25, and 1.75, 0.1 and 1.9, etc i'd get the same results long-term. And so on and so forth.

Accounting for the infinite right edge would be very, very difficult (not impossible) to simulate. In the end, it doesn't matter... because if I did, all that would do would shift the average somewhat to the right. But, the same thing would happen to the block time as well. They cancel each other out. At that point I am dealing with a different average. It doesn't matter what the average is that you use, the effect will still be there.

I am sure someone smarter than me can replace that small part of the code with a formula to simulate the real range. Its beyond my math knowledge. But know I am aware it is a flaw. I am almost certain the result would be very very similar if you did simulate that. I will attempt to do some research and see if I can figure it out. If i can, I'll re-run the simulations and see what happens. If anyone knows the right distribution for this, I can certainly convert it to python. H20 might be onto something about the inverse square distribution.

Again, I am picking arbitrary numbers to be the average. It doesn't matter what I pick. the point is the relationship between the two workers.

The block find time, and the share find time of the miner are going to be equally effected by any changes to the calculation of the times.

But I think easier said than done..  I don’t mind paying the 3% to NOT have to manage all that myself..  But then again, I am lazy that way..     

Sooo... how long can you guys go on talking about this?

My intuition is that mixing blockchains is only a problem if you're using the --load-balance option. But I don't really know. If anyone has success with a backup pool, and knows for sure that it doesn't cause extra "detected new block" for the primary pool, let us know.

Thanks liquidfire, for your simulation. Good idea. It's the next best thing to me actually making the change in my pool, to test it out.

There is a problem with it though. Block solve times, and share solve times, are not between 0.5 and 1.5 of their average. Nor are they uniformly distributed. They are between 0 and infinity, and some kind of inverse square distribution maybe.

I believe that bug is what's producing your results, showing that slow miners are disadvantaged. Because if a share cannot be solved in 0.5, and a block comes before then, then his work is wasted.