|
I love the speculation and guesswork in this thread. A million years until the coins are all mined? LOL.
Bitcoin is based upon a finite supply of coins. Those coins are distributed into the ecosystem in a decreasing amount until all 21 million of them are dispersed. Every 210,000 blocks the amount rewarded for finding a block is halved. So, the first period it was 50 coins. This, being the second period it is 25 coins. Next period will be 12.5 coins. So on and so forth until there aren't any more to create.
You can very easily calculate the expected dates of each one of those events, and of course when the date on which all 21 million coins will be created. (Hint, 144 blocks are expected to be created a day).
To answer the OP's question: once the 21 million coins are generated, there are no more block rewards. The coinbase transaction of the block will contain only the transaction fees.
|
|
|
|
|
I did the same, Phil. Soon as it topped $300 I sold a couple coins.
|
|
|
|
|
Yeah, I'm behind. The real world has kept me busy and this is really the first time I've sat down to do the data. The data is below; however, unlike in previous updates I'm not going to update the OP with the details. I'll just leave it up to the graphs and raw data from the spreadsheet to provide the updates in the OP. Eventually I'm not going to be able to add any more text to the first post anyway, so I might as well just start condensing it now.
In the past 6 weeks, things have been up and down for p2pool. The luck stats would seem to indicate that as well. Weeks of 9/18, 9/25, and 10/9 were below average expected luck, while the weeks of 10/2, 10/16 and 10/23 were above average. As for my miners, they've tended to mirror that trend as well. However, of note is that my miner on the NastyPoP payout has pretty much consistently (only 1 week in 6 that it didn't) beaten the standard p2pool payout.
9/11 - 9/18
NastyPoP: 0.01749809BTC
NastyP2P: 0.01594801BTC
Expected: 0.02704454BTC
Luck - 64.05%
9/18 - 9/25
NastyPoP: 0.02153287BTC
NastyP2P: 0.0122369BTC
Expected: 0.02610505BTC
Luck - 97%
9/25 - 10/2
NastyPoP: 0.04509658BTC
NastyP2P: 0.04937384BTC
Expected: 0.02598755BTC
Luck - 197.69%
10/2 - 10/9
NastyPoP: 0.01134903BTC
NastyP2P: 0.00951317BTC
Expected: 0.02547065BTC
Luck - 57.71%
10/9 - 10/16
NastyPoP: 0.02790957BTC
NastyP2P: 0.02483293BTC
Expected: 0.02546511BTC
Luck - 133.15%
10/16 - 10/23
NastyPoP: 0.03667461BTC
NastyP2P: 0.02703798BTC
Expected: 0.02544111BTC
Luck - 185.08%
OP updated with latest numbers
|
|
|
|
|
No. Your payouts mature after 101 confirmations. P2Pool pays virgin minted coins, so you have to wait the full maturity time before they become available.
|
|
|
|
|
In p2pool you only get paid for shares you have on the share chain when a block is found. Typically (this varies, but just for the sake of simplicity) a share lasts 3 days before it falls off the payout list.
So... if you have valid shares still on the chain when a block is found, you'll get your portion of the reward for those shares.
|
|
|
|
You need to define what you mean by mining rig. Heck, you grab a simple USB miner (sidehack sells his own) and plug it in to a raspberry pi and call that a Bitcoin miner  . If you're talking about building from scratch... well, that seems to be a bit over the top. |
|
|
|
|
Is the block size limit a problem? Yes. While right now the block reward is sufficient for most miners to be happily compensated for their work, that will not remain so for long. The supply of coins is finite. The idea is that as the block rewards go down, the transaction fees go up to compensate. How do you get more transaction fees per block? By including more transactions, or by charging more per transaction. If we want to include more transactions, we need to be able to have bigger blocks. Remember, the network itself will continually adjust to maintain its "10 minute per block" timeline. Therefore, as more and more transactions are coming in during those 10 minutes, the blocks need to be able to be created large enough to contain all of the them.
Of course, a ton of pools are going to have to retool their code (AntPool for example) because they keep the transaction fees for themselves.
|
|
|
|
Hi Phillip,
Appreciate your advice, but I have all up and running for a few days now, I rather not mess with it even if it saves me a bit.
Okay, I have taken everyones advice into consideration about trying out different ones to test what I get.
I am now currently taking a stab at p2pool with a portion of my machines, then I will try something next.
Thanks guys.
Just another bit of food for thought. Bitmain has historically not played nicely with p2pool using their default firmware/drivers. They have their own lousy fork of cgminer, and refuse to incorporate work that both -ck and kano have done to improve it. Especially in regards to p2pool, Bitmain's default driver will not submit stale shares. Furthermore, Bitmain hardware typically loses 10% or more hash rate on p2pool - again because of their lousy coding. |
|
|
|
|
That would explain things... if the bitcoind process was frozen and you were still mining to that node that actually explains everything. Because bitcoind wasn't fetching new blocks, p2pool was always mining to an old block. You were submitting shares just fine on your node. The rest of the network was rejecting your shares (since they were from old blocks). Then when things came back to life on your node, things caught back up, the shares you submitted were immediately dropped and your expected payment went to what the network thought it should be.
In effect, even though your miners were mining, they weren't doing anything useful because they were solving shares for blocks that were already on the chain.
|
|
|
|
The pool rate is always jumping about - it's normal. failovers, restarts, miners coming & going etc.
Sure. But look at my graph. smooth and steady at 0.9something for many hours then jumpily climbing... That's not what you would expect to see. Edit: you would expect to see some climb after we found two blocks so quickly but it still doesn't look correct. Edit2: Check this monthly chart, especially the circled areas. Looking at this one makes me think it doesn't support the fork hypothesis as much as I had thought though.  Huh... here's that same graph from windpath's node:  The blank spot is where his node was down. I see some differences... |
|
|
|
OP, as much as I'd love to have that extra hash rate on p2pool, if I had that kind of setup, I would almost certainly spend the time to setup my own pool and mine to it as eleuthria (who certainly knows a thing or two about running pools) mentioned. Of course, that also runs the risk of poor connections to the network and orphaned blocks, so considerably higher risk (losing the full block vs losing a few shares on p2pool). Maybe see if -ck would be willing to work on something with you. He might know a thing or two about mining and pools...  EDIT: I actually just saw -ck's reply above to use www.kano.is. So let me get back to the basics of your original question. PPS does not suffer the effects of variance. You get paid for every share you submit. The value of each share is calculated as the block reward divided by the network difficulty. The big PPS pools (f2pool, AntPool) charge you a fee for PPS mining, 4% and 2.5% respectively. Now, f2pool does give you alt coins (NMC, HUC, etc) to help offset the fee, so at the end of the day you probably end up making about 98% of expected earnings after everything is factored in. PPLNS pools (like p2pool, www.kano.is, antpool) are very affected by luck and the luck swings can lead you to making considerably more or considerably less coin than expectations. I actually have a very long running thread (which I need to update with the last month's data... will hopefully get to that tonight or tomorrow) showing actual earnings of an S3 on p2pool since about Christmas of last year. You can clearly see from the graphs that there are ups and downs, but overall I have made more BTC than expected payouts for that hash rate. If you go through the thread you can see there were weeks where p2pool found no or very few blocks and others where p2pool found more blocks than expected. You can also see the effects of luck. There was one week where even though p2pool had better luck than expected, I actually made less than expected because of how many shares I had on the chain when the blocks were found. Anyway, if you want to take a look, that thread is here: https://bitcointalk.org/index.php?topic=891298.0. On a more personal note, I don't support the behavior of either f2pool or AntPool. They both perform SPV mining, have caused forks in the chain previously, and run shoddy software that produces empty blocks. |
|
|
|
Just on the off chance, are you using the latest version of p2pool?
Saturation should never be a problem with p2pool - it uses minimal bandwidth, almost nothing. How many connections does your bitcoind have? I restrict mine to 14 to keep bandwidth down - I also use QOS for prioritizing traffic on ports 9332,9333,8332 & 8333.
That would have been my question as well, but using a version earlier than 14 would result in no shares submitted at all, and hence no expected or actual payouts. To be honest, I've never seen the behavior Richy_T is reporting here. Yes, I've seen shares drop off the chain; however, it is in proportion to when they were added. For example, if I suddenly start mining with 1PH/s, I would see a very rapid increase in the number of shares I have on the chain, and then when I stopped, they would drop off at the same rate. My calculated expected payouts provided by the node have always been spot on (give or take a few satoshi). My actual payouts reflect the node's expectations. I wish I had some better news or a solution I could offer, but unfortunately I'm at a loss, too. |
|
|
|
Well sounds a wise chooise avoid the summer ,and well i hope you can keep us informed about how it will go on.I would like to be part of this solo miners but rigs very expensive here.
You could always try renting some hash and hoping to hit... might be a cheaper option for you than purchasing a rig. |
|
|
|
To anyone who has experiences in p2pool, for 2.3PH/s running 24x7 how many bitcoins would you estimate I would get/day?
Thanks
D = Difficulty H = Mhash/s C = Reward (currenctly 25 BTC, soon to be 12.5) 24 / (D * 2^32 / (H * 10^6) / 60 / 60) * C = BTC/day Writing the formula another way: 25 / (2^32 * difficulty / hashrate / 86400)
For 2.3PH/s it's 18.99852101 BTC expected per day. |
|
|
|
|
As of this writing, we just added block 379767 to the chain. The diff adjustment was block 379008. That was on 2015-10-15 11:32:31. 379767 was found 2015-10-20 17:31:30. This is one second shy of 7559 minutes. We have solved 759 blocks in that time. Expected average for that time is 755 (just one minute and one second shy of expecting 756).
So, we've actually found 759 and should have found 755. Only 4 blocks over for the period so far...
|
|
|
|
How much the quality of internet is matter for solo mining in this pool ? like ping,speed, distance and ...
I live in middle of Asia. how much my chance is lower than someone who lives is USA for mining in this pool ?
Thanks,
you may be at a very slight disadvantage. the disadvantage would be most likely under 1% but when I hit 2 blocks here in under 3 hours via 500 gh in rentals 1 block was from a nicehash rental (Europe server) the next block was from a westhash rental (usa server) Pretty sure you meant 500TH/s in rentals (that was our group rental we did a while back, right?)... you didn't really hit two blocks in 3 hours with only a 500GH rental, did you? |
|
|
|
...
I watched as the bitcoind would slowly consume more and more memory, up until it took almost the entire 8G available, at which point it would invariably die off.
What was the magic you used to produce the output, (8G <-- bitcoind is using this much ram.) Somethings not right there man. Linux will try to use alot of the computers memory to keep the system fast. 8 gigs of ram i'm thinking is below average for power linux users. Is adding more of it an option for you. Maybe i'll bootstrap a build and run the latest bitcoind and the p2pool to see what the story is. No magic at all... and honestly I'm not sure why things just kept spiraling up like they did. I had that node running for over a year and never experienced any problems with it until relatively recently. I ended up just killing the node. I couldn't justify the $80 a month expense, and I didn't have the time to constantly monitor it to ensure it was behaving. I know there are plenty of other nodes out there running on Linux, and likely not experiencing anything near what I saw, and to be honest I never bothered inspecting it too closely. I just finally got fed up with the hassle and realized that I didn't want to deal with it any longer. I still run my own local node and now use windpath's node as my backup instead of my own VPS. |
|
|
|
I'm inclined to believe the memory leak... although I've only seen it on my Linux (Ubuntu 14.04) node. I watched bitcoind spool up to consume 8GB of RAM before it was shut down. On my Mac, using the same codebase, I regularly only see about 400MB of RAM being consumed by the bitcoind. Both Linux and Mac are built from source.
Are both bitcoind nodes being used for p2pool? My testing indicates that the use of getblocktemplate is necessary for the memory leaking to occur. Yes. I was running a VPS (a DigitalOcean droplet) that I used as my backup p2pool node. I had other miners besides my own on it pretty constantly. It ran for quite a long time until a few weeks ago it started acting up. The bitcoind process would die for no apparent reason. Sometimes the p2pool process would just die off as well. Finally spending time looking at the box, I watched as the bitcoind would slowly consume more and more memory, up until it took almost the entire 8G available, at which point it would invariably die off. On my Mac, I also run a p2pool node that is local to my miners at my home. That bitcoind, just like the one on my droplet, was compiled from source. On my local node, I've never seen it utilize more than 1G of RAM. More typically, it's around 400-500MB. Granted, I have fewer miners on my local home node (2-3 at most with a total hash of about 5TH/s). On my Linux node, I typically had 5-6 miners with a hash rate of about 15TH/s. |
|
|
|
Yea, I'll keep an eye on it, so far mempool seems to be behaving normally.
As to the high reject rate on my node I suspect you are correct.
In addition to the # of miners a lot of folks seem to park their browsers on the stats pages which hit both p2pool and bitcoind to pull some of the data for the front end.
There are some relatively easy fixes like setting the data refresh to stop in the browser after say 30 minutes with a "I'm still here" button to restart it....
I'll look into it.
If I remember that UI correctly, there's a config file that defines the stats refresh rate, which defaults to like 10 seconds for the stats and 30 for the graphs (or something like that). Of course, you've customized it so much that file has probably been rendered irrelevant at this point . |
|
|
|
Not sure what went down, something crashed bitcoind, which is unusual on my server.
The congested mempool that we've had recently from the 14kB blocks is causing excessive memory consumption. From my investigation so far, it looks like there's a memory leak in getblocktemplate/CreateNewBlock. This makes bitcoind's memory consumption increase by as much as 1 GB per day. I've been restarting my bitcoind processes every 2 days or so. We keep relatively strict limits for bitcoind's mempool on the node, granted below is only since this mornings restart, I'll keep an eye on it. bitcoin-cli getmempoolinfo
{
"size" : 1967,
"bytes" : 1745856
}
I'm inclined to believe the memory leak... although I've only seen it on my Linux (Ubuntu 14.04) node. I watched bitcoind spool up to consume 8GB of RAM before it was shut down. On my Mac, using the same codebase, I regularly only see about 400MB of RAM being consumed by the bitcoind. Both Linux and Mac are built from source. Anyway, back on topic... I wonder why my reject rate is always so high mining on your node windpath. My ping time to your server is about 17ms, yet I'm constantly seeing 10% or higher DOA. When I was running my own VPS node (with about the same ping time), I would typically see about 3-4%. Yes, running my own local node when I'm at home is considerably lower (usually about 1% or less), and that's to be expected since my miners and my node are all hardwired into the same internal gigabit network. I'm wondering if it is caused by the traffic on the node, and p2pool's inherent single-threaded execution. Anyone have thoughts on it? |
|
|
|
|
Show Posts
