Q: how you will deal whit botnets ?
Sorry, was writing a reply to this but lost it somehow. A botnet would have to simultaneously overwhelm the bandwidth of all the P2Pool nodes in order to prevent mining from taking place. This would get more and more difficult as the number of people using P2Pool grows. Also, there is a way to prevent this: People can connect to only trusted nodes, so their IP isn't advertised to be DoS'd. They could have two internet connections and make the trusted connections over one and the untrusted ones over another, if they want. |
|
|
|
Great! Although, my actual payout is nowhere near the estimated payout. The 'Payout if block' estimate is the number that you'd get if _you_ solved the block. There is a 0.25 BTC reward that goes to the solver, and that number includes it. You didn't solve the block this time, so you didn't get it. This was an oversight from when the p2pool hashrate was low, and a .25 BTC difference in the payout wasn't obvious... Sorry, working on a patch for that now. |
|
|
|
- Dropping of old shares - p2pool's memory usage no longer grows slowly over time
How about disk usage? I stopped running p2pool since shares.dat grew to 1.8GB! I did not expect this. That was completely fixed - p2pool now uses numbered files named bitcoin_shares.### and deletes old ones automatically. |
|
|
|
Another doubt is: what happens with all of yesterday's work? It's remembered by the network and will be payed if a block is found, or it's wasted?
It's forgotten. p2pool pays the last N shares (PPLNS payout method, used by several other pools too), which is provably fair and invulnerable to pool hopping. It does seem kind of unfair now, but once p2pool grows to get one block per day, all work will get a payout. So everytime I stop the pool -let's say to launch the latest git version, or to change the payment address- I lose all work of every worker? I think that this has to be worked out. I understand PPLNS, and let's say that I agree with its fairness. Anyway, downtimes will always happens, and I think that that work shouldn't be wasted. Ah, sorry, no! Your work is remembered in the sharechain that all nodes hold. However, that sharechain is only 17280 shares (~1 day) long, so your contributions fall off the end after about a day. Restarting the program doesn't affect this. |
|
|
|
Hi. I'm trying p2pool and I have some doubts. Last night I left it working on a server, with a couple of client miners, and this morning I found it was frozen. It seems that it got frozen after 12 hours of being running, or something like that...
Somebody else has experienced this kind of problem?
There was no logs useful for tracing the problem. It was just hanged somewhere on the normal loop, and I have had to SIGKILL the process and launch it again.
I'm guessing you're on Windows? I haven't been able to reproduce this problem. However, if you run p2pool with --debug, it will produce a lot more messages and log them all to debug.log, which might be useful. Another doubt is: what happens with all of yesterday's work? It's remembered by the network and will be payed if a block is found, or it's wasted?
It's forgotten. p2pool pays the last N shares (PPLNS payout method, used by several other pools too), which is provably fair and invulnerable to pool hopping. It does seem kind of unfair now, but once p2pool grows to get one block per day, all work will get a payout. And last. When the logs says: "Payout if block: x BTC"
That amount is what will be payed if my node finds the block or it's the payment without counting the subsidy?
That exact amount would be paid to you if the pool found a block at this moment. |
|
|
|
New version! fbedaf9 Windows binary: http://u.forre.st/u/weclcaad/p2pool_win32_b324a68.zipSee first post and the wiki for instructions. Major changes: - Namecoin and Ixcoin support! Use --net=namecoin or --net=ixcoin
- Dropping of old shares - p2pool's memory usage no longer grows slowly over time
- Caching of shares and block headers on disk - after starting p2pool, it's ready to mine in less than a minute
- Display of median stale rate for users and individual efficiency - no more worrying about stales
- Improved communication with miners - less stales
- Removed resource leaks and huge bandwidth usage under some configurations due to UPnP
- Work isn't given to miners if bitcoind dies
- Miscellaneous memory and speed improvements
- Reopens debug.log on SIGUSR1 for log rotation
Join the #p2pool channel on Freenode for discussion! |
|
|
|
Well I'm no expert on the code, but MAX_MONEY is still set to 21000000 in main.h, so unless I'm missing something it's still capped at the same amount.
That constant does almost nothing. All it limits is the amount of money that can change hands in a single transaction, not the total amount of money in circulation. That thread is incorrect in stating that blocks will begin being rejected. Things will continue past 21 million IXC as usual, unless one person happens to hold half of the money. The point I was trying to make here is that Ixcoin's fundamental reason for existing (at least, the publicly stated one) isn't actually real, but it's still documented as such in the forum posting and the Ixcoin FAQ. What's wrong with re-raising the issue here? It seemed rather important to me. |
|
|
|
There are currently ~7M (as of August 2011) in existence and it is expected that all 21 million Bitcoins will have been generated by 2033. Whereas there are currently ~580K Ixcoins (as of 10th August 2011) in existence and it is expected that all 21 million Ixcoins will have been generated by 2015. This is because 16*6=96 IXC are created per new block, instead of 50 BTC in Bitcoin.
Ixcoin maturity will be reached ~18 years before Bitcoin's. By mid-2013, the number of IXC and BTC will reach parity (for a brief moment). Ixcoin does not actually have a "shorter maturation period", as stated as the reason for forking Bitcoin. Did nobody wonder why the 'total ixcoins over time' graph suddenly just stopped? Or did everybody just accept the fact that this is a futureless blockchain, designed to be abandoned once its creators had gotten rich?  The truth is that the "developer" here just increased the block reward from 50 to 96, without changing the decay factor, which halves the reward every 210000 blocks (or ~4 years). Instead of a total of 21,000,000 IXC being created, there will be 40,320,000 IXC in the end. The graph should look something like this:  Draw your own conclusions. Relevant source code: https://github.com/ixcoin/ixcoin/compare/f08736405e98d0f16ec2...b721315ff7adf959e76a#L43L637 |
|
|
|
New release! fbedaf9 Major changes: - Miners can connect with a Bitcoin address as the username to direct payouts to that address - set up a public node and invite people to mine on it!
- Drawing of share chain - use option --charts and go to http://127.0.0.1:9332/chain_img
- UPnP support - automatic port forwarding to help the P2P network
- IP transactions work
- Peer count displayed on status line
- Forward compatibility for merged mining
- Two new bootstrap nodes
- Better version detection
- Reduced CPU usage
Binaries are on the first post. EDIT: If you have multiple mining clients make sure they have unique usernames. p2pool internally tracks the state of miners by their usernames, and you will get a lot more stales if they are confused. |
|
|
|
|
On behalf of picchio:
330MH/s
|
|
|
|
|
On palsecam's behalf:
I "offer" 300+ MHash/sec to the pool.
|
|
|
|
In order to sidestep the chicken-and-egg problem of bootstrapping a mining pool, in this thread people can promise to put a certain amount of hashing power on the p2pool network when the total pledged is high enough. Background: P2Pool is a decentralized pool that works by creating a P2P network of miner nodes. These nodes work on a chain of shares similar to Bitcoin's blockchain. Each node works on a block that includes payouts to the previous shares' owners and the node itself. There is no central point of failure, making it DoS resistant. Forum thread | P2Pool wiki page | GitHub project page'High enough' should be around 30GH/s, but this is open to discussion. 30GH/s results in an average time-to-first-block of 3 days, with the 50% and 95% percentiles being 2 days and 9 days. Once the agreed upon amount is reached, I'll signal everyone to begin on this thread. If you're already mining on p2pool, put your pledge in anyway so we can have an accurate total. Sum so far: 25.68GH/s --- I pledge the 410MH/s that I'm already mining with. |
|
|
|
last update gives me 50 rejects from 60 submited shares using cgminer
Hm ... there might have been a regression, though I'm testing cgminer right now, and while it does worse than poclbm (~15% stales), it's nowhere near what you report. Are you talking about the stales that cgminer tells you or the stales that p2pool reports? Can you paste a few lines from both cgminer and p2pool? And try running p2pool with '--debug' for a while and then upload the 'debug.log' file somewhere? Thanks, sorry! EDIT: Are you using multiple pools? burp_ reports that that can cause problems with cgminer and long polling. Also, cgminer doesn't check shares against the actual target, it just submits all difficulty-1 shares, so getting up to half rejected on the miner and lots of 'Invalid share' messages in p2pool is normal for it. You're not losing any work. Want to get on IRC? #p2pool on freenode if you're interested ... |
|
|
|
New important release! - please upgrade! 9037c07 - New best-share selection strategy - will reduce stales, but everyone needs to upgrade!
- Worker interface improvements that should also reduce stales (including added information about several additional miner daemons)
- Miscellaneous interface improvements and code cleanups
Please upgrade to keep the p2pool network healthy!  The Windows EXE on the first post has been updated. EDIT: I'm getting ~5% stales on the miner using poclbm with the patch on the first post: ./poclbm.py http://9dfa:ada@127.0.0.1:9332 --verbose -d1 -f 100 -w 128 -v
...
127.0.0.1:9332 29/07/2011 05:23:49, [395.838 MH/s (~319 MH/s)] [Rej: 5/134 (3.73%)]
|
|
|
|
Throwing away current work every 5 seconds doesn't seem very efficient to me. What about increasing the block rate? By using p2pool I'm basically wasting more than 30% of my hashing power. ( Reject ratio: 28.7 )
What miner and p2pool version are you using? Did you look at the updated information about miners on the first post? By using that I've consistently been able to get <10% stales with all the different miners. I'm currently working on improving p2pool and the patches to the miners to decrease the reject ratio ... should have some new results in about an hour to further reduce it. |
|
|
|
All problems relating to stales are fixed if you get the newest p2pool version from http://forum.bitcoin.org/index.php?topic=18313.0 and pay attention to the 'Miners' section there. cgminer works as is, but the other major ones need a patch (which is there for all of them) Memory usage is significantly decreased in the latest release, so I think that with this, it's ready to take off! |
|
|
|
New release! a07e25c Changes: - Memory reduction - p2pool now takes 40% less memory!
- p2pool now adjusts to the specific miner daemon using its User-Agent header - less stales
- Share downloading is smarter - faster, more robust sharechain downloads
- p2pool doesn't distribute work until the sharechain is downloaded - elimination of those confusing stales you get when p2pool is starting
- Some minor interface changes: exception reporting, share notification lines
|
|
|
|
|
Show Posts
