Hi wizkid057, I read through your explanation and was wondering if you would mind providing a bit more detail on the following statement you made: New method allows a small bandwidth spike to get all miners on the new block, followed by a staggered updating of full work and coinbase on miners spread over the next several seconds.
If I am reading that correctly, you're sending out an empty block to your miners, getting them on the latest block as quickly as possible, and then sending out the full set of transactions and coinbase afterwards. My question is, what happens if a miner happens to find a block prior to receiving the latest work/coinbase? Thanks! |
|
|
|
I think you're missing the point here. Small time miners get small time payouts - no matter what you may wish to happen. You simply aren't going to get a bigger slice of the pie unless you get more hash. Let's say you do start some kind of pool with an upper limit on hashing power. So, you've got a pool with 10000 miners each having 100GH/s. Do you somehow think that you, as one of those 100GH/s users is somehow going to make more than you would as the same user on a pool that has 2 miners, one has 999.9TH/s and you, with 100GH/s? The simple answer is you are going to make the same.
You are hoping for the impossible.
I wrote on the other thread that I usually make 10 mBTC per 2 weeks on Eligius pool and 1 mBTC per 2 days on Antpool with 100 Gh/s hashrate. Those are roughly equal to 0.7 and 0.5 mBTC per day respectively. If I would mine together with all other 9,999 miners with the same 100 Gh/s, using this method I will definitely get 2.5 mBTC per day. And I will definitely get multiple of that per day as the pool hashrate is 1 Ph/s so it is likely to solve more blocks a day. If there would be only 2 miners with 999.9 Th/s and 100 Gh/s, I would have to wait for a few days until my shares value reach the minimum payout threshold while the other miner would get the most payout every day while I am waiting. This is clear to me that I will make very less than on the previous example. Could you please explain why this would not be the expected result, John (I hope you still have the patience of the Saint)? Ok... let me see if I can break this down for you in a way you'll be able to get  . For the sake of this argument, we're going to assume there are 2 pools. Pool 1 has 10,000 miners each with 100GH/s. Pool 2 has 2 miners, one with 999.9TH/s and the other with 100GH/s. We are also going to assume that each pool finds exactly 1 block a day, and the reward is exactly 25 BTC per block. When a block is found on pool 1, the pool must divide that 25 BTC into 10,000 parts. Therefore, each miner gets 0.0025 BTCWhen a block is found on pool 2, the pool must divide that 25 BTC into 2 parts. The miner with 999.9TH/s gets 24.9975 BTC. The miner with 100GH/s gets 0.0025 BTC. They are both equal. Payout thresholds are completely irrelevant. It doesn't matter how you break it down, 100GH/s expects to earn exactly the same coin on pool 1 and pool 2. |
|
|
|
|
I think you're missing the point here. Small time miners get small time payouts - no matter what you may wish to happen. You simply aren't going to get a bigger slice of the pie unless you get more hash. Let's say you do start some kind of pool with an upper limit on hashing power. So, you've got a pool with 10000 miners each having 100GH/s. Do you somehow think that you, as one of those 100GH/s users is somehow going to make more than you would as the same user on a pool that has 2 miners, one has 999.9TH/s and you, with 100GH/s? The simple answer is you are going to make the same.
You are hoping for the impossible.
|
|
|
|
Well, everyone can dream I suppose. I'm not really sure why the inability to set your minimum difficulty to 512 would have been a reason to quit a pool. I find it especially curious that the very reason for you leaving a pool is not even listed as a requirement for your dream one. Why do you want to attract pool hoppers? How would your pool provide an advantage to miners with low hash rates? I don't understand your payout scheme at all. Way too many weird things going on... The coinbase transaction of the miners' Bitcoin addresses will be updated each hour Huh? Makes zero sense. - The payout will be based on the total shares recorded on the previous hour
- The shares that have been paid out will be reset at the time the payout is being executed
- When the total shares of miners remain the same on previous 2 hours, they will be set as dormant miners
- The total share of each dormant miner will be deducted by 1% and they will be distributed to all active miners on the next hour as bonus share
Wait... first you state the payout is based on previous hour's shares. Alright, so you only count an hour's worth of mining? Weird... but fine. But wait, how then can I tell if a miner has been inactive for the previous 2 hours? If I'm paying and resetting every hour, then I have no way to know if somebody was dormant for the hour prior. |
|
|
|
Ok... now if we go back to my original statement, with Eligius, you can never, ever make more than that 0.064146152448BTC in those 12 weeks. On kano, you can make more than that, or you can make less. Kano's pool has, since inception, been running about 101% luck. That has no bearing on future luck - it is just a metric of past performance. However, it is a metric that shows had you been mining on Eligius for the past year and on kano for the past year, given identical hash rates on each pool, you would have made more on kano.
I have been mining on Kano's pool from 20/11/2015 until now or about 7 days and I have got only 1.5 mBTC in total from blocks 384498, 384724, 384805 and 385383. If I would have mined on Eligius, I would have made about 5 mBTC. On Antpool, I would have made about 4 mBTC. How would that be practically possible to make more BTC on Kano's pool than Eligius, even if I would mine on Kano's pool for a year? You mined for 7 days. What you're not getting here is that your shares on kano's pool are valid for 5N (N on his pool is the network difficulty). Even if you turned off your miners, you will continue to earn on the shares until they fall out of the 5N range. So, every block between now and when your last share falls away will net you some BTC. It's how PPLNS works. You have a "ramp up" and "ramp down" period. |
|
|
|
|
Well, it was tough to call this a scam at the beginning... the pool was running relatively smoothly... the operator was pretty active on the forums and was quick to respond to queries. It wasn't until I found the block and the pool went dark that the scam was exposed for what it was.
|
|
|
|
Thanks for the PM... I removed the signature. I guess I should have spent a bit more time researching the signature provider and the links in their ads. Hopefully nobody fell prey by clicking on it when I was advertising for them  . |
|
|
|
|
You're actually mining at this pool? I guess all the pages of this thread talking about how it doesn't pay... That the pool operator owes miners a ton of coins... You completely missed all of it? What's that old saying again... Something about leading a horse to water...
|
|
|
|
I just found this talk. I have 55th/s with a pool right now. Is there a chance that it would be more profitable for me to mine solo rather than with a pool? I currently make $3700 a month with an electric bill of $1000. Does solo provide a better income?
With this pool you either get all 25 coins or none at all. You might go for 6 months without any income... Or you might find 2 blocks this month and get 50. |
|
|
|
To some of the regular posters here, I'm curious about reaction to this https://bitcointalk.org/index.php?topic=441465.msg13062153#msg13062153If you don't want to follow the link, apparently 6 * Difficulty shares have been pointed at Eligius from Nicehash and not one block solve yet. Relevant here I think because many of us use Nice/Westhash to gamble. Plenty of people have found blocks here using NH/WH and MRR. I'm not sure what's going on over at Eligius... |
|
|
|
Oh, well now that you've managed to stabilize your rig we should expect to see the blocks rolling in any minute now. About damn time you got that sorted  . |
|
|
|
- is it better to wait if the Pool has the next block found
It makes no difference - is it better to rent 1 PH for 10h or 2 PH for 5h
It makes no difference - is it better to rent some big Rentals or many smal ons
It makes no difference - is it better i start the rental if the Pool has a high or a low hashrate at the moment
It makes no difference - on what for a day or night Time is it better to start
It makes no difference - if you have other good tip for me
Alas no. This should be carved in stone!! Deep thoughts by -ck. Where did I leave that hammer and chisel... |
|
|
|
LOL... ultimate goal is p2pool v2. Where have we heard that line of crap before? I've got a lot of "ultimate goals", too. If I state them, do they automatically become a reality? |
|
|
|
|
Wow, I think this is the most active this thread has been in months...
Any Antminer that has not been updated to use some version of mainline cgminer will not submit stale shares. This is bad, because those stale shares can be valid block solutions that p2pool would happily submit. Kano, where do you get the 95% number you've provided? Maybe you could provide a definition of a stale share and how cgminer determines if a share is stale as I'm sure people would find the information useful.
@notbatman, I don't think I'd go blaming the XT guys for the run of bad luck. And you're the second or third person in the past few days to talk about orphaned blocks. P2Pool has not had an orphaned block since January 7th of this year. Maybe other pools are having a string of orphans, but that is definitely not the case here.
@BlInK311, you can manually call getblocktemplate, pick a nonce and apply the SHA256 hash to the data. If you picked correctly, you put that hash into the block template and submit your block. Good luck! (Yes, I GROSSLY oversimplified that description).
|
|
|
|
I was kind of referring to you -ck when I made my statements above about simply translating from Python to C not solving the inherent problem of the pool. Sure, a node will be faster and more scalable... heck you'd probably even do something like using multiple threads ... but as you, me, and most everyone else has stated, the real problem is the variance. Throw 100PH/s on p2pool and see how the share difficulty skyrockets and nobody with under 500TH/s mining is going to have a prayer of getting a share on the chain with any regularity. Until that is solved, what's the point. By the way... what is your magic number? You state, "...it would cost you a fortune to pay me...". Define fortune . |
|
|
|
Good luck to you! There was another user who setup an S3 to solo mine and he hit a block about a month and a half into his experiment. I have an S3 that I use for solo mining, and a bunch of others that I use on p2pool. I also have a number of USB sticks that solo mine... now THAT's playing the lottery . Oh, and I occasionally gamble and rent a ton of hash hoping for a quick hit. Haven't found anything on my own yet, but have been part of a group that found a couple blocks earlier this year. I keep dreaming and every morning I check to see if 25 BTC has magically appeared in my wallet... Edit: the last time one of my personal miners hit a block was in early 2014. One of my S1s found a block for p2pool. |
|
|
|
|
blocktrail.com is my primary choice, but I also use blockchain.info and blokr.io. All 3 offer up useful info.
|
|
|
|
...but I think the centralized nature of our payout system is a bit of a turn off for some folks. I had hoped that my reputation and only having 1 week of earnings on the line would be enough to ease community concerns, but it appears that it is not.
I hear you. And yet, people have no problems throwing their hash at the most centralized pools out there (Ant, Discus, etc). It really strikes me as paradoxical. We want decentralization, but we will gladly centralize all of our mining power to get it. Oh well... I look forward to the stuff Nonnakip is doing. Keep on fighting the good fight . |
|
|
|
|
The point is, you can't look at such a small sample size and make any kind of useful determinations from it. For example, if you look at just the previous 2 blocks (as of this post), it took the network 20 minutes. So according to that, the total network hash rate is exactly on target for the current difficulty. However, if you had made the same comparison about an hour ago, you would have seen that the network found 2 blocks within seconds of each other, so the hash rate was astronomical. This is precisely why the network waits 2016 blocks to adjust... and even with that many blocks, it's still pretty much a SWAG.
|
|
|
|
I'm not sure, but why don't we raise funds for the development team that can do this (maybe it's a bad idea).
I think we should act more active rather than passively wait for volunteers.
This has also been discussed many times in the past, but finding a coder willing to step up (huge task) as well as people who are willing to donate has proven impossible unfortunately. I've read through this thread many times & it seems some users think that either there is no need for development because it's perfect already, or that it is some kind of crime to even think about it - so nothing happens & miners go elsewhere. **waits for torrent of abuse** I'm not sure this is the case. There are qualified developers who I have spoken with that are willing to work on P2Pool, and Forrest is still around, if there was a viable proposed solution I would certainly contribute. The real problem is solving P2Pool's scaleability challenges, and they are hard problems to solve that require inventing a solution. I've been waiting for almost 2 years to bump my head in the shower and come up with it, but not there yet  If 100 PH/s was pointed to P2Pool today most (if not all) of the existing miners would see a huge spike in variance, and a large reduction in payout. Share difficulty would skyrocket, and keeping a share on the chain would become very difficult for most of us. The share chain has a finite amount of space and there is a threshold to prevent dust payments that would not even constitute a transaction fee. You can only split the 25BTC reward so many ways in a decentralized trust-less environment, and smaller miners will always get squeezed out. I believe that the solution may lie with sidechains and micro payments where a miner could accrue shares in some type of trust-less sidechain that would be paid out in BTC once a given threshold amount is reached. This would allow us to increase the size of the share-chain while eliminating dust payouts from the generation transaction. This technology does not yet exist, but perhaps we are getting closer.... We actually had this discussion almost word for word previously . I'm right there with you... all I've gotten is a few lumps on the head from bumping it so many times. The idea of a side chain is interesting, but nobody's been able to come up with a way to implement it. OgNasty and Nonnakip have done the closest thing to a solution with their NastyPoP method (ckpool combined with p2pool). It's a decent workaround, but it's not ideal. I've been mining on it for a year now, and have my thread comparing the results of it to standard p2pool nodes. The biggest problem with their solution is that you lose the decentralized nature of p2pool. Of course, if they expanded their operations from just their two current nodes, so that anyone could operate their own NastyPoP node, then we'd have something workable. I definitely like what they've done, or I wouldn't have dedicated a year's worth of mining and time to them . |
|
|
|
|
Show Posts
