P2Pool release 8.2 tag: 8.2 hash: 7e823017a508feb861ee05cb163df88cde35b57b Output and web stats page say: Version: unknown How did you get P2Pool? From Git? Pre-built Windows binaries? Github zip/tarball download? Ah, sorry... tarball download from github. I unarchived it then renamed the resulting directory to p2pool. I'm using Linux. Using the tarball doesn't provide any version information except the contained folder's name... and you renamed it, so it couldn't use that. Ordinarily, it extracts to forrestv-p2pool-7aedd00, and P2Pool uses the hash at the end as its version. |
|
|
|
P2Pool release 8.2 tag: 8.2 hash: 7e823017a508feb861ee05cb163df88cde35b57b Output and web stats page say: Version: unknown How did you get P2Pool? From Git? Pre-built Windows binaries? Github zip/tarball download? |
|
|
|
P2Pool release 8.2 tag: 8.2 hash: 7e823017a508feb861ee05cb163df88cde35b57b HARDFORK: Upgrade is required! Hardfork will happen after 95% of the pool's hash rate has upgraded. Everybody having not upgraded will be split off into a tiny P2Pool. Windows binary: http://u.forre.st/u/fgwamcsu/p2pool_win32_8.2.zipSource zipball: https://github.com/forrestv/p2pool/zipball/8.2Source tarball: https://github.com/forrestv/p2pool/tarball/8.2Changes: * Transaction preforwarding Transactions that you're mining are sent to peers before you get a share, so any block solution you find can be broadcast virtually instantaneously. This could theoretically get our invalid block rate below any other pool's thanks to our large network of nodes. * Added some additional data to web stats viewer. * Added network traffic graph.
|
|
|
|
|
The main flaw I see is that it wouldn't decrease variance optimally - you only have your friends mining for you, as opposed to the entire pool. You'd have to be communicating with every other pool member, exchanging PoWs, to reach the same low levels of block-finding variance, which would result in O(n^2) scaling. This may be fixable by making it so some nodes can proxy work for others - combine lots of small exchanges into some large ones, though this would probably require trusting them.
As an aside, while reading this thread I couldn't help but think "This approach is to P2Pool as Ripple is to Bitcoin." Not sure whether that's a good or a bad thing.. Ripple is undoubtedly more scalable than Bitcoin.
|
|
|
|
Why am I seeing this repeatedly in my console? 2012-10-01 20:31:14.959000 Sending 0 shares to 92.251.166.251:58565
It's just a peer requesting a share you don't have, potentially on purpose to measure ping times: http://forre.st:9332/pings |
|
|
|
V5 still seems to have problems with memory leaks, seems more to be an issue with how it talks to .7 bitcoin qt as when it happens, both start to consume HUGE amounts of memory. run_p2pool will start blasting lost connection messages or scrolling this message constantly
eventually it'll use up all available ram and blow up.
Aseras, running p2pool with the --debug option and sending me the log might help. It looks like it's leaking sockets for some reason.. |
|
|
|
I run p2pool, it returns
...
what's the red box means?
Thus, the miner works at normal speed, but accept is 0, p2pool's Local is also 0,
and there's no show at p2pool.info_active users
bitcoin-qt's datadir is at D:\bitcoin\
how to solve the problem?
thanks
The red box isn't unusual.. It just means that querying bitcoin for something timed out, but unless it's happening all the time, it's harmless. Local may be displayed as 0 if you're mining to a non-default address, because you've set your miner's username to a Bitcoin address. This isn't recommended - instead you should use P2Pool's -a option. If you need to use the username way, you can look at the graphs on http://127.0.0.1:9332/ to get some information. |
|
|
|
|
kjj: No, not really; you'll eventually start getting spammed warnings about needing to upgrade to v5 when 50% of everyone else upgrades to v5, but there's nothing essential there as long as you are actually running Bitcoin 0.7.0.
|
|
|
|
P2Pool release 5.0 tag: 5.0 hash: 11b050873e2a77869fdf4f86d2a9cb14e6dd2966 Windows binary: http://u.forre.st/u/tskucpih/p2pool_win32_5.0.zipSource zipball: https://github.com/forrestv/p2pool/zipball/5.0Source tarball: https://github.com/forrestv/p2pool/tarball/5.0Changes: * This release requires users to upgrade to Bitcoin 0.7.0 in order to support BIP 0034 (block versioning). (It increments the share version to 5 in order to do this.) * BIP 0022 (getblocktemplate) support Sorry about the confusion with versions 4 and 5. Version 4 was the first to support BIP 0034 and getblocktemplate, but now version 5 requires a bitcoind that supports BIP 0034 (Bitcoin 0.7). Neither of those two versions were actual announced releases (until now).
|
|
|
|
forestv - how did you find this? Was it by accident or inspired?
First, some background: P2Pool could theoretically use the normal merged mining standard to store the reference to its own data in the coinbase. However, the standard is flawed in several ways and requires that you have the entire coinbase transaction to validate it. P2Pool uses something similar of my invention - it stores a merkle root at the end of the coinbase transaction by integrating it into a fake txout. Then, you can prove that the merkle root is in the coinbase transaction using only O(1) data by sending the SHA256 midstate of all the data preceding the merkle root. I'd like to write up a specification for this at some point, because I believe that O(1) MM proofs are pretty useful. I was thinking about the consequences of someone including multiple different merged mining references (something that is prevented in the original MM implementation by the chain id stuff) under one root when I realized that the merkle root function Bitcoin uses isn't nearly one-to-one. From there, I noticed that you could duplicate transactions while maintaining the block hash, wondered how Bitcoin would react to that, and remembered that Bitcoin stores unvalidated orphan blocks... Here's the original proof of concept code, untouched since April 29/30: http://u.forre.st/u/gkwobmns/poc.zip You have to run the programs using "trial" - they were P2Pool testcases that I grabbed and reused. |
|
|
|
Since at least 80% of the Bitcoin network is now protected against this attack, I've been given permission to disclose it: The Merkle hash implementation that Bitcoin uses to calculate the Merkle root in a block header is flawed in that one can easily construct multiple lists of hashes that map to the same Merkle root. For example, merkle_hash([a, b, c]) and merkle_hash([a, b, c, c]) yield the same result. This is because, at every iteration, the Merkle hash function pads its intermediate list of hashes with the last hash if the list is of odd length, in order to make it of even length. And so, the Merkle root function can be effectively preimaged by changing the input so that one of the intermediate lists is of even length with the last two elements equal (where originally it was of odd length with a last element equal to the earlier mentioned two). As was later noted, this extends to any input length that is not a power of two: merkle_hash([a, b, c, d, e, f]) == merkle_hash([a, b, c, d, e, f, e, f]). Note that to maintain the same root hash, the only flexibility that exists is duplication of elements. As a result, two blocks can easily be created that have the same block hash, though one can be valid and the other invalid, by duplicating one or more of the transactions in a way that maintains the Merkle root hash. Duplicating any transaction will make the block invalid, since the block double spends a certain past transaction output. An unpatched Bitcoin installation can be permanently wedged at its current highest block using this and the fact that Bitcoin caches orphan blocks in a disk-backed database. To do so, the attacker must send it a valid block (that will eventually make it into the blockchain) made invalid by duplicating one of the transactions in a way that preserves the Merkle root. The attacker doesn't even need to mine their own block - instead, they can listen for a block, then mutate it in this way, and pass it on to their peers. Once the victim receives this invalid block, they will cache it on disk, attempt to process it, and reject it as invalid. Re-requesting the block will not be even attempted since Bitcoin believes that it already has the block, since it has one with the same hash. Bitcoin eventually displays the "WARNING: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade." warning when the blockchain extends further beyond the received invalid block. The problem was fixed by Gavin Andresen in Bitcoin commit be8651d [1] by rejecting blocks with duplicate transactions in CheckBlock, preventing them from being cached at all. Cheers, Forrest Voight http://forre.st/[1]: https://github.com/bitcoin/bitcoin/commit/be8651dde7b59e50e8c443da71c706667803d06d |
|
|
|
The + option (pseudoshare difficulty) is indeed disabled for the Bitcoin P2Pool due to me being paranoid, though that shouldn't be a large issue. The other option (/) doesn't seem to be currently implemented anywhere (I PMd forrestv to find out about this)
The / option (share difficulty) is still there, though: In work.py: desired_share_target = 2**256 - 1
if '/' in user:
user, min_diff_str = user.rsplit('/', 1)
try:
desired_share_target = bitcoin_data.difficulty_to_target(float(min_diff_str))
except:
pass
... desired_timestamp=int(time.time() - self.current_work.value['clock_offset']),
desired_target=desired_share_target,
ref_merkle_link=dict(branch=[], index=0),
I urge larger miners to use /3000 or higher in order to keep the variance down for smaller P2Pool miners. This will increase the difficulty of your shares to 3000, but each share is worth proportionally more. Simply append /3000 to the end of your miners' usernames. This will keep share difficulty (and consequentially, variance) low for small miners. Also, don't worry, because no value is too high for either pseudoshare (+) or share (/) difficulty. P2Pool will ignore values of + that would cause it to drop shares otherwise, and the / value is capped at 10x the current minimum(default) share difficulty. |
|
|
|
Just started using p2pool again today and I have a quick question. Does the --p2pool-node flag support DNS lookups or can it only do IP addresses? I have a friend nearby that I'd like to be always connected to, but he has a dynamic IP.
DNS lookups should definitely work. If they fail, P2Pool should print an error while starting up. A few of the bootstrap nodes, including mine, use domain names instead of IP addresses. I changed my bitcoin-qt datadir to E:\Users\xxx\AppData\Roaming\Bitcoin\,
then run:
run_p2pool --datadir E:\Users\xxx\AppData\Roaming\Bitcoin -a myaddress
it returned:
run_p2pool: error: Bitcoin configuration file not found. Manually enter your RPC password.
If you actually haven't created a configuration file, you should create one at C:\Users\xxx\AppData\Roaming\Bitcoin\bitcoin.conf with the text:
server=1
rpcpassword=........
I of course had created the file at E:\Users\xxx\AppData\Roaming\Bitcoin\bitcoin.conf,
so what's the matter?
The problem was that P2Pool is looking on the C: drive, but your Bitcoin files are apparently on the E: drive? Anyway, you already solved it. |
|
|
|
I think the best solution is increasing the increment that P2Pool does from 12 to something huge (100?) is best. Roll-Ntime helps a lot because it lets the mining software generate enough work to feed all the GPUs with the single long poll response that P2Pool sends. P2Pool rolling the timestamp itself also helps a lot because it lets P2Pool not regenerate the merkle root which (at least now) is relatively slow, so P2Pool can broadcast the same work to every miner daemon that you have without having to regenerate it, which especially helps latency on long polls.
I doubt that any miner is ever going to roll the timestamp more than 100 seconds (this would only happen if they have more than 100 GPUs, I think?), so this preserves the benefits of rolling the timestamp in both ways. Adding a sanity check that warns if miners are rolling >90 seconds would let us know if there's anything wrong with this.
That sounds like a hack to me  How about miner specific addresses? Would that solve the problem, and if so why is it a bad idea? Wouldn't you want to distort the block timestamp as little as possible? Having different addresses forces the generation transaction and merkle root to be regenerated, with all the latency that that creates. It's equivalent to simply removing P2Pool's timestamp rolling and leaving X-Roll-Ntime in. The block timestamps aren't very important - as long as they're centered around the correct time and within the bounds of Bitcoin's protocol rules, you can change them as much as you like. They're only really used by Bitcoin to recalculate the difficulty every 2016 blocks, and small changes won't affect that. |
|
|
|
I would think you're better off making p2pool not roll ntime and leave it to the mining software.
I'm basically with this, but I'm not sure how to achieve it. There seem to be no consensus on what expire=10 actually means. I guess (and it is just a guess after looking at the code) the reason p2pool does it this way is because two different miners must be given unique work, and the way it does it - since the merkle root is the same - is by giving 10 second timstamp intervals to work on, assuming the expire=10 makes the miner ask for more instead of rolling past 10 seconds. This assumption is false though, which is the problem. Now with miners rolling on their own, the load on the server would be smaller but since each miner will be working on the exact same work, the clashes will return in a different form, if you have more than one miner connected. Not a good solution... I think the best solution is increasing the increment that P2Pool does from 12 to something huge (100?) is best. Roll-Ntime helps a lot because it lets the mining software generate enough work to feed all the GPUs with the single long poll response that P2Pool sends. P2Pool rolling the timestamp itself also helps a lot because it lets P2Pool not regenerate the merkle root which (at least now) is relatively slow, so P2Pool can broadcast the same work to every miner daemon that you have without having to regenerate it, which especially helps latency on long polls. I doubt that any miner is ever going to roll the timestamp more than 100 seconds (this would only happen if they have more than 100 GPUs, I think?), so this preserves the benefits of rolling the timestamp in both ways. Adding a sanity check that warns if miners are rolling >90 seconds would let us know if there's anything wrong with this. |
|
|
|
I guess you are right. Then my only idea is the caching of work in WorkerInterface. Can someone shed some light on that?
The work caching preserves the merkle root, but advances the timestamp by 12 seconds every time. It may be possible that CGminer is advancing the timestamp more than that (ignoring the X-Roll-NTime header, which is set to "expire=10"), and so redoing work. EDIT: I'm going to add a check to P2Pool that warns about improperly rolled work. If anyone _ever_ sees this warning, we'll know that something is broken. On the other hand, maybe CGminer retries submitting work before the original work submit is finished if it's slow? That would mean that there's no work actually being lost. I should really just look at the code... I use CGminer and almost never see this message. Is there anything special about the mining rigs that this happens to? How many GPUs do they have? |
|
|
|
Yep, update to 2.7 and install twisted and zope  I'm running 2.7.2 and twisted is installed. I'll try zope edit: zope is only for windows? i'm on OS X Lion Your Twisted is too old. It's not Python. |
|
|
|
2 nights ago i upgraded to the newer version and now on the stats page my Hash rate is listed as only 7 yet GUminer still says 61.
Can you give a screenshot of the stats page? If you look at the P2Pool console, it says that you have 43MH/s running. (The number after "Local:") |
|
|
|
Those are P2Pool stales, which don't directly affect block finding. odd forrest is at 3.0
Fixed |
|
|
|
|
Show Posts
