Topic: Pools should state their position on maximum block size increase issue. (Read 649 times)
August 18, 2015, 06:25:06 PM
I suspect the bulk of the pools feel the way Kano and I do: We're all in favour of bigger blocks but most of us don't want XT and are not adopting it. We're waiting in the vain hope core dev gets off its arse and increases block size itself.
August 18, 2015, 09:51:01 AM
For p2pool, it is up to the node operator on whether or not to support XT. This is of course assuming that forrestv's code can handle the larger block size in BIP101. He had to make changes to the code to support BIP66 (bumped up the version of p2pool from 13.xx to 14.xx), so I'm not sure if similar changes would need to be implemented to support BIP101.
However, assuming that the underlying p2pool code can indeed handle the larger block sizes, then it will be up to the node operator to choose whether or not to use the XT code or the Core code to generate the blocks.
However, assuming that the underlying p2pool code can indeed handle the larger block sizes, then it will be up to the node operator to choose whether or not to use the XT code or the Core code to generate the blocks.
August 17, 2015, 10:53:14 PM
Given the current maximum block size controversy, it would be helpful if pool operators could state their position regarding increasing the maximum block size and regarding various proposals related to this issue.
This would provide useful information for hashers looking to decide which pools to use.
This would provide useful information for hashers looking to decide which pools to use.
Jump to: