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

[Nite69]

this happens sometimes, start litecoind first and then start ltcp2pool, that should fix it.

It happens *allways* on my system. Every single time p2pool finds a block.

The code looks like it tries to use some 'getmemorypool' method, and fallbacks to use 'submitblock' if it fails. Unfortunately, fallback uses 'submitblock', which also does not work in litecoin. You have to wait for the first found litecoin block on p2pool network to see the problem. Hopefully this problem is not on every 11.2 node.

I do not know why getmemorypool fails. Shouldn't it?

[forrestv]

submitblock is relatively new in bitcoind.  In litecoind it's done with getblocktemplate, passing the first argument (mode) as submit, and the second argument (data) as the hex data of the full block.

That means there really is a compatibility problem between latest p2pool (11.2, possibly earlier) and any version of litecoind. Maybe users should be adviced not to update to latest p2pool with litecoin. If everyone updates... litecoin p2pool stops getting any blocks :-(

P2Pool also submits blocks over the P2P connection, so even if everyone upgraded, there wouldn't be any problem.

I'll either fix this in P2Pool or submit a pull request to the Litecoin project to add submitblock.

[-ck]

p2pool stratum for ltc uses difficulty based on btc difficulty. Unfortunately the defacto standard as used by many pools using ltc stratum now set difficulty according to the base ltc difficulty (65536 times larger) meaning p2pool is at odds with what everyone else is doing and thus is asking for way too low difficulties making cgminer submit shares of much lower difficulty than p2pool is expecting. As there is a precedent with other pools setting the defacto standard prior to p2pool, unfortunately the onus is on p2pool to come in line with the rest.

[rav3n_pl]

submitblock is relatively new in bitcoind.  In litecoind it's done with getblocktemplate, passing the first argument (mode) as submit, and the second argument (data) as the hex data of the full block.

Thank you, fixed it by changing one line in source:
helper.py, line 73:
was

Code:

        #result = yield bitcoind.rpc_submitblock(bitcoin_data.block_type.pack(block).encode('hex'))

Fix:

Code:

	result = yield bitcoind.rpc_getblocktemplate(dict(mode='submit', data=bitcoin_data.block_type.pack(block).encode('hex')))

Of course, I don't know if this works on bitcoin p2pool any more. Someone into this make this and add correct checks (litecoind/bitcoind (terracoin/ppc?!) mode, other end version etc..)

Seriously, the rpc interface should give a version number so the client could choose correct method to use.. Current one this is a mess and very difficult to do (litecoind/bitcoind) version independent code :-(

Testing is a bit slow, allways need to wait for p2poop to find a block...

Poll request send, for litecoin p2pool should use getblocktemplate instead of submitblock. Till they fix/update daemon code.

[wtogami]

submitblock is relatively new in bitcoind.  In litecoind it's done with getblocktemplate, passing the first argument (mode) as submit, and the second argument (data) as the hex data of the full block.

That means there really is a compatibility problem between latest p2pool (11.2, possibly earlier) and any version of litecoind. Maybe users should be adviced not to update to latest p2pool with litecoin. If everyone updates... litecoin p2pool stops getting any blocks :-(

P2Pool also submits blocks over the P2P connection, so even if everyone upgraded, there wouldn't be any problem.

I'll either fix this in P2Pool or submit a pull request to the Litecoin project to add submitblock.

Litecoin has plans for 0.8.1, it looks like it will be a few months as coblee wants to be extra cautious.  He wants to wait past May 15th to be certain the BTC hard-fork goes smoothly.

Meanwhile there are a lot of p2pool litecoin miners who are currently failing to submit blocks.  Perhaps this is a good time to push 11.3 and make it incompatible with the previous version to ensure the broken miners are no longer leaching shares?

Edit: It seems I was wrong.  gmaxwell reminded me that p2pool has parallel block submissions, so as long as other nodes have working block submissions this isn't broken enough to require a protocol version bump and sharechain fork.  Until everyone upgrades p2pool, it seems that block submission will be delayed and we have a slightly higher chance of block orphans.

[PatMan]

What on earth has happened here?

160% 7 day "L**k"?!!! 

Has someone been tinkering?......

Peace.

[wtogami]

p2pool stratum for ltc uses difficulty based on btc difficulty. Unfortunately the defacto standard as used by many pools using ltc stratum now set difficulty according to the base ltc difficulty (65536 times larger) meaning p2pool is at odds with what everyone else is doing and thus is asking for way too low difficulties making cgminer submit shares of much lower difficulty than p2pool is expecting. As there is a precedent with other pools setting the defacto standard prior to p2pool, unfortunately the onus is on p2pool to come in line with the rest.

https://github.com/coblee/litecoin/commit/923b6643c902590f4817e3c4111649082353b1b8#L12L31

-static CBigNum bnProofOfWorkLimit(~uint256(0) >> 32);
+static CBigNum bnProofOfWorkLimit(~uint256(0) >> 20); // Litecoin: starting difficulty is 1 / 2^12

This is another difference between bitcoin and litecoin.  Is this also taken into account by p2pool/cgminer?

[gyverlb]

p2pool stratum for ltc uses difficulty based on btc difficulty. Unfortunately the defacto standard as used by many pools using ltc stratum now set difficulty according to the base ltc difficulty (65536 times larger) meaning p2pool is at odds with what everyone else is doing and thus is asking for way too low difficulties making cgminer submit shares of much lower difficulty than p2pool is expecting. As there is a precedent with other pools setting the defacto standard prior to p2pool, unfortunately the onus is on p2pool to come in line with the rest.

https://github.com/coblee/litecoin/commit/923b6643c902590f4817e3c4111649082353b1b8#L12L31

-static CBigNum bnProofOfWorkLimit(~uint256(0) >> 32);
+static CBigNum bnProofOfWorkLimit(~uint256(0) >> 20); // Litecoin: starting difficulty is 1 / 2^12

This is another difference between bitcoin and litecoin.  Is this also taken into account by p2pool/cgminer?

Nope: it seems p2pool should be patched as patching cgminer would break all other litecoin/stratum pools.

I've stumbled upon this bug and posted a message in #cgminer shortly before ckolivas posted this. I've documented it in the FAQ of this guide too in case someone looks in the forum for the information (I couldn't and found the information on IRC).

[Luke-Jr]

p2pool stratum for ltc uses difficulty based on btc difficulty. Unfortunately the defacto standard as used by many pools using ltc stratum now set difficulty according to the base ltc difficulty (65536 times larger) meaning p2pool is at odds with what everyone else is doing and thus is asking for way too low difficulties making cgminer submit shares of much lower difficulty than p2pool is expecting. As there is a precedent with other pools setting the defacto standard prior to p2pool, unfortunately the onus is on p2pool to come in line with the rest.

This is really a bug in litecoin pools and *gminer. p2pool handles it more sanely. The protocol/miner only cares about algorithm, not network.
The original bug is in stratum, for specifying a network-related variable unit for difficulty, instead of the actual target.
But as long as stratum is specifying target as a fuzzy bdiff, pools using litecoin-diff instead are merely violating the spec.

[jgarzik]

Yeah we could point out how YOU put botnet support into the bitcoind client (yes it is there) buy adding a STUPID 32bit nonce range that wasn't in the BIP

Read the code closely.  bitcoind's block processing behavior is the same as it always was.  getblocktemplate returns a static value for "noncerange":

Code:

    result.push_back(Pair("noncerange", "00000000ffffffff"));

and never examines the value.

noncerange was always silly in my opinion -- which is why it does not change bitcoind's behavior one bit.

[kano]

Yeah we could point out how YOU put botnet support into the bitcoind client (yes it is there) buy adding a STUPID 32bit nonce range that wasn't in the BIP

Read the code closely.  bitcoind's block processing behavior is the same as it always was.  getblocktemplate returns a static value for "noncerange":

Code:

    result.push_back(Pair("noncerange", "00000000ffffffff"));

and never examines the value.

noncerange was always silly in my opinion -- which is why it does not change bitcoind's behavior one bit.

It is not in the BIP he implemented ... go read it.

[jgarzik]

It is not in the BIP he implemented ... go read it.

Not relevant to evaluating your claim of "[luke-jr] put botnet support into the bitcoind client"

That statement is not just characteristically hyperbolic... it is simply false, as the source code demonstrates.

[kano]

It is not in the BIP he implemented ... go read it.

Not relevant to evaluating your claim of "[luke-jr] put botnet support into the bitcoind client"

That statement is not just characteristically hyperbolic... it is simply false, as the source code demonstrates.

Logic fail.
Implement a new interface, and include an old option that isn't required or even in the implementation spec.
Yeah I know it's a bit beyond a BTC dev to understand ...

[eleuthria]

Just a note for p2pool miners (and possibly a required hard fork for p2pool software versions):  Version 2 blocks (height-in-coinbase) will likely hit supermajority next week which will make any attempt to submit a Version1 block be orphaned by the rest of the network.  Deepbit has switched, BTC Guild has finally patched the getwork pools, and Ozcoin is closing getwork entirely.  After ~1 week, the 1,000 block window used to evaluate 95% supermajority has a good chance of triggering, and once it is triggered it will never turn off.

This change to v2 blocks is also a good chance to upgrade to bitcoind 0.8.1 if you haven't done so already.

[gyverlb]

This change to v2 blocks is also a good chance to upgrade to bitcoind 0.8.1 if you haven't done so already.

Note that you only need 0.7.0 or later to generate v2 blocks. Upgrading to 0.8.1 from any 0.7.x is still advisable for P2Pool miners (for efficiency reasons).

[mdude77]

Now that p2pool seems to have recovered, I'm trying to use it again.  I found whenever cgminer 2.11.x tries to connect, I get this error from p2pool.  2.10.5 doesn't do it.  With my machine with one GPU, cgminer is able to mine.  With the machine with 4 GPUs, cgminer hangs and then crashes.  This is on win7 x64.  What gives?

Code:

2013-03-21 20:20:56.830000 > Squelched JSON error:
2013-03-21 20:20:56.830000 > Traceback (most recent call last):
2013-03-21 20:20:56.830000 >   File "c:\python27\lib\site-packages\twisted\proto
cols\basic.py", line 455, in dataReceived
2013-03-21 20:20:56.830000 >     self.lineReceived(line)
2013-03-21 20:20:56.830000 >   File "C:\mining\p2pool\p2pool\util\jsonrpc.py", l
ine 164, in lineReceived
2013-03-21 20:20:56.830000 >     _handle(line, self, response_handler=self._matc
her.got_response).addCallback(lambda line2: self.sendLine(line2) if line2 is not
 None else None)
2013-03-21 20:20:56.830000 >   File "c:\python27\lib\site-packages\twisted\inter
net\defer.py", line 1187, in unwindGenerator
2013-03-21 20:20:56.830000 >     return _inlineCallbacks(None, gen, Deferred())
2013-03-21 20:20:56.830000 >   File "c:\python27\lib\site-packages\twisted\inter
net\defer.py", line 1045, in _inlineCallbacks
2013-03-21 20:20:56.830000 >     result = g.send(result)
2013-03-21 20:20:56.840000 > --- <exception caught here> ---
2013-03-21 20:20:56.840000 >   File "C:\mining\p2pool\p2pool\util\jsonrpc.py", l
ine 85, in _handle
2013-03-21 20:20:56.840000 >     result = yield method_meth(*list(preargs) + lis
t(params))
2013-03-21 20:20:56.840000 > exceptions.TypeError: rpc_subscribe() takes exactly
 1 argument (2 given)
2013-03-21 20:20:56.840000 > Squelched JSON error:
2013-03-21 20:20:56.840000 > Traceback (most recent call last):
2013-03-21 20:20:56.840000 >   File "c:\python27\lib\site-packages\twisted\proto
cols\basic.py", line 455, in dataReceived
2013-03-21 20:20:56.840000 >     self.lineReceived(line)
2013-03-21 20:20:56.850000 >   File "C:\mining\p2pool\p2pool\util\jsonrpc.py", l
ine 164, in lineReceived
2013-03-21 20:20:56.850000 >     _handle(line, self, response_handler=self._matc
her.got_response).addCallback(lambda line2: self.sendLine(line2) if line2 is not
 None else None)
2013-03-21 20:20:56.850000 >   File "c:\python27\lib\site-packages\twisted\inter
net\defer.py", line 1187, in unwindGenerator
2013-03-21 20:20:56.850000 >     return _inlineCallbacks(None, gen, Deferred())
2013-03-21 20:20:56.850000 >   File "c:\python27\lib\site-packages\twisted\inter
net\defer.py", line 1045, in _inlineCallbacks
2013-03-21 20:20:56.850000 >     result = g.send(result)
2013-03-21 20:20:56.850000 > --- <exception caught here> ---
2013-03-21 20:20:56.850000 >   File "C:\mining\p2pool\p2pool\util\jsonrpc.py", l
ine 85, in _handle
2013-03-21 20:20:56.850000 >     result = yield method_meth(*list(preargs) + lis
t(params))
2013-03-21 20:20:56.860000 > exceptions.TypeError: rpc_subscribe() takes exactly
 1 argument (2 given)

M

[gyverlb]

Now that p2pool seems to have recovered, I'm trying to use it again.  I found whenever cgminer 2.11.x tries to connect, I get this error from p2pool.  2.10.5 doesn't do it.  With my machine with one GPU, cgminer is able to mine.  With the machine with 4 GPUs, cgminer hangs and then crashes.  This is on win7 x64.  What gives?

If it's cgminer crashing and not P2Pool the cgminer thread would be a better place to find a solution. I've seen the kind of stacktrace you got with connectivity problems.

[mdude77]

Now that p2pool seems to have recovered, I'm trying to use it again.  I found whenever cgminer 2.11.x tries to connect, I get this error from p2pool.  2.10.5 doesn't do it.  With my machine with one GPU, cgminer is able to mine.  With the machine with 4 GPUs, cgminer hangs and then crashes.  This is on win7 x64.  What gives?

If it's cgminer crashing and not P2Pool the cgminer thread would be a better place to find a solution. I've seen the kind of stacktrace you got with connectivity problems.

p2pool gives the error when cgminer tries to connect.

I know the cgminer guys read here, maybe they'll pipe up.

M

[mdude77]

Now that p2pool seems to have recovered, I'm trying to use it again.  I found whenever cgminer 2.11.x tries to connect, I get this error from p2pool.  2.10.5 doesn't do it.  With my machine with one GPU, cgminer is able to mine.  With the machine with 4 GPUs, cgminer hangs and then crashes.  This is on win7 x64.  What gives?

If it's cgminer crashing and not P2Pool the cgminer thread would be a better place to find a solution. I've seen the kind of stacktrace you got with connectivity problems.

p2pool gives the error when cgminer tries to connect.

I know the cgminer guys read here, maybe they'll pipe up.

M

Also, while 2.10.5 works, it isn't working right.  On the 4xgpu box, it sits there for a good 30 seconds just showing the version before it starts.  Then it starts on LP instead of stratum.  I get this when using the windows .exe build for 11.2, as well as directly with python with latest source git.  My 1 gpu rig connects right up immediately with stratum.

M

[forrestv]

I just pushed a commit that should fix the traceback. All it does is ignore the extra argument cgminer provides to mining.subscribe (which is cgminer's version).