Something I don't understand ... . I start the bitcoin daemon, wait till it's up and running . I start the pool daemon with a payout address specified on the command line and whose private key is in the wallet of the bitcoin daemon . They talk to one another fine . I start cgminer, it gets shares from the pool fine and after a while, solves some . The pool reports solved shares received from the miner Everything looks peachy until I decide to look at: http://127.0.0.1:9332/current_payoutsMy payout address is nowhere to be seen  Am I missing something ? Look at P2Pool's status line. Are the shares not orphaned or dead? If they're not, they should definitely be displayed in /current_payouts . |
|
|
|
I know that coblee is (or at least was). |
|
|
|
1) the problem with merged mining: i looked a little bit over the code, an afaik you are only checking your own hashes against namecoin or whatevercoin and you get the hole block, so alternative-blockchains are solo mining.
my evil side says me that all good bitcoin hashes are stored in this history-db to do double checking (verification of the share-history so there are no "cheaters") and if i understand the merged mining stuff right ever good bitcoin-share could also be a good namecoin-share, so all i have to do is set up a little "optimized" P2P-Pool-server with or without a miner and send every new share that is coming over P2P to my alternative "solo-mining-namecoin-server" and hope that there is a positive match!
or did i miss something? i guess i am not the only one with this idea....
my suggestion is that there should be at least an namecoin support by sending the share with bitcoin&namecoin-adresse, so that also the namecoins are splitted over the users that provide a valid namecoin adresse and if an share without valid namecoinadress comes over P2P there should be a check by the merged-miners
i know there are more alternative chains but namecoin is by hashrate the second one! and namecoins are a good idea, my opinion is that other currencies are only splitting the community
You can't use somebody else's share as a Namecoin attempt that would pay you. The Namecoin blocks all include a transaction to the miner that created it, which you can't change. Changing it would change the block's hash, making it worthless. Also, you can't use a non-Namecoin share to get NMC, because Namecoin requires a special tag to be inside the block. Yeah, I'm working towards pooled merged Namecoin mining. 2)version stuff: at some releases you are writting that everbody has to update the version, what would happen if i am not able to update because of some remotecontrol-problems? is there some kind of protocol version? i didn't look that up in your code, i would prefer a split of the pools so that people who arent updating because of what ever are mining with the other non-updaters
That will already happen - the sharechain will fork, with old miners on one side and new miners on the other. Also, I try to schedule these forking changes at least a few weeks in the future, so everyone has a lot of time to upgrade. For example, the last change that went from a 12 hour to 24 hour payout period was included in a release 25 days before the actual change happened. 3)small thing: it would be nice if there would be some proxy(tor) support, i know that when everbody would use this over tor there would be a major connection problem, but not more as if nobody would make a port-redirect on there routers
Tor would probably increase latency quite a bit... But in any case, you can already do it with tsocks: tsocks python run_p2pool.py ... should work fine. |
|
|
|
I already have the 3 daemons running, the bitcoind (from Ubuntu PPA), namecoind and litecoind compiled from sources.
Now I want to setup the P2Pool daemon to talk with Bitcoin (default), with Namecoin via merged mining feature and, with Litecoin.
So, how to do it?!
Do I need two P2Pool daemons? One for Bitcoin/Namecoin and another for exclusively Litecoin?!
I'd recommend sticking this in litecoin.conf: Otherwise, the bitcoin-P2Pool and litecoind's ports will conflict. By default, namecoind's RPC port conflicts with Bitcoin's too, but you probably already fixed that. You need to run two instances of P2Pool, one for Bitcoin and Namecoin, and one for Litecoin. For the Bitcoin-Namecoin one: python run_p2pool.py BITCOIN_PASS --merged-url http://127.0.0.1:NAMECOIN_RPC_PORT/ --merged-userpass NAMECOIN_USER:NAMECOIN_PASS For the Litecoin one: python run_p2pool.py LITECOIN_PASS --net litecoin --bitcoind-rpc-port 11332 --bitcoind-p2p-port 11333 |
|
|
|
What is the recommended way to run p2pool as a service on Windows? I have bitcoind running as a service using BitcoinServiceWrapper (somewhere in the forums), and I would like to do the same with p2pool.
Also, how many peers is the maximum? I obtained 10 peers rapidly, but then it never went any higher than that. Additionally, there is (xxxxx/17381 Verified), which is increasing extremely slowly. What does this number mean? P2Pool only tries to make 10 outgoing connections, so if your port 9333 is not open, that is where it will stay. P2Pool tries to get 2 days of shares (~17280 shares), so that many is normal. It's just the number of shares back that your node knows about. A post sometimes in August mentions a -chart option ... it seems
to have disappeared ?
It was --charts, but now it automatically detects if the dependencies are present and enables it if they are. However, the current release doesn't include very good charts. There's work in progress on better charts and it's visible at http://forre.st:9332/graphs/ . I'd like to run one instance of p2pool and the bitcoin client on a small
non-mining machine and have all my miners get work from there.
Is that possible ?
If so, how can I see per-miner stats in the pool's output ?
Definitely possible. P2Pool by default listens on all interfaces, so you can just point them to the host running P2Pool. P2Pool does not collect per-miner stats yet, though it's a priority and going to happen as part of the new graphs. |
|
|
|
At the risk of sounding dumb, what does FPS mean
and, more importantly, how do I set it properly on cgminer ?
Cgminer does not have a FPS setting. The closest thing is the "intensity" setting, which has the opposite effect. Keep it low (<=8?) or just leave it at the default, which works fine for me. EDIT: Forgot the first part of your question. FPS means frames per second, and is the number of times that your miner updates the work that it is working on every second. A higher FPS means less time between updates, so less time is wasted after a long poll response comes in. |
|
|
|
Just to be clear though....'Shares' don't show up accepted very quickly.......do they ?
I have been keeping an eye on the P2Pool output and I notice a bit of an up/down speed variation at times and a much slower-than anticipated 'Share' acceptance.
......just thought I would ask to be sure.
Yes, the difficulty is currently ~150, so with 4.5GH/s, you should get a share about every 2 minutes and 23 seconds. |
|
|
|
Is there a way to make it working without the need of all the blockchain?
Is it really needed?
Not currently. At some point in the future, the bitcoin client won't need all of the blockchain to run. However, P2Pool will likely always require a Bitcoin client to be present. |
|
|
|
How can i see if merged mining is working? P2pool sometimes logs:
Got new merged mining work! Difficulty: 409454.724619
So I think it should be working, but namecoind shows no balance or transactions.
Any ideas?
As long as it shows that, everything is working. Keep in mind that you're mining solo, and it can be a long time between blocks. You can test namecoin block submission if you run with --debug - you'll get lots of lines saying "MERGED RESULT: False" or "MERGED RESULT: True" if you get a block. I know that at least gmaxwell has recently gotten a namecoin block. |
|
|
|
Just curious : why does p2pool report a number of shares roughly covering 48 hours ? Is it to make it possible to switch to another memory period later or did I misinterpret something else ?
Currently, 48 hours of shares are held in order to make it possible to switch to 24 hours, which will happen in a few days. It requires double the number of shares because an individual share depends on having a history to be verified. If the memory period is 24 hours, we keep the last 48 hours of shares, so we can verify the last 24 hours. |
|
|
|
General notice: All users must be using P2Pool version 0.7.1 or greater before Thu Jan 5 23:11:45 UTC (Unix time 1325805105) (Thu Jan 5 18:11:45 EST). P2Pool is switching from a 12 hour maximum payout period to a 24 hour maximum payout period. but as i see it only those mining the last 24hours get paid.
This is the exepected behaviour. Although I believe you are paid for the last 48 hours at the time a block is found (at least the p2pool client remembers shares for this period from what I can read in its logs). I'm sorry for your loss, bronan... P2Pool has very high variance due to the long time between blocks and the short memory period, which is currently 12 hours, but will switch to 24 hours when the above change takes effect. This should make anyone who mines only during the day (or any other daily period) not be hurt by variance due to the memory period.
|
|
|
|
Only seems to appear when there is "new work for worker".
New version. Bitcoinqt 0.5.1 on Win7x64.
What miner are you using? Poclbm? It does long polls using HTTP GET requests instead of JSON-RPC, which I didn't know. EDIT: The latest commit has a fix for this. |
|
|
|
P2Pool 0.8 - tag: release-0.8 Windows py2exe binary: http://u.forre.st/u/gtrmtyze/p2pool_0.8_d893094.zipSource tarball: https://github.com/forrestv/p2pool/tarball/release-0.8Changes: * Worker interface now caches merkle roots and changes the timestamp to improve latency * Fixes merged mining block submit bug * --debug now submits all merged mining solutions, whether they match the target or not, so it can be tested * Message displayed whenever new merged mining work arrives: 11:29:09.781837 Got new merged mining work! Difficulty: 425748.907476* Some other efficiency improvements for miners * ± display bug fixed
|
|
|
|
What about auto-electing a 'CONGRESS' with like-i-say 100 members,
when a new block was found and a extra funds remain,
send to MULTISIG by all 'CONGRESS' guys ' keys,
when withdraw, auto-vote?
--as you know i can't code, just some thoughts. Is this practical?
This is possible and would be really neat, but it'd be really complex. Also, there are some problems - What if half of the nodes go offline or were reset when it's time to withdraw? I'll think about it more.. |
|
|
|
Hey Forrest, what's up with the first output of your coinbase transaction? It's not a valid scriptPubKey. Is this some kind of p2pool marker tag? Why not put it in the scriptSig if so?
It is indeed a p2pool tag - it's a hash of some data structures that is used to make shares unique. It used to be in the scriptSig, but with the rise of merged mining and miners needing to add their own data to the coinbase, it was simpler to give them complete control over the coinbase contents and make this separate. |
|
|
|
Can you make this pool running SMPPS mode , just like Eligius?
First, there is no way to store extra funds generated during lucky periods, because the pool can't keep any secrets from its users. (Using escrow payments might be possible, but has a lot of pitfalls - nodes could collude to steal pool's savings, nodes could go offline and money is lost forever.) Some sort of hybrid scheme similar to... A substantially different variant [of PPLNS] is to pay for every share at most once. If, when going backwards in the list of shares, we encounter some that were already paid, we skip them and move on to older shares.
...is definitely technically possible, but the size of the history of payments owed would have to be limited to prevent it from growing too large. Also, it would create a much greater reward from attacking the pool - instead of just nullifying the last 24 hours of other miners' work, an attacker with 51% of the mining power could create a separate sharechain stating that he's owed some enormous amount and override the history, forcing miners to pay any payouts during lucky periods to him. |
|
|
|
Ok, i switched to bitcoin 0.5, it seems OK now!
Yes, Bitcoin 0.5.0 is required now. I'll add that to the documentation. but still get some "error like" messages:  Those are normal. There's an old peer mining a couple of shares.. I'll change P2Pool to make it obvious that these errors don't mean that something is wrong. EDIT: Fixed in https://github.com/forrestv/p2pool/commit/59a9680 |
|
|
|
|
Show Posts
