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

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: jgarzik on March 20, 2013, 11:50:46 PM

Quote from: kano on March 20, 2013, 10:18:05 PM

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 ...

jgarzik

legendary

Activity: 1596

Merit: 1100

Quote from: kano on March 20, 2013, 10:18:05 PM

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

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: jgarzik on March 20, 2013, 09:07:32 PM

Quote from: ?? on ??

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

legendary

Activity: 1596

Merit: 1100

Quote from: ?? on ??

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.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: -ck on March 18, 2013, 05:55:39 PM

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.

gyverlb

hero member

Activity: 896

Merit: 1000

Quote from: wtogami on March 20, 2013, 05:24:15 PM

Quote from: -ck on March 18, 2013, 05:55:39 PM

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

Quote

-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).

wtogami

sr. member

Activity: 263

Merit: 250

Quote from: -ck on March 18, 2013, 05:55:39 PM

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

Quote

-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?

PatMan

hero member

Activity: 924

Merit: 1000

Watch out for the "Neg-Rep-Dogie-Police".....

What on earth has happened here?

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

Has someone been tinkering?...... Cheesy

Peace.

wtogami

sr. member

Activity: 263

Merit: 250

Quote from: forrestv on March 17, 2013, 09:17:10 PM

Quote from: Nite69 on March 17, 2013, 03:18:24 AM

Quote from: eleuthria on March 17, 2013, 02:06:44 AM

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.

rav3n_pl

legendary

Activity: 1361

Merit: 1003

Don`t panic! Organize!

Quote from: Nite69 on March 17, 2013, 02:50:27 PM

Quote from: eleuthria on March 17, 2013, 02:06:44 AM

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.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

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.

forrestv

hero member

Activity: 516

Merit: 643

Quote from: Nite69 on March 17, 2013, 03:18:24 AM

Quote from: eleuthria on March 17, 2013, 02:06:44 AM

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.

Nite69

sr. member

Activity: 477

Merit: 500

Quote from: K1773R on March 17, 2013, 09:13:24 AM

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?

Nite69

sr. member

Activity: 477

Merit: 500

Quote from: eleuthria on March 17, 2013, 02:06:44 AM

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...

K1773R

legendary

Activity: 1792

Merit: 1008

/dev/null

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

Nite69

sr. member

Activity: 477

Merit: 500

Quote from: eleuthria on March 17, 2013, 02:06:44 AM

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 :-(

eleuthria

legendary

Activity: 1750

Merit: 1007

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.

Nite69

sr. member

Activity: 477

Merit: 500

Quote from: rav3n_pl on March 16, 2013, 03:36:23 AM

Code:

2013-03-16 09:39:04.373335 > Error submitting block: (will retry)
...
2013-03-16 09:39:04.375917 > raise Error_for_code(resp['error']['code'])(resp['error']['message'], resp['error'].get('data', None))
2013-03-16 09:39:04.376017 > p2pool.util.jsonrpc.NarrowError: -32601 Method not found

It clearly says, that daemon is not accepting submitted block (function is not known).
See debug.log form litecoind and log for p2pool in same time.
https://github.com/litecoin-project/litecoin/issues/23

Debugged this a little more. Well, there is not submitblock rpc method on the litecoin! :-( This means it is not working anywhere. But then how the blocks get into litecoin block chain?!
bitcoinrp.cpp @ bitcoin

Code:

{ "settxfee", &settxfee, false, false },
{ "getblocktemplate", &getblocktemplate, true, false },
{ "submitblock", &submitblock, false, false },
{ "listsinceblock", &listsinceblock, false, false },
{ "dumpprivkey", &dumpprivkey, false, false },
{ "importprivkey", &importprivkey, false, false },

bitcoinrp.cpp @ litecoin

Code:

{ "getblocktemplate", &getblocktemplate, true },
{ "listsinceblock", &listsinceblock, false },
{ "dumpprivkey", &dumpprivkey, false },
{ "importprivkey", &importprivkey, false },

Nite69

sr. member

Activity: 477

Merit: 500

Quote from: twmz on March 16, 2013, 02:49:02 PM

Quote from: Nite69 on March 16, 2013, 02:45:00 PM

Hi!

How is this supposed to work? I do not understand how it could have been implemented. Also, it does not seem to work on litecoin p2pool.

-f FEE_PERCENTAGE, --fee FEE_PERCENTAGE
charge workers mining to their own bitcoin address (by
setting their miner's username to a bitcoin address)
this percentage fee to mine on your p2pool instance.
Amount displayed at http://127.0.0.1:WORKER_PORT/fee
(default: 0)

if you set the fee percentage to 1%, then 1% of shares (randomly) will be allocated to the address specified on the command line (with -a) instead of to the address passed in by the miner as the username.

Yes, of course, ty anyway. Found it on the code:

Code:

if random.uniform(0, 100) < self.worker_fee:
pubkey_hash = self.my_pubkey_hash

twmz

hero member

Activity: 737

Merit: 500

Quote from: Nite69 on March 16, 2013, 02:45:00 PM

Hi!

How is this supposed to work? I do not understand how it could have been implemented. Also, it does not seem to work on litecoin p2pool.

-f FEE_PERCENTAGE, --fee FEE_PERCENTAGE
charge workers mining to their own bitcoin address (by
setting their miner's username to a bitcoin address)
this percentage fee to mine on your p2pool instance.
Amount displayed at http://127.0.0.1:WORKER_PORT/fee
(default: 0)

if you set the fee percentage to 1%, then 1% of shares (randomly) will be allocated to the address specified on the command line (with -a) instead of to the address passed in by the miner as the username.

Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 581. (Read 2591920 times)