Alright, I've revised my opinion. It's no longer MLM/Pyramid.
It's simply pants on head retarded (and a pyramid scheme).
+1  |
|
|
|
|
I'd argue it's a pyramid, and not MLM. You aren't providing anything to those under you except the opportunity to pay you fees. You are required to pay your parent node's tax. No goods, no services, and the people on the top are the only ones to reap the benefits.
|
|
|
|
|
You give the definition of a pyramid scheme, then present your example, which exactly matches that definition.
Assume for a second that I decide to join this pool. When I join, I will automatically be "taxed" because I'll be placed under some user's node. I can then recruit two friends and tax them, thereby reaping the benefits. Oh, and whoever my parent node's owner will now benefit even more because my earned income is higher, meaning my taxes paid to him are also higher.
That is a pyramid scheme. The folks on the top get exceedingly rich on the backs of the folks under them.
If there is a way for a user to join your pool and not become part of this hierarchical structure, then you can state it isn't a pyramid scheme.
|
|
|
|
So I've been playing around with p2pool quite a bit, digging through code, modifying front end code to display things, etc. I've got a question that I hope people can help answer:
How do I get more information into the JSON queries?
For example, in the global_stats, I see something like this:
{"min_difficulty": 479474.8692329195, "pool_stale_prop": 0.1111111111111111, "pool_hash_rate": 136727809739777.47, "pool_nonstale_hash_rate": 121535830879802.19}
How would I add to that to get things like "expected_time_to_block", "last_block_found", "total_network_hashrate"?
Currently I've fudged the first two by hooking into p2pool.info directly to retrieve the data, but I'd like to have it come from the global_stats.
Thanks for the help!
You can also check the code I use in mpoolmonitor in github. I make use of p2pool stats extensively in there. M Thanks, I'll have a look. I'm not much of a windows programmer - I think the last time I touched an MS development environment was about 12 years ago, but I'll take a look through the code to see some examples of what you've done. |
|
|
|
So I've been playing around with p2pool quite a bit, digging through code, modifying front end code to display things, etc. I've got a question that I hope people can help answer:
How do I get more information into the JSON queries?
For example, in the global_stats, I see something like this:
{"min_difficulty": 479474.8692329195, "pool_stale_prop": 0.1111111111111111, "pool_hash_rate": 136727809739777.47, "pool_nonstale_hash_rate": 121535830879802.19}
How would I add to that to get things like "expected_time_to_block", "last_block_found", "total_network_hashrate"?
Currently I've fudged the first two by hooking into p2pool.info directly to retrieve the data, but I'd like to have it come from the global_stats.
Thanks for the help!
You can see an example of adding a miner_last_difficulties array, network_hashrate, and network_block_difficulty here: https://github.com/forrestv/p2pool/pull/191/filesMuch obliged! |
|
|
|
|
So I've been playing around with p2pool quite a bit, digging through code, modifying front end code to display things, etc. I've got a question that I hope people can help answer:
How do I get more information into the JSON queries?
For example, in the global_stats, I see something like this:
{"min_difficulty": 479474.8692329195, "pool_stale_prop": 0.1111111111111111, "pool_hash_rate": 136727809739777.47, "pool_nonstale_hash_rate": 121535830879802.19}
How would I add to that to get things like "expected_time_to_block", "last_block_found", "total_network_hashrate"?
Currently I've fudged the first two by hooking into p2pool.info directly to retrieve the data, but I'd like to have it come from the global_stats.
Thanks for the help!
|
|
|
|
|
That's an interesting thought. Let's assume for a minute that every miner in the world but you shut down. Isn't the difficulty level reset every 2 weeks (give or take) based upon the number of blocks solved and hash rate? If absolutely no blocks are solved (or maybe the OP gets lucky and solves 1 at the current level), how does the network react? Isn't the algorithm designed such that blocks should be solved on average every 10 minutes? If suddenly no blocks are being solved, wouldn't the difficulty level be recalculated immediately such that blocks again are solved every 10 minutes or so?
|
|
|
|
Hey BTCTalk!
I need help choosing a PSU to work alone, meaning, 1 miner, 1 PSU. If history taught me one thing is that it's always the best way and I like to do things the right way, the best way, from the get go, so it leaves nothing on the table. To me, the PSU is as much an investment as the mining machine itself. Well, there like a million PSU's out there and I'd like to buy in BitCoin but I find it hard to find sites to buy computer and mining related stuff you can buy with BitCoin. I would be bound to believe that every computer and nerdy type store would take BitCoin but alas...
I guess a drawback of being a pioneer. I been reading this site for long but never needed to comment nor ask anything but looks like miners in this industry are very similar to miners in the Gold industry in which I also have mining assets.
I'd like suggestions and like anything, I want to get the best bang for my buck. I value reliability and durability above all.
I have my eye on a few but I'd also like to avoid the gross retail markup. So far, I found this to be the best bang for my buck:
CoolMaster S80 PLUS Gold RS550 PSU
I think it's a good deal right now and it's single rail from what I read... which one single S1 will run will run on one of those right? It puts out 550 Watts but I don't know the company CoolMaster; first thing that comes to mind is MasterCraft - CanadianTire mid quality crap. Or well, on paper it should but I'd like to hear out if anyone used those for one single S1. If someone can save me the headache by either saying, that it works well for them or to run in the opposite direction then it could look like I could have a decent source for those because the deal is half decent and they seem quite mass produced.
I know this PSU debate is never ending... computers are my thing and I have this OCD called perfectionism... lol
Thanks in advance for insight and advice in advance. Please, no "don't even start" crap, it's fair to say everyone in this site was probably told that at some point lol. I have time and I'm not money hungry either, I'm a professional war gamer and developer, BitCoin to me is the easiest game I ever played... It just happens to pay a lot better than any other game I pay to play. I also happen to live in a cheap energy nation. Lucky me eh, so why not.
Peace out!
GigaBit
I've got a Corsair CX600M that worked flawlessly with a single S1. Now I drive 2 S1 off a single Corsair HX1050 with plenty of power. My S1s are over clocked. PS - don't start!!!! |
|
|
|
|
That's pure BTC mining porn right there... looks like that setup is pushing 65-70 TH/s give or take.
|
|
|
|
They make pills for that... Oldiesel, yes, you can mix both U1 and U2. U2 is really just a U1 with a big, fat heatsink. As phillipma1957 stated, your USB hub is not providing enough power to drive the 4 miners. |
|
|
|
Mine is a kid compared to others I have seen here!
No doubt. I've read about some pretty intense setups like folks who have their own power generation driving the mining. When I read your reply seeing 10Th/s with Antminers, the first thing I thought was, "Wow! That's sweet!" and then immediately it turned into, "How would I possibly get enough power to drive that?" which of course then turned into, "That's 20kW!" (Cue Doc Brown screaming about 1.21 Gigawatts and flux capacitors).... |
|
|
|
Interesting read! Thanks for keeping up the thread throughout the year. The S1 is a nice piece of hardware. I've got 2 of them running off a Corsair HX1050 with no problems at all. I agree that they're a bit loud... and they keep my office nice and warm Going to have to move them to the basement for the upcoming summer months. |
|
|
|
Unfortunately, it was found via the pool (GHASH.IO)  Congrats! The best share my S1s have found is ~83 million. I actually have my 5 U2 sticks playing the lottery... they solo mine BTC. Unfortunately the best share they've ever found is 204k... lol I have 10 Th/s for more than three months, all S1s , and never found any block. You're God damn lucky!  Wow... 10 TH/s of S1s... 50 units overclocked to 200GH/s each... 20kW of power driving it. That's one hell of an electricity bill  |
|
|
|
1) Have all miners payout to a single address by starting each with -u MYPAYOUTADDRESS, where MYPAYOUTADDRESS is the same as the address the p2pool node pays.
2) Have all miners payout to a single address as in option 1; however, that address is not the same as the p2poool node payout address
3) Have each miner payout to a different address, independent of the node's payout address.
4) Something I haven't thought of?
If my understanding is correct, the only time the p2pool node would payout to it's default address is if I'm collecting fees. If I want to see payouts on the "Payout if a block were found now", I would have to set my miners to pay to the node's payout address as well.
I actually had to make a very similar decision recently. What I learned is that if you don't set an address (and instead use a generic label like "Antminer") for each miner, then all the shares earned will default to the payout address you've set for your pool. That way, you can track each device individually in your local p2pool node's stats, but still get the benefit of a combined payout. If you use the -a option on the command line, you can specify any payout address, even one that isn't part of the local bitcoin node's wallet. If you prefer, you can set a specific payout address for each device, and track the earnings that way, but with your RPi, you won't get shares very often. That will lead to long stretches of no shares. Also your payouts will be more fragmented, which means when it comes time to spend them, you'll have to pay slightly higher transaction fees. As to your options, you could do #1, but I personally went with the "labels" option I mentioned. #2 is more or less identical to #1; it's just up to you where you define the address (on each miner, or on p2pool's command line). #3 is also permissible, but has the downsides I mentioned. Great point. That would be option 4 - one I didn't think of  Just start the miners up with usernames like "S1_1", "S1_2", "rPi" and they will default payout to the node's wallet. I'll restart them that way so I can track each miner's performance, but get the benefits of combined payouts (and like you stated, smaller fees because the payouts would be larger). Thanks for the tip! |
|
|
|
|
On a different topic, but still very much related to educating me...
What is the recommended setup when you've got multiple miners pointing to a local p2pool node?
Let's first describe the hardware:
Box running local p2pool node and Bitcoin-Qt. P2Pool pays out to wallet address other than the one running locally. Since it's a local node, there are no fees (seems a bit silly to charge myself)
2 Antminer S1
1 Raspberry Pi controlling 5 Antminer U2 USB sticks
Options:
1) Have all miners payout to a single address by starting each with -u MYPAYOUTADDRESS, where MYPAYOUTADDRESS is the same as the address the p2pool node pays.
2) Have all miners payout to a single address as in option 1; however, that address is not the same as the p2poool node payout address
3) Have each miner payout to a different address, independent of the node's payout address.
4) Something I haven't thought of?
If my understanding is correct, the only time the p2pool node would payout to it's default address is if I'm collecting fees. If I want to see payouts on the "Payout if a block were found now", I would have to set my miners to pay to the node's payout address as well.
If I go with option 3, does the p2pool node software dole out appropriate difficulty to each miner? Here, the 2 S1s at 200GH/s each should get higher difficulty than the 5 U2 sticks with a total of 8GH/s, right? I realize that it really doesn't make much difference in the long run since the difficulty is purely for "lying" to the miner and getting better approximations of hash rate by allowing the miner to solve less difficult shares, right?
Again, thanks for the inputs!
|
|
|
|
Quick question. What happens when the expected time to block exceeds the rolling window of shares counted for payout? Yes, I understand that you *might* have a string of luck where you find more blocks than expected, and you also *might* have a string of luck where you might find fewer blocks than expected. However, we are dealing with an expected time to block, because that's what the "average" should work out to be given enough time. Currently, it's a 3 day window of shares counted for payout, correct? If that's the case, then our average time to block (given the latest stats I'm looking at in my local p2pool node and those on p2pool.info) with ~130TH/s is ~2.3 days. So, with that average, we're good because time to block falls within the payout window. If the hash rate is such, or the difficulty is such, or whatever, where the expected time to block becomes 4 days, 5 days, longer... doesn't that equate to "wasted" work mining because there are days gone by without being counted? Please educate me oh Gurus of Mining Knowledge! |
|
|
|
|
Wow... Is everyone jumping ship? Hash rate is down to about 110TH/s...
|
|
|
|
Ahh... I've got rav3n's and forrestv's. Are you merge-mining the BTC/VTC/UNO? What kind of impact, if any, does that have vs just mining BTC? I assume you'd start the p2pool with something like: ./run_p2pool.py --merged walletID@host:port ... Yeah? Edit: Well, you're obviously not merge-mining the VTC since it's scrypt-n |
|
|
|
Hey roy7,
So, I decided to check your stats page again. Now you've found 11 shares (3 more since this morning when I first checked). I've found exactly 0 more.
Am I just exceedingly unlucky, or have you been exceedingly lucky, or is something more nefarious going on here on my end? Over 16 hours since the restart after upgrading Bitcoin-Qt to 0.9.1 and I've found 1 share...
You must be unlucky? The interface tells me the time to share for 186 GH/s is currently 4h 3m 37 s. I don't see how/why bitcoind would mess you up. I'm also running 0.9.1. LOL... with luck like that... seriously... 1 share in 16 hours... that's just plain awful. I could probably calculate it by hand faster  Edit: I noticed that the versions showing on our nodes are different. Yours shows 13.4-34-gabbbdd3-dirty. Mine is 13.4-24-gf0eeb48-dirty. I just did a git pull from forrestv repo last night when I updated to 0.9.1. How'd you get the 4-34 version? You running off some branch/fork? |
|
|
|
|
Show Posts
