It would most certainly not imply that a solo mining pool is a fraud. I'm not sure how you drew that conclusion from this discussion. Is it likely that I will solo mine a block of BTC? Nope. Is it likely I will win the powerball on Wednesday? Nope. Doesn't mean I won't pick up a ticket for a couple bucks and try anyway.
EDIT: It is not a combined effort of shares that solve a block. It is a SINGLE share that does it. Each time you're attempting to find the solution, it either works or it doesn't. Flip a coin. Either it lands on heads or it lands on tails. It can't land on both at the same time. Each flip of that coin has absolutely no relation to the flips before it, or the flips that come after it.
I hear you. Like I said, I'll continue with my reading up on pool mining and bitcoin in general. In the meantime, I'll leave my entire 14GH pointed firmly to the solo mining pool. PS. In my part of the world, though the lottery jackpot is not always won at each draw, there are always winners in each draw. |
|
|
|
Is not possible to implement, as the puzzle you are solving includes the definition of who gets paid.
You can either solve a problem that involves paying yourself all of the block reward, or you can solve a problem that involves paying the pool the block reward.
It is impossible to solve both problems simultaneously.
The question was clarified in my latter posts, and you have not caught up yet. |
|
|
|
I think I found your confusion. There is no such thing as "the pool wins the block". Either miner 1 or miner 2 had to have solved the block. Your scenario 1 is in reality your scenario 2, minus that "pool wins the block" stuff. If both miner 1 and miner 2 are mining with equal hashing power and equally submitting shares, then they've each contributed exactly half the work necessary to solve the block. Therefore, they're each going to get 12.5BTC.
So basically what you are saying is that it is only possible for a single hasher to solve a block if it is just their shares that solve the entire block. That would imply that a solo mining pool is a fraud as this will NEVER realistically happen with the hashing power in the hands of home miners. |
|
|
|
Let me give you a scenario. I go and create this type of pool, and have 2 miners connected to it. After a while the first block is found by miner 1. Both miners have been submitting work equally. I have 25BTC to give out. Who gets it? If I pay miner 1 the full 25BTC for finding the block, I don't have anything left to pay miner 2. If I pay both miner 1 and miner 2 for the work they've done, I don't have the 25BTC to give to miner 1 for finding the block. Make sense?
Just to tweak your scenario to suit my utopia. 2 miners connected, hashing equally. Scenario 1: Miner 1 finds the block - Miner 1 gets 25 BTC less the mining fees attributed to Miner 2's work which Miner 2 gets Scenario 2: the pool wins the block - Each miner gets 12.5 BTC including (or in addition to) the mining fees attributed to their work submissions |
|
|
|
I won't continue, since there are a number of threads dedicated to explaining payout schemes, but I will conclude with this: nobody is going to create a pool that rewards the full 25BTC to the miner who finds the block, and also rewards every other miner for the work they've done.
i appreciate your time in explaining and will do some digging to satisfy my ignorance, suffice to say, the crux of my ignorance seems to lie squarely in the manner in which a pool dishes out work. So I have a clean session of google to embark on my research. thanks again for the time. |
|
|
|
In a normal pool, when a block is found, the reward for that block is distributed to all the users who contributed work to the pool.
When solo mining, the solo miner takes the whole block reward for himself.
You cannot simultaneously give all 25 BTC to the miner that found it AND divide it up among everyone who is hashing on the pool.
I am sure the questionis being lost here, unless I am mistaken and your response is not intended for me. My query was to the contrary, i.e a pool in which if a person found the block, then he'd get the reward (not share it), but for the blocks won by the pool shared throughout, aka a pool that offers solo mining in and pool mining. |
|
|
|
You're asking if work can be submitted twice. It can't. Think about it. If something like this could be implemented, then I could take my hashing power and multiply it by connecting to multiple pools. So, in pool 1, I have 1TH/s, and pool 2 I have that same 1TH/s, and in pool N I have my 1TH/s, effectively giving me N TH/s mining, when I only have a single terra hash of hardware. So, to answer your question, no, that kind of pool is not technically feasible to implement.
P2Pool does nothing of the sort. P2Pool has its own block chain called the share chain. Each share that is added to the chain either solves the BTC block or it does not. If it does, the generation transaction includes the payouts to all the miners who have shares on the chain. If it does not solve the block, it is just added to the share chain.
I think you got closest to what I was asking, but not quite. I did not mean to ask " if work can be submitted twice" as you say. When mining directly / solo mining, I assume you still get rewarded for solving part of the chain, however, most solo mining nodes (including this one) do not relay those minute rewards (if any), only IF you solve the entire block. So that was the crust of my question, can a solo mining pool be set up whereby rather than (realistically) mining for nothing short of hitting the jackpot, the mining can be rewarded however lowly? Thanks for explaining, and I am sure I am missing something that is obvious to yourself (but ofcourse very foreign to me!). |
|
|
|
Hi
can someone help with this?
I have pointed 4 of my Ants S3 to solo pool and get lot of discarted shares.
For example:
GetWorks 15
Accepted 79
Rejected 1
Discarded 2342
and best share is also very low afer few minutes.
When I point this miners for example to Slush I get:
GetWorks 19922
Accepted 152451
Rejected 337
Discarded 1934111
And best share is > 1 000 0000 after few minutes.
In solo pool is ratio Accepted / Discarded much bigger.
Thanks
Like it has been mentioned, the discarded number is due to the S3's high queue (I think it is 1046), but I am meant to believe does NOT affect your mining. you can change this to a lower number to get less discards. This particular solo pool, I have noticed, takes a while to "settle" down to your appropriate hashing speed to assign a relevant Diff, so a few minutes is not long enough to reach conclusions. |
|
|
|
Heads up guys, if you update your CGMiner beyond what it comes with, bitmain will deny you any future RMA
Source: They denied several of my S1s back in the day when I applied Kano's fix.
I have a few S3's from batch 6 and 7 and several S1's from loads of sources. If one of them went, knowing that I overclock each, I do not expect bitmain to take responsibility and give me a voucher. I value my machines but I have never known anything that depreciates so fast in value as a bitcoin mining rig, for that reason, I do not have any sentimental attachement to my rigs. Matter of fact, I keep them outside, though well sheltered from the elements. I have not updated any firmware but I knew that any cgminer from the author would improve on what shipped with the S3 (and thus far, I think I have more reason than not to update all my S3's, infact i have!). If you want to hold back updating cgminer in the anticipation of an RMA claim, that is your choice! |
|
|
|
Have you tried increasing the freq over 250 since changing? - Looks like extra CPU might equal more work into the asics. I am not sure how or where the file is not with the new bios, that you can set from interface. Anyone know where to edit that file?
TIA
I have one S3 running at 262.5 for the last 5hrs+ and like I mentioned before in this thread, it looks like my pool-side hash rate is higher than usual, so I would nod to the assumption that less load MAY equate to more work into the asics (and more efficient submission thus less rejects!). I'll have to come up with a more meaningful assumption after I've run for over 24+ hrs. |
|
|
|
How exactly would the "pool" get paid? All of the coins from the block go to whoever finds it. If you take coins from that person, it just becomes another pool.
Come off it! How does this solo pool get paid? If you find the block, then you get 99.95% of the 25 BTC it is worth, the rest to the pool. In the same breath I'd add, the "normal" pool mining would say incur a flat rate for paying out to your address (not rocket science, but the pool gets paid then!) But I digress, the question was is that kind of pool technically feasible to implement (or am I barking mad because that is what P2Pool is)? |
|
|
|
Thankfully, this is impossible. Pools send out work that pay to their own addresses and there's no way of changing that. Even if there was a way of doing it, any pool that you do it to has every right to ban you because you would be stealing from them.
You miss the point completely. I was insinuating to the technical feasibility of implementing a pool that would offer both solo-mining AND pool mining (if that makes sense), thus the issue of being banned by the pool would not arise. So the question still stands, is it technically feasible to implement one? by the way, from the small miner's point of view, this will just ensure that all mining is at least rewarded. I play the lottery every week, but that does not mean I have to give up the day job! |
|
|
|
what exactly is 4.6
firmware or something else.:?/
Latest version of cgminer for the S3 |
|
|
|
|
Just wondering, can we not have the best of both worlds by solo-mining AND submiting to a pool at the same time?
I am thinking along the lines of having a mining proxy opening connections (chats) and first submiting to the solo-minig chat then to the pool such that if you "discover" a block, you win it with the intial submission and though you go ahead and submit the same share to the pool, it is of no effect.
Would this require a special implementation of the pool and what does it take to mine directly rather than through a solo mining pool such as this one?
|
|
|
|
....
Just a question, would this cgminer run on an S1 (like to earlier Kano cgminer)?
No, it doesn't work on S1. I tried it and it's not hashing. Thats that then. Come to think of it, it even resided in the S3 directory (which should have given the game away for me!) Thanks for placing your S1 in harm's way to clear this up. |
|
|
|
Could you report hash difference (if any) after 24hr?
I sure will (and that is why I said " still early days ...". |
|
|
|
I also noticed the load average is way lower on the CPU now that it was. was always above 2 before. now hovers around 1.2. any additional benefit to these devices to run with lower/higher loads?
That's likely the advantage of the newer version. In principle it will lead to less lag time in keeping the device busy and less time to process and send shares. However cgminer is so heavily multithreaded that it probably won't matter since the latency critical parts of the cgminer code are already prioritised. Still early days since I updated my S3 with the latest cgminer (3 hrs+) but I have noticed an improvement in the pool-side reported hashrate AND I suspect a reduced DiffR. This is on top of a faster UI (which I attribute to the lower load average). Just a question, would this cgminer run on an S1 (like to earlier Kano cgminer)? |
|
|
|
seemed to work to get it there but the permissions are wrong. sorry my nix is rusty. any help?
Tried to follow the same steps, but it doesn't seem to start hashing - the status page parameters remain empty. I reinstated the original cgminer and it is hashing now. Cheers Perhaps chmod 755 cgminer would help? Can you try running cgminer manually from the command line? Here's what I've used and it started hashing as usual. 1. SSH into the S3 and login 2. Issue the following commands sequentially. a) cd /usr/bin b) mv cgminer cgminer.bak c) wget http://ck.kolivas.org/apps/cgminer/antminer/s3/4.6.0-140908/cgminer d) chmod +x cgminer e) reboot |
|
|
|
Thanks for the heads-up. I'll download onto my overclocked S3 and report back here (and there!). UPDATE: Got the latest cgminer installed on the overclocked S3 and it is hashing away nicely. Will update after its been running for a while. To get it, I did this: 1. SSH into the S3 and login 2. Issue the following commands sequentially. a) cd /usr/bin b) mv cgminer cgminer.bak c) wget http://ck.kolivas.org/apps/cgminer/antminer/s3/4.6.0-140908/cgminer d) chmod +x cgminer e) reboot |
|
|
|
what firmwere do you use in the s3
The original firmware (i.e without the advanced tab settings). I have never had any issues with the unit so I did not think it wise to update the firmware. I am waiting on an "opensource" cgminer for the S3 if ever that pops up and may try that out, other than that, IF IT AIN'T BROKE, DON'T FIX IT! I think units from batch 6 upwards are quite solid for overclocking, though some earlier batches could also be. |
|
|
|
|
Show Posts
