How frequently your script change the mining coin? (Every what minute/second?)
In the past day, on average every 6.5 minutes.
Topic: [ANN] profit switching auto-exchanging pool - www.middlecoin.com - page 519. (Read 829908 times)
July 26, 2013, 09:26:52 AM
In the past day, on average every 6.5 minutes.
July 26, 2013, 09:22:40 AM
The pool now supports NVC.
That's great news, it should increase the profitability of pool.
just a question: How frequently your script change the mining coin? (Every what minute/second?)
July 26, 2013, 06:47:14 AM
The pool now supports NVC.
July 26, 2013, 06:31:25 AM
Happy to help. 
July 26, 2013, 06:26:49 AM
It worked!!
Thank you so much Balthazar. I would have been stuck on this forever, and I was not about to test it out outside of testnet.
Thank you so much Balthazar. I would have been stuck on this forever, and I was not about to test it out outside of testnet.
July 26, 2013, 06:24:11 AM
You should specify your local public key to get it working. Use getnewpubkey RPC to get it and specify it as the value for CENTRAL_WALLET variable.
[/quote]
If I do that, I get this:
Coinbase address '03efb8b9b0802d8cd34055b54e16735acbb79937ba7822f2af2af0e98fca82a926' is NOT valid!
I'll try another stratum-mining branch.
[/quote]
If I do that, I get this:
Coinbase address '03efb8b9b0802d8cd34055b54e16735acbb79937ba7822f2af2af0e98fca82a926' is NOT valid!
I'll try another stratum-mining branch.
July 26, 2013, 06:21:43 AM
It's a block height serialization bug in StratumServer code, which appears on short BIP34 chains only (shorter than 254 blocks). You should mine 254 blocks for testnet chain before StratumServer will be able to function on testnet.
I thought about fixing this problem, but it's not a critical issue because it will never appear in the real life.
I thought about fixing this problem, but it's not a critical issue because it will never appear in the real life.
That didn't help. I mined 300 blocks, but still have the same issue.
I get this in my novacoin testnet debug.log:
ThreadRPCServer method=submitblock
Sign failed
July 26, 2013, 06:14:41 AM
i think your pool has great potential. u have to invest in new servers (eu too) and lower diff are do vardiff.
July 26, 2013, 06:10:37 AM
It's a block height serialization bug in StratumServer code, which appears on short BIP34 chains only (shorter than 254 blocks). You should mine 254 blocks for testnet chain before StratumServer will be able to function on testnet.
I thought about fixing this problem, but it's not a critical issue because it will never appear in the real life.
I thought about fixing this problem, but it's not a critical issue because it will never appear in the real life.
That didn't help. I mined 300 blocks, but still have the same issue.
I get this in my novacoin testnet debug.log:
ThreadRPCServer method=submitblock
Sign failed
July 26, 2013, 05:55:51 AM
why dont you include LTC, FTC, or NVC? despite of their profitability, there are many tools to start their pool easily
I have FTC and LTC. I've been trying to get NVC to work, but when testing on testnet, all the blocks I mine show up as REJECTED in the pool.
I'll update the FAQ.
I thought about fixing this problem, but it's not a critical issue because it will never appear in the real life.
July 26, 2013, 05:33:06 AM
Okay, but assuming you do not find a valid share in the 512-diff share pack. Then what I said is the case, correct?
There's really no such thing as a 512-diff share pack.
512 is just factored into the probability that your hashes will produce valid shares.
I guess you can think of a 512-diff share pack as the average length of time it will take your miner to find a share using a difficulty of 512. But there are no discrete work chunks like that. Unless you count the cgminer worksize, which is completely different.
July 26, 2013, 05:28:46 AM
No, the work isn't dropped.
The way it works is your miner is hashing numbers, and if the resultant hash is less than a certain number called the target, it is a valid share.
The target is calculated something like 65536*65536 / difficulty. So the higher the difficulty, the more improbable your hashes have to be, to be considered shares.
Edit: So if while you are 386 hashes in, right after a new block, and you find a valid share, you submit it right then. You don't wait until you finish 512-difficulty worth of shares.
The way it works is your miner is hashing numbers, and if the resultant hash is less than a certain number called the target, it is a valid share.
The target is calculated something like 65536*65536 / difficulty. So the higher the difficulty, the more improbable your hashes have to be, to be considered shares.
Edit: So if while you are 386 hashes in, right after a new block, and you find a valid share, you submit it right then. You don't wait until you finish 512-difficulty worth of shares.
Okay, but assuming you do not find a valid share in the 512-diff share pack. Then what I said is the case, correct?
July 26, 2013, 05:15:43 AM
But if you're working on a 512-diff share and a new block comes when you've only completed e.g. 386 hashes, basically all of that work is now invalid and dropped.
No, the work isn't dropped.
The way it works is your miner is hashing numbers, and if the resultant hash is less than a certain number called the target, it is a valid share.
The target is calculated something like 65536*65536 / difficulty. So the higher the difficulty, the more improbable your hashes have to be, to be considered shares.
Edit: So if while you are 386 hashes in, right after a new block, and you find a valid share, you submit it right then. You don't wait until you finish 512-difficulty worth of shares.
July 26, 2013, 05:09:18 AM
Am I correct in understanding that once a new block is found, all previously worked on shares become invalid? And that 512-diff shares are just 512 1-diff shares strung together?
Then the thing is, if the average time you are working on a share is larger than the rate of blocks being added to the blockchain, you will get a lot more rejects, since 512-diff shares greatly reduce the variance in share time.
Then the thing is, if the average time you are working on a share is larger than the rate of blocks being added to the blockchain, you will get a lot more rejects, since 512-diff shares greatly reduce the variance in share time.
The way I understand it, that is incorrect.
When a new block is found, all previous worked on shares do not become invalid unless they didn't make it to the network in time, in which case they either became stale (cgminer rejected it), rejected (my pool rejected it) or orphaned (the network rejected it).
Well the fact that 'they didn't make it to the network in time' is exactly what I'm getting at. Obviously, previously submitted shares stay valid. But if you're working on a 512-diff share and a new block comes when you've only completed e.g. 386 hashes, basically all of that work is now invalid and dropped.
I'm guessing your choice of difficulty is to reduce overhead and therefore load on your server? If so, I think it would be better to just invest in a better server and up the fee to adjust for costs.
July 26, 2013, 05:09:01 AM
I'v got my first payment, Horayyyyy 
July 26, 2013, 04:48:35 AM
Am I correct in understanding that once a new block is found, all previously worked on shares become invalid? And that 512-diff shares are just 512 1-diff shares strung together?
Then the thing is, if the average time you are working on a share is larger than the rate of blocks being added to the blockchain, you will get a lot more rejects, since 512-diff shares greatly reduce the variance in share time.
Then the thing is, if the average time you are working on a share is larger than the rate of blocks being added to the blockchain, you will get a lot more rejects, since 512-diff shares greatly reduce the variance in share time.
The way I understand it, that is incorrect.
When a new block is found, all previous worked on shares do not become invalid unless they didn't make it to the network in time, in which case they either became stale (cgminer rejected it), rejected (my pool rejected it) or orphaned (the network rejected it).
July 26, 2013, 04:00:31 AM
Code:
block boundary (||)
(A) [64][64][64][64][64||][64][64][64][64][64][64][64][64][64]||[ ...
(B) [---------------512||[---------------512-------------][ ...
(A) [64][64][64][64][64||][64][64][64][64][64][64][64][64][64]||[ ...
(B) [---------------512||[---------------512-------------][ ...
In this scenario, miner A would have 4 difficulty-64 shares submitted before the first block boundary, and one aborted. The miner using 512 difficulty shares has not finished one share yet and so he loses the equivalent of ~4.5 difficulty 64 shares when he restarts work.
Miner A is expected to have 4 shares, but may get less or more, in some kind of distribution around that. Miner B is expected to get 0.5 shares on average. They work out to the same thing. The work isn't in discrete blocks like that. It's a probability.
Am I correct in understanding that once a new block is found, all previously worked on shares become invalid? And that 512-diff shares are just 512 1-diff shares strung together?
Then the thing is, if the average time you are working on a share is larger than the rate of blocks being added to the blockchain, you will get a lot more rejects, since 512-diff shares greatly reduce the variance in share time.
July 26, 2013, 03:46:55 AM
this is what im taking about...........
its not like there slow cards either
its not like there slow cards either
July 26, 2013, 02:41:31 AM
Chucked a couple 7970's on there for a few hours the other day, got paid nothing.
Have you checked on middlecoin.com whether any shares were received for the BTC-address you used and whether you passed the 0.01 BTC threshold for payment? July 26, 2013, 02:21:15 AM
Chucked a couple 7970's on there for a few hours the other day, got paid nothing.
Jump to: