[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[windpath]

P2Pool.org - Now hosted on Github Pages!

I just moved p2pool.org over to Github pages, I'll save a few bucks on hosting, and now it's easy for anyone to contribute.

I'd love some help!

Some areas that could use improvement:

- Some of the links are out of date or broken
- Copy changes or additions welcome

And the big one:

The site was pretty much thrown together in a day, and the whole thing is a single HTML page using modals rather then traditional navigation, if anyone wants to fork it and redesign it with more traditional navigation and separate html pages for different content sections that would be just awesome!

The repo is: https://github.com/ChainQuery/p2pool.org/

The site lives in the 'gh-pages' branch: https://github.com/ChainQuery/p2pool.org/tree/gh-pages

Really hoping to get some folks to jump in and help out For anyone serious about helping that would like commit access, PM me.

http://p2pool.org

[1713496816]

1713496816

[1713496816]

1713496816

[1713496816]

1713496816

[yslyung]

WoW looks like things are moving fwd. thx windpath for putting up your effort, extra time & commitment towards p2p.

let's hope it'll expand further & attract more miners to come join us.

[windpath]

Awesome! Already had our first commit with some fixes from Rav3nPL, thanks!

As he has been around a while (longer then I anyway), is a contributor to the main source, and maintains a branch with support for many alt-coins, he now has commit access as well.

I also added ForrestV if he would care to contribute...

Edit: Also changed the default branch to gh-pages, so https://github.com/ChainQuery/p2pool.org resolves to the site branch.

[p3yot33at3r]

Yup, bit of a whizz is our Rav3nPL 

This is great stuff windpath - kudos.

[yslyung]

Awesome! Already had our first commit with some fixes from Rav3nPL, thanks!

As he has been around a while (longer then I anyway), is a contributor to the main source, and maintains a branch with support for many alt-coins, he now has commit access as well.

I also added ForrestV if he would care to contribute...

Edit: Also changed the default branch to gh-pages, so https://github.com/ChainQuery/p2pool.org resolves to the site branch.

http://p2pool-nodes.info/ is listed on the site but it ain;t working anymore.

looks like the hunt for 3rd block of the day has just begun.

[Carlton Banks]

Has there been any word from forrestv as to weather this new "XT" client is actually compatible with p2pool with it's different block size params?

I'm using XT. Working good here. Still looking into what it actually patches and how it effects mining. Any info would be appreciated.

I wonder how this will change mining? Would it give Big pools a bigger advantage?
I know KNC are supporting it and that's one of there biggest sponsors.
Of course Bitmain is for this too.
Coming to a hard-fork means I'm supporting it at the moment.
"ChinaPool" is definitely going to kick it's weight around if this flies or not.
How do you feel about this please share.

XT is compatible now. It will not be compatibile after the arranged fork date (January 11th 2016)

The main change is it implements BIP 101, Gavin Andresen's proposal to increase the blocksize limit to 8MB, followed by a doubling of that limit every two years until a final target limit of 8 gigabytes is reached in the year 2033.

Other significant changes are:

• Longest chain no longer wins, chain validity is determined using checkpoints periodically added by the XT devs to the code
• Tor nodes are deprioritised from connection as an anti-DOS measure
• Permitted Tor exit nodes are, at present, hard coded into the XT client

As p2pool miners, I would investigate the implications of the blocksize changes, and also of the changes to the chain consensus rules.


Also be aware: this model of absolute blocksize limits isn't a very good one (it worked well up to now, but it is true that we are beginning to "run out of road" using this paradigm). A dynamic limit of some type is perhaps a better option, but I am also interested to hear any other concepts that haven't yet been given an airing. There is a productive discussion (no, really!) going on in the Development and Technical sub (https://bitcointalk.org/index.php?topic=1154536.0). Here's what I had to say about this in another thread:

"Is it really such a great plan to make predictions about what technology we'll be running the bitcoin network on, decades into the future? I would argue that as we approach the steeper part of the curve of technological progress, making accurate predictions will become increasingly more difficult. Perhaps it is worth taking an optimistic view of progress when conducting some aspects of long term planning. But when you're designing something vital, prudence and conservatism is a much more appropriate strategy. Only the absolute basics in life are more vital than monetary systems."

[p3yot33at3r]

Has there been any word from forrestv as to weather this new "XT" client is actually compatible with p2pool with it's different block size params?

Forrestv - if you're lurking, it would be interesting to hear your point of view 

[Meuh6879]

http://p2pool-nodes.info/ is listed on the site but it ain;t working anymore.

looks like the hunt for 3rd block of the day has just begun.

use this : http://nodes.p2pool.co/

[jonnybravo0311]

XT is compatible now. It will not be compatibile after the arranged fork date (January 11th 2016)

The main change is it implements BIP 101, Gavin Andresen's proposal to increase the blocksize limit to 8MB, followed by a doubling of that limit every two years until a final target limit of 8 gigabytes is reached in the year 2033.

Other significant changes are:

• Longest chain no longer wins, chain validity is determined using checkpoints periodically added by the XT devs to the code
• Tor nodes are deprioritised from connection as an anti-DOS measure
• Permitted Tor exit nodes are, at present, hard coded into the XT client

As p2pool miners, I would investigate the implications of the blocksize changes, and also of the changes to the chain consensus rules.

Great points Carlton.  Using XT means you are implicitly accepting all of the changes it brings to the table - not just the increased block size from BIP101.

I also agree that setting arbitrary limits like the ones proposed in BIP101 provides an artificial barrier that may or may not need to be changed as technology progresses in the future.

[Carlton Banks]

Great points Carlton.  Using XT means you are implicitly accepting all of the changes it brings to the table - not just the increased block size from BIP101.

I also agree that setting arbitrary limits like the ones proposed in BIP101 provides an artificial barrier that may or may not need to be changed as technology progresses in the future.

Thank you, although I must point out that the text of mine that you quoted are the facts as I perceive them, not any kind of arguments.


The part of my post you didn't quote are my opinions about how to strategise for the future growth of Bitcoin, although I hope you might consider those to be good points. I would be interested to hear anybody elses views on such matters also, debating on the main board about these issues is tough when you have to explain alot of the details.

[p3yot33at3r]

Looks like p2pool's recent outstanding luck has bought a big player back - currently at over 2.5Ph/s 

[forrestv]

Has there been any word from forrestv as to weather this new "XT" client is actually compatible with p2pool with it's different block size params?

Forrestv - if you're lurking, it would be interesting to hear your point of view 

If the fork to 8MB blocks happens, P2Pool will require changes to support 8MB blocks and its own fork to get everyone using the changes. That said, it's a ways off and the changes should be pretty straightforward.

[yslyung]

Has there been any word from forrestv as to weather this new "XT" client is actually compatible with p2pool with it's different block size params?

Forrestv - if you're lurking, it would be interesting to hear your point of view 

If the fork to 8MB blocks happens, P2Pool will require changes to support 8MB blocks and its own fork to get everyone using the changes. That said, it's a ways off and the changes should be pretty straightforward.

let's hope there will an earlier warning compared to the last one so that everyone on p2p will have ample time to switch over. would be also great to see some improvements.

in the meanwhile, whereisblock ?

[squidicuz]

XT is compatible now. It will not be compatibile after the arranged fork date (January 11th 2016)

The main change is it implements BIP 101, Gavin Andresen's proposal to increase the blocksize limit to 8MB, followed by a doubling of that limit every two years until a final target limit of 8 gigabytes is reached in the year 2033.

Other significant changes are:

• Longest chain no longer wins, chain validity is determined using checkpoints periodically added by the XT devs to the code
• Tor nodes are deprioritised from connection as an anti-DOS measure
• Permitted Tor exit nodes are, at present, hard coded into the XT client

As p2pool miners, I would investigate the implications of the blocksize changes, and also of the changes to the chain consensus rules.


Also be aware: this model of absolute blocksize limits isn't a very good one (it worked well up to now, but it is true that we are beginning to "run out of road" using this paradigm). A dynamic limit of some type is perhaps a better option, but I am also interested to hear any other concepts that haven't yet been given an airing. There is a productive discussion (no, really!) going on in the Development and Technical sub (https://bitcointalk.org/index.php?topic=1154536.0). Here's what I had to say about this in another thread:

"Is it really such a great plan to make predictions about what technology we'll be running the bitcoin network on, decades into the future? I would argue that as we approach the steeper part of the curve of technological progress, making accurate predictions will become increasingly more difficult. Perhaps it is worth taking an optimistic view of progress when conducting some aspects of long term planning. But when you're designing something vital, prudence and conservatism is a much more appropriate strategy. Only the absolute basics in life are more vital than monetary systems."

Thank you.

The changes to the consensus rules are appalling, as well as some of the other features of Bitcoin XT.
BIP101 may be an answer, but there could be a better solution that we can all stand behind.  We must work to all agree on a plan for the future that scales and doesn't divide us.  A solution that everyone can support will eventually be found.

[p3yot33at3r]

Has there been any word from forrestv as to weather this new "XT" client is actually compatible with p2pool with it's different block size params?

Forrestv - if you're lurking, it would be interesting to hear your point of view 

If the fork to 8MB blocks happens, P2Pool will require changes to support 8MB blocks and its own fork to get everyone using the changes. That said, it's a ways off and the changes should be pretty straightforward.

Thanks forrestv - good to hear your point of view. Having said that, I am totally opposed to the new Bitcoin XT client for a few reasons, one of which I pointed out on a different thread:  https://bitcointalk.org/index.php?topic=1157317.0

ie: Hard coded TOR exit nodes hand picked by "someone" is a massive security danger to anyone using them. I definitely won't be using the XT client.

[windpath]

http://p2pool-nodes.info/ is listed on the site but it ain;t working anymore.

looks like the hunt for 3rd block of the day has just begun.

use this : http://nodes.p2pool.co/

This has been updated.

[luthermarcus]

Just checked on my node and I haven't received a share for a while and my payments are going down using XT.
Since I changed nothing else I'm assuming it has something  to do with the new default settings in XT.
Yea I have to figure out how to revert back now. I really wish i could do this without reinstalling bitcoin core over and waiting for the blockchain to download.


Update: Seems like after restarting things went back to normal.

[TheRealSteve]

I really wish i could do this without reinstalling bitcoin core over and waiting for the blockchain to download.

I don't know about whatever P2Pool issues you may be facing - but you can install XT over Core and Core over XT and just have them use the existing block chain data files - no need to re-download it all.

[yslyung]

Just checked on my node and I haven't received a share for a while and my payments are going down using XT.
Since I changed nothing else I'm assuming it has something  to do with the new default settings in XT.
Yea I have to figure out how to revert back now. I really wish i could do this without reinstalling bitcoin core over and waiting for the blockchain to download.

could be the sudden BIG hashrate that showed up snatching some shares & shares do expire in p2p after some time.

when hashrate goes up, min p2p share difficulty goes up too & it is more difficult to get a share if your hashrate is too low.

maybe you can try to use YOUR_BTC_ADD/1 ... "/1" tells the node to give your miner min p2p share diff instead of high diff but high diff shares is more valuable but min share diff enables you to get more share.

also try to point your miners to the closest node to you as latency plays a BIG role in p2p.

stand to be corrected.

[luthermarcus]

Just checked on my node and I haven't received a share for a while and my payments are going down using XT.
Since I changed nothing else I'm assuming it has something  to do with the new default settings in XT.
Yea I have to figure out how to revert back now. I really wish i could do this without reinstalling bitcoin core over and waiting for the blockchain to download.

could be the sudden BIG hashrate that showed up snatching some shares & shares do expire in p2p after some time.

when hashrate goes up, min p2p share difficulty goes up too & it is more difficult to get a share if your hashrate is too low.

maybe you can try to use YOUR_BTC_ADD/1 ... "/1" tells the node to give your miner min p2p share diff instead of high diff but high diff shares is more valuable but min share diff enables you to get more share.

also try to point your miners to the closest node to you as latency plays a BIG role in p2p.

stand to be corrected.

I was considering a the higher hashrate but that doesn't explain why i haven't had a share for 24 hours. The difficulty I use for my miners should be the ok because of past experience. I think that they changed the default blocksize to current max which why it was taking longer to get a share because at first started off great was grabbing shares like normal then I check on it a day later and the orphan rate shot up. The next day the stats haven't changed so I recently restarted it seems to be doing better but I'm keeping an eye on it. You may be right about the latency because the blocksizre increase to the full 1mb is by default on XT but I get anywhere from 100 to 160MB/s which i think is really fast latency shouldn't be an issue unless comcast is fucking something up like they do. Maybe I'm overlooking something else they changed hope a reset is all my miner, node and bitcoin needed.
I did what you said too I let it kick to the backup node and my payout started to go up while I reset XT.

Update: Seems like after restarting things went back to normal.