Hi all, I'm a newbie in the BTC/LTC world and I recently found the hard way that exchange and online wallets are not compatible with the type of payout transactions generated by a P2Pool pool (please correct me if I'm wrong or explain why if I'm right). I am very surprised that such an important information it's not printed in bold in the official P2Pool wiki. I cannot edit that page because it's protected but perhaps someone reading this thread has the powers to do so…  The problem really lies with the exchange/web wallet, not P2Pool... and according to Eligius, only Instawallet is broken. However, a warning about which specific ones are broken could of course help people, so I'm not opposed to it. Know of any that are broken besides "ltcinstawallet.com"? |
|
|
|
Have received this error twice now. This is on a DGC p2pool with 30 Mh/s. When the error occurs it stops all mining until the pool is restarted.
Based off of p2pool 13.3. 6 nodes with one having 98% of the hashrate. Any help would be appreciated.
Where's the source for DGC-P2Pool? This seems like it should be impossible with vanilla P2Pool. |
|
|
|
You have to decide what the target is.
For example, if you do 1 trillion hashes, you will get approx
25 difficulty 10 shares
250 difficulty 1 shares (includes the 25 difficulty 10 shares)
Interesting. I thought p2pool already paid out on a prorated basis, based on how difficult your share was, regardless of what the target was? If you just barely limp in over the minimum required difficulty, you get paid a small amount, but if you find a massively high difficulty share (such as a share that's good enough to become a real Bitcoin block) you get paid that much more. You don't get paid the same amount per share, I have noticed. Didn't know it took into account the ability to optionally choose a higher minimum required difficulty, and increased the payout ratio proportionally, to compensate you for your loss from all the little low shares that you've now chosen to throw away instead of submit. What's the ratio that it uses? Let's say I submit 6 shares, at these difficulties: 1, 1, 1, 1000, 1000, 1000. That will pay me about 3003 difficulties worth of work. Now, let's say I change my minimum difficulty to 500. Instead of submitting 6 shares, I submit only 3 shares, at these difficulties: 1000, 1000, 1000. This only pays me about 3000 difficulties worth of work, not 3003. So I have lost a little income here. In case there's something I'm missing. Anybody have the exact formula? Josh How "difficult" a share is depends only on its target. Any share mined around the same time will yield the same contribution to your payout. I say "around the same time", because the minimum difficulty changes to keep it at one share every thirty seconds, and that will affect a share's reward. |
|
|
|
How is initial chain syncing accomplished?
Nodes download the most recent portion of the sharechain from their peers. Only 1 day is kept, so how does a new peer distinguish which is the correct sharechain, since it can't trace back to genesis?
From the wiki: Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 shares (the last day's worth). In order to prevent an attacker from working on a chain in secret and then releasing it, overriding the existing chain, chains are judged by how much work they have since a point in the past. To ascertain that the work has been done since that point, nodes look at the Bitcoin blocks that the shares reference, establishing a provable timestamp. (If a share points to a block, it was definitely made after that block was made.) Mining a sharechain that dies means that you share any winnings, but then there are no later winners to share back with you.
Is there persistence for the sharechain?
Does restart the p2pool daemon mean it has to re-acquire the sharechain from scratch?
Yes, you're mining on the assumption that the pool is not going to disappear while your shares are valid. I'm not sure exactly what you mean with the second question, but the sharechain is persisted to disk, so when you restart your node, it only has to download shares since it was stopped. What are "heads" and "tails" (and what are "verified heads" and "verified tails")?
Why is the difficulty of the sharechain not linked directly to the main chain's difficulty?
Related to that is why not just keep 24 hours worth of main chain blocks?
"Heads" are shares without child shares (leaves of a tree structure). "Tails" are shares without their parent present (roots of a tree structure). The difficulty of the sharechain is unlinked so it can go as fast as possible, which we've empirically determined to be something like 20 to 30 seconds. Keeping 24 hours worth of main chain blocks would require storing an unbounded number of shares in memory, which is a bad idea. |
|
|
|
No that isn't the only difference, the other 2 major problems are:
1) it's python - so it will use more CPU
2) it only uses one thread by default and thus p2pool itself can easily get CPU starved on a machine with 16 cores ...
I'm talking about the Avalon device's CPU. |
|
|
|
|
An Avalon mining on P2Pool with even 3 modules does indeed take its CPU to the limit. The only real difference between P2Pool and other pools is that P2Pool's generation transaction is much larger. I'm guessing that the bottleneck is hashing the generation transaction ~16 times per second (though that isn't much...). If that's true, perhaps cgminer could be optimized to compress everything before the Stratum nonce to a SHA-256 midstate?
|
|
|
|
on that last block that p2pool got:
000000000000000105a6f2c8641caa61f9d678b3ddde4935fefbcae2984e71f7
wtf difficulty would that be? like 400 million?
>>> from p2pool.bitcoin import data
>>> data.target_to_difficulty(0x000000000000000105a6f2c8641caa61f9d678b3ddde4935fefbcae2984e71f7)/1e6
4202.124400192549 4202 million :3 |
|
|
|
rename thread, 2000/2500 GH/s
Done, thanks! |
|
|
|
Nice, 2 more blocks last night while I was asleep ... I got one of them  (my first block in MANY months) Edit: ... and I've spent some time now (since that post) working out why my block sux. It is only 16k and only had 28 txn in it. My bitcoind (default 0.8.3 settings for txns etc except: paytxfee=0.0005) on the other hand at the time had 1854 in it's mempool: 2013-07-25 16:25:43 CTxMemPool::accept() : accepted 7b1f0fd72e281abdb9b6724aa839b872550a3e7ff8de395dfbe20cd92777d4ae (poolsz 1854)
2013-07-25 16:25:43 ThreadRPCServer method=submitblock
.
.
2013-07-25 16:25:44 SetBestChain: new best=000000000000006e312482364ffc008b8fabad506fefde343a1acfc1f64ae982 height=248394 log2_work=70.874866 tx=21101483 date=2013-07-25 16:24:32 progress=0.999995
2013-07-25 16:25:44 ProcessBlock: ACCEPTED
.
.
2013-07-25 16:25:44 CTxMemPool::accept() : accepted c75dd649944be1e262c3c82fda612e29c1631b74b7563f0142e28486623c2217 (poolsz 1828)
... anyone care to explain that before I switch over to some other pool ... it really does look like it's p2pool itself that decided to produce that crap block ... unless I've misunderstood somewhere ... or are there hidden options in p2pool that I need to fix and the default settings suck? P2Pool sometimes has to limit the number of transactions in a block because of per-share tx inclusion limits. Only 50kB of new transactions are allowed per-share, so it takes time the pool of allowed share to build up. |
|
|
|
I'm setting up a p2pool for an altcoin. Mining appears to work well, but I can't get the stat page to display any stats. The stat headings show up, but not the data. The graphs are working. I'm not a python guy, and I'm having a hard time figuring out where to start. There's no errors in the logs. Could someone give a suggestion where to start looking?
You have to wait a while for the chain to get long enough for some of the stats to work, so mine for a few hours first. A screenshot would be helpful. |
|
|
|
I think it has to do with the new “dust payout” elimination feature. It raises the difficulty enough to minimize transaction fees when spending mined coins. It appears you may be able to reduce the share difficulty again by adding “+n” to the miner username, where n is the desired share difficulty. However, you may incur heavy transaction fees in the future when you go to spend the mined coins.
Maybe someone can confirm this for sure. I've been finding it difficult to find detailed p2pool documentation lately for some reason.
You can override the dust-preventing difficulty with the "/" option, which sets the desired share difficulty ("+" option sets desired pseudoshare difficulty). Sorry about not adequately describing the new features. Documenting them will happen. |
|
|
|
I'm doing test mining with versions 13.0-13.1 for two days 2013-07-10 10:47:12.841000 Local: 348kH/s in last 10.0 minutes Local dead on arrival: ~3.8% (2-6%) Expected time to share: 21.4 hours
2013-07-10 10:47:12.841000 Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: 0.0000 LTC
2013-07-10 10:47:12.872000 Pool: 741MH/s Stale rate: 20.0% Expected time to block: 1.4 hours
2013-07-10 10:47:18.778000
2013-07-10 10:47:18.809000 New work for worker! Difficulty: 0.000109 Share difficulty: 6.293200 Total block value: 50.001000 LTC including 10 transact
ions No shares. Expected time may be 1.6 hours then again 1 day. Is it normal? Will I get any shares with p2pool? It is normal. Expected time to share is 1 day, but expected time to block is 1.4 hours. P2Pool is increasing your share difficulty to prevent you from receiving dust payouts. You will get shares if you keep mining. |
|
|
|
how many percent was updated? where can we see? can wait for the switch.
The "desired versions" graph shows this. |
|
|
|
P2Pool release 13.0 - HARDFORK, UPGRADE REQUIRED - commit hash: f3a0e8dfcd872716123771db7900cdcd963b91ce Windows binary: http://u.forre.st/u/xqerwrpk/p2pool_win32_13.0.zipWindows binary signature: http://u.forre.st/u/viejmrru/p2pool_win32_13.0.zip.sigSource zipball: https://github.com/forrestv/p2pool/zipball/13.0Source tarball: https://github.com/forrestv/p2pool/tarball/13.0After 50% of each P2Pool's mining power has upgraded, warnings will be displayed to everyone who hasn't upgraded. Approximately 24 hours after 95% of the mining power has upgraded, the switch will happen. Changes: * Hardfork at 95% upgraded: ** Bitcoin share period increased from 10 to 30 seconds to cater to ASIC miners. Avalon/BFL/ASICMINER devices should start working well after this. ** Litecoin share period increased from 10 to 15 seconds ** Litecoin payouts spread over 3 block-lengths instead of 12, reducing dust payouts ** Transaction pre-forwarding greatly simplified, allowing future network traffic reductions ** Maximum share difficulty multiplier increased from 10x to 30x to give more freedom to below share difficulty adjustments ** OP_RETURN used in last txout to prevent UTXO database spam ** Stratum nonce length increased from 4 to 8 bytes, allowing for future Avalon support without having to use the "avalon" branch * Automatically increase share difficulty to prevent payouts below "dust threshold", 0.001 BTC and 0.03 LTC * Automatically increase share difficulty to prevent any single node from making more than 5% of shares, by default * Worker username parameters (+PSEUDOSHARE_DIFF/SHARE_DIFF) not longer have to be in a specific order * Support for submitblock RPC call in new Litecoin versions * Fixed incompatibility with ASICMINER BE Blade * Updated bootstrap address list
|
|
|
|
Are we supposed to be using the newshare branch from forresv's github or the main one?
Master for now. newshare will be merged in and released very soon. Hey, did you get my private message?
Yes, I did. It looked like all the open files were sockets from miners, so there may not be anything you can do. Do you expect to have hundreds of simultaneous connections from miners? If so, you might want to look at load-balancing over multiple P2Pool instances. If not, someone may be attacking your node by making hundreds of connections to it. Hmm. Can you give me more info about load-balancing? The only things I found about it are load-balancing the network connection, not 2 instances of a process. Also, is it normal that the pool is finding valid shares but Payout if a block were found NOW is stuck at 0, even though fee is set to 2%? Use something like the "balance" program to do TCP load balancing between multiple P2Pool instances. You'll have to start two separate P2Pool instances listening on different worker ports, then use balance to make a public port that round-robins between them. The fee is probabilistic - 2% of shares will go to you, not 2% of every share, so you're probably just unlucky at the moment. |
|
|
|
Are we supposed to be using the newshare branch from forresv's github or the main one?
Master for now. newshare will be merged in and released very soon. Hey, did you get my private message?
Yes, I did. It looked like all the open files were sockets from miners, so there may not be anything you can do. Do you expect to have hundreds of simultaneous connections from miners? If so, you might want to look at load-balancing over multiple P2Pool instances. If not, someone may be attacking your node by making hundreds of connections to it. |
|
|
|
in command line:
ulimit -n 8192
and run p2pool
and check later if errors show.
Open files in linux-like system is also opened connections.
I edited /etc/security/limits.conf with limits of 10000 and I've been running p2pool for nearly 3 hours without a crash. Weird though, because before I upgraded p2pool it was working, even with the limit set at 1024. Maybe it's because more users joined my pool? Who knows.  On the node will tell you how many files p2pool has opened. 1494 files, wow. That's why it was crashing, the limit was at 1024 before. Thanks for the tip! Can you do instead, replacing P2POOL_PID with run_p2pool.py's PID, and pastebin the output and send it to me? P2Pool shouldn't be using that many files - seeing which it has open could help find the issue. |
|
|
|
|
Show Posts
