Unfortunately, I can't find how to send a report.
Report Issue is a button on the In-App settings page. |
|
|
|
Are they the same every block or do they vary? Also, could you share what some of them are?
The last output in the coinbase is the special P2P hashchain commitment. It has zero value and it now looks like OP_RETURN PUSH <data>. Thanks gmaxwell. Is there anywhere a script could pull the special P2P hashchain commitment from if and when it changes (in order to do a regex search of the coinbase)? Or is that something you'd have to run a p2Pool node in order to do? The <data> will always be different and depends entirely on P2Pool's sharechain, so I don't think it's too useful. Instead, the second to last txout will always be to the donation address (1Kz5QaUPDtKrj5SqW5tFkn7WZh8LmQaQi4) and then you can match the template of the last txout (0 value to OP_RETURN PUSH <data>). Either of those alone is probably good enough, but combined should work very well. Thanks forrestv. I didn't think of looking for the donation address to confirm. That's what p2pool.info does, essentially. Note, I would also suggest excluding any blocks that do not have at least 25 outputs. There are some non-main p2pool installations running out there (either forks, or someone running their own mini-pool with the p2pool codebase). They all have only a few people mining on them, as far as I know, so their blocks only have a handful of outputs (besides the donation address and the special last transaction). |
|
|
|
I feel like we've had a lack of communication this week. Especially seeing as how if Bit Fury is shipping, we should be seeing some decent increases in hashrate, between hardware purchases and contracted hardware. While it's nice to see pictures and all, it would be nicer if the level of communication increased, if only on the "Such and such added to the hashrate today." If you want to keep selling shares, Lab Rat, you need to keep up the communication of hashrate increses. Hell, just updating your site with the latest numbers would do it. I think the rest of LRM shareholders would disseminate information pretty quickly from there. Maybe let grnbrg handle to communication end since he seems to be "in the know"?
FYI, the hashrate shown at the private pool for LabRat is now 1.83 TH/s. There is an API now for the pool that could be used to dynamically read the current hashrate. If LabRat doesn't update his website in the next few days to start using the API (instead of requiring manual updates), then I'll put something together. |
|
|
|
* gigavps presses the easy button  You will find a new top navigation link named "API" that details out all of the functionality you can access via the API. I have added the ability for you to get worker, reward and payment information. Awesome, thanks. What I am looking to do is include on my own mining dashboard an indication of how much balance (including unconfirmed rewards) has built up that hasn't been paid out yet. On the website UI, that translates to "Total Rewards - (Paid Rewards + Pending Rewards)". If there was an API that just had these 4 summary numbers, I'd have everything I need: Confirmed Rewards and Unconfirmed Rewards (from the Rewards tab), and Paid Rewards and Pending Rewards (from the Payments tab). As far as I can tell, the only way to get those numbers is to call the rewards.json and payments.json APIs (repeatedly to get each page of results until I get an empty page) and add up the numbers from those results. Certainly doable, but probably means hitting the APIs harder than is probably ideal. I am assuming that you have a quicker way to get at those numbers internally with less CPU/database overhead since you are displaying them on the web pages. |
|
|
|
|
16 H cards is 400 GH/s, as I recall, so 18 will probably end up at around 450 GH/s. The M boards are just what the H boards plug into. Each can hold up to 16, I believe.
|
|
|
|
I know I'm a bit late in menting this, but a few posts back there was a bit of confusion with where 'make clean' should go. I think people may have been getting confused with 'make distclean'. 'make clean' should just remove old object files, etc (things generated AFTER make is executed) leaving the configure file, etc intact. 'make distclean' will do the same as 'make clean' AND it will remove the configuration file, etc too. So 'make clean' should be safe to run after a autogen or configure command, 'make distclean' won't be safe. If you get an error when you type make clean that there is nothing to be done, that usually means that it's already clean.
I would imagine a good thing to do when building a new version is definitely to run 'make distclean' first to clean out old configs as well, especially if the build process has changed. Even better would be to just 'sudo rm -r <cgminer directory>' and do another git clone of the repo, then you know you are safe and don't have anything lying around if you are having problems with the build process.
I realise this was not the original posters problem in the end, but just though it should be mentioned for when people compile other things.
Alex
The problem is that with cgminer 3.4.1/2 there is a completely new configuration, so yeah anyone upgrading really needs to ensure they aren't skipping the autogen and configure ... so it's easier to say: rename the old directory (so you can get any config files or scripts from the old directory, if needed after you rebuild) and start again with an empty cgminer folder or fresh git clone ... even I made some mistakes with this back about 2 or 3 months ago when I was doing libusb version testing (and failed to switch the versions properly a few times) I have a build.sh file in my cgminer git working directory that I run every time I want to build cgminer. It looks like this: #!/bin/sh
make distclean
CFLAGS="-O2 -Wall -march=native" ./autogen.sh --enable-bflsc --enable-icarus --disable-opencl
make
mv -f cgminer cgminer-nogpu
The 'make distclean' may not be necessary every time, but it doesn't take long. |
|
|
|
Bitcoin-QT can't handle that much hashrate.
interesting. I never knew that. Nonsense, Qt can handle anything you throw at it. To say otherwise is to doubt Satoshi, and I will not have it. /Troll People that have solo mined with high hash rate ASIC's have setup their own pool software to do it. The Bitcoin-QT client has no Stratum protocol nor variable difficulty. Edit: All I am trying to say is that solo mining 23,506.34 GH/s is no trivial task. He was being sarcastic  |
|
|
|
|
Hi, just checking in on if there has been any progress on expanding the API to include information on current account balances (confirmed/unconfirmed rewards, pending/paid rewards, unpaid rewards, etc).
|
|
|
|
NOw my hashrate is 400~550 MHs after restarting, and my address is nowhere to be found on Current Payouts or the Active users, it appears that my address just wanishes from the p2pool.info.... Payout, in p2pool, is still 0.0000..........
Exactly. It'll stay like that until you find another share. OK! But why did my address keeps dissapearing from the list? It happened before I restarted p2pool and cgminer...? It works good and just suddenly goes poof without any obvoius reason from my side. I mean, I didn't touch anything on my PC, but my address simply dissapears? The list only shows addresses that have found a share recently enough to be owed a payment in the next block. If you go for a long time without finding a share (as will happen with a low hashrate), you will not be on the list. |
|
|
|
I have been having the same problem in the past month. Restarting everything sometimes fixes it. This is what it shows now: Node uptime: 0.788 days Peers: 6 out, 8 in
Local rate: 1.38GH/s (3.1% DOA) Expected time to share: 31.2 hours
Shares: 0 total (0 orphaned, 0 dead) Efficiency: ??? It's not a "problem" in the sense that something is not working right. Your hashrate is just low enough that you're finding shares very often. There will be dry spells where you won't have found any shares and then every once in a while (on average every 31 hours), you'll find a share and get payments in the next couple blocks, etc. Note, the 31 hour estimate is an *average*. It is not uncommon to find shares more frequently than that or more infrequently. In reality, you may commonly see the time between shares range from 8 hours to 5 days. |
|
|
|
I have a huge problem!  I didn't recieve payments from last 2 found blocks!!! My miner is working constantly but the last payment is from 29.08.2013 after that nothing.... This is my BTC address 1HhnzLoam81FRcrjBJkGYVHoWduDwsqs6C What's your hashrate? Have you found any shares recently? In cgminer accepted shares are normal, and it works good, in p2pool.exe I have 0 shares and 0.0000 payout... Ihave just restarted PC and started all over again, but, with the same result.... cgminer shares are not real p2pool shares. They are psuedo shares to help you see that your miner is working. All that matters for getting paid is finding real, p2pool shares (which are much higher difficulty). You have found 0. That means you don't get any payout in any blocks found. You didn't answer the question about your hashrate, but if you look at the p2pool console output, it will also tell you the average amount of time to fine 1 share at your current hashrate. My guess is that your hashrate is pretty low and that average time is very long. |
|
|
|
I just fetched the latest CGMiner, and oh, god, what happened to the share logging? Please change it back.
If you mean A: and R: (and WU:) no it will not be changed back to displaying meaningless information  It was very much meaningful information. It told me how many shares I have submitted. So let me get this straight, rather than have it tell you how much work you've done that the pool will reward you for, you want a variable on the screen from the cpu mining era of diff1 shares that today correlates with absolutely nothing at all unless you happen to mine on one of the last remaining pools that accepts diff1 shares, in which case the result is equal to what's shown in the current cgminer anyway? I like it the way it is now. Please don't change it back. |
|
|
|
I have a huge problem! I didn't recieve payments from last 2 found blocks!!! My miner is working constantly but the last payment is from 29.08.2013 after that nothing.... This is my BTC address 1HhnzLoam81FRcrjBJkGYVHoWduDwsqs6C What's your hashrate? Have you found any shares recently? |
|
|
|
Better yet, where can we found tabular data of blocks and their vital data (e.g., timestamp and difficulty) from which this can easily be deduced? The closest to this I found was blockexplorer nethash, but the minimum allowed is steps of 5 blocks.
Data on all blocks can be obtained by the blockchain.info API, but you'd have to make multiple API calls to get all the data (they have no API that dumps everything in one call). Probably the blocks-in-one-day API would be the easiest to access. Just have to make 1 call for each day since the network went live (which is many fewer requests than 1 per block-height). |
|
|
|
And is it fair enough to let a miner mine blocks that include previous shares from others? I mean the work the others did before the actual miner found the real bitcoin block is lost then right?
Yes, but that is the entire point of pooled mining. Miners agree to split the reward for a block with those that were helping to find blocks at the same time even though those other miners failed to find anything. The block reward cant be sent to some zentralised server first that then determines how many btc every miner gets right?
That is how a normal pool works, and is entirely viable, but it's also contrary to the entire point of p2pool which is to avoid having any centralized server that everyone depends on and has to trust. |
|
|
|
p2pool allows you to submit lower difficulty shares to make it's stats work to show how it thinks you are hashing
That is what the +x difficulty is all about to set it above the old default 1 difficulty
Yes, but in the context of this discussion I think we're talking about the '/x' difficulty username option (vs '+x') which actually does allow you to change the target for the real p2pool shares and not just the pseudo shares (as long as you choose something higher than what p2pool network requires by default). |
|
|
|
That's something I don't get: how voluntarily increasing your difficulty will help you.
Wouldn't you want to claim as many shares as possible, even if they are small amounts?
You will get paid more for the higher difficulty shares. It will reduce your bandwidth usage if you are putting out a lot of hash power. In other words, the "value" of a share is not fixed. It's based on the target difficulty for that share relative to the target difficulties of all the other shares that make up that block. In other words, if you opt-in to a difficulty that is 2x as high, you get paid 2x as much for that share. |
|
|
|
How does the payout work for small miners? Is there some kind of rule for dust payments?
You get paid for each share you have found within the PPLNS window. So the smallest payment you can get is for 1 share, which translates to ~0.003-0.004 BTC at the moment. |
|
|
|
I get a number of errors when trying to run this:
http://pastebin.com/raw.php?i=Up1xV5mR
I didn't see anything in the readme about installing dependencies, but it seems like several assemblies are not on my system (Windows 8 64bit w/ Visual Studio 2012 installed) that are assumed to be there...
Nevermind, there was a piece of software on my computer that was auto-deleting "old" files from my download folder and it deleted all the dependencies as soon as they were extracted. I extracted the archive to a different location and it works. |
|
|
|
There probably a simple answer to this, what do you do when the number of erupters you are running pushes the display off the bottom of the screen. So far I've been getting by with a smaller font, but that will only work so long.
resize the window. click on the box in top left, click properties. go to layout and increase the window height. you may need to restart it for it to take effect. (I assume you're talking windows) M actually, i'm using linux. I know how to resize the window, the question is how to cope when the biggest window that will fit on the screen doesn't have enough rows. Use --compact mode and stop get per device statistics from the API (some kind of dashboard, etc) instead of by looking at the screen. |
|
|
|
|
Show Posts
