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

tiker

sr. member

Activity: 459

Merit: 250

Every time I update p2pool or stop and start it again I get new errors...

This time I'm getting the following but don't know why or how to fix it.. any ideas?

Code:


2012-03-08 19:18:37.602900 Error when requesting noncached value:
2012-03-08 19:18:37.603161 > Traceback (most recent call last):
2012-03-08 19:18:37.603401 >   File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 388, in errback
2012-03-08 19:18:37.603583 >     self._startRunCallbacks(fail)
2012-03-08 19:18:37.603746 >   File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 455, in _startRunCallbacks
2012-03-08 19:18:37.603914 >     self._runCallbacks()
2012-03-08 19:18:37.604149 >   File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 542, in _runCallbacks
2012-03-08 19:18:37.604342 >     current.result = callback(current.result, *args, **kw)
2012-03-08 19:18:37.604508 >   File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1076, in gotResult
2012-03-08 19:18:37.604674 >     _inlineCallbacks(r, g, deferred)
2012-03-08 19:18:37.604861 > ---  ---
2012-03-08 19:18:37.605021 >   File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1018, in _inlineCallbacks
2012-03-08 19:18:37.605215 >     result = result.throwExceptionIntoGenerator(g)
2012-03-08 19:18:37.605376 >   File "/usr/lib/python2.7/dist-packages/twisted/python/failure.py", line 350, in throwExceptionIntoGenerator
2012-03-08 19:18:37.605567 >     return g.throw(self.type, self.value, self.tb)
2012-03-08 19:18:37.605729 >   File "/home/ed/apps/p2pool/p2pool/main.py", line 171, in 
2012-03-08 19:18:37.605894 >     height_cacher = deferral.DeferredCacher(defer.inlineCallbacks(lambda block_hash: defer.returnValue((lambda x: x['blockcount'] if 'blockcount' in x else x['height'])((yield bitcoind.rpc_getblock('%x' % (block_hash,)))))))
2012-03-08 19:18:37.606063 >   File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1018, in _inlineCallbacks
2012-03-08 19:18:37.606276 >     result = result.throwExceptionIntoGenerator(g)
2012-03-08 19:18:37.606439 >   File "/usr/lib/python2.7/dist-packages/twisted/python/failure.py", line 350, in throwExceptionIntoGenerator
2012-03-08 19:18:37.606632 >     return g.throw(self.type, self.value, self.tb)
2012-03-08 19:18:37.606794 >   File "/home/ed/apps/p2pool/p2pool/util/jsonrpc.py", line 67, in callRemote
2012-03-08 19:18:37.606978 >     raise Error(**resp['error'])
2012-03-08 19:18:37.607198 > p2pool.util.jsonrpc.Error: -5 Block not found

cabin

sr. member

Activity: 604

Merit: 250

anyone else getting tons of these.. or just me? I am on rc2, for sure. Earlier in this thread it was mentioned it is supposed to be 'ok', but still.. it isn't going away..

2012-03-08 19:22:44.788000 > return g.throw(self.type, self.value, self.tb)
2012-03-08 19:22:44.788000 > File "C:\data\miner2\p2pool-a15c106\p2pool\util\jsonrpc.py", line 67, in callRemote
2012-03-08 19:22:44.788000 > raise Error(**resp['error'])
2012-03-08 19:22:44.789000 > p2pool.util.jsonrpc.Error: -5 Block not found
2012-03-08 19:22:44.790000

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: kano on March 08, 2012, 06:14:59 PM

Hmmm - so 3 weeks for the bitcoin developers to ensure that rc2 isn't like rc1 ... and then force everyone to use it under the name of 0.6.0?

That assumes the network has the 60%? support which AFAIK it currently doesn't.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: forrestv on March 08, 2012, 01:20:37 PM

Quote from: Glasswalker on March 08, 2012, 01:07:08 PM

Since P2Pool is Peer to Peer, if say half the miners have updated clients, and half are using older clients. I assume that the client who ultimately finds the block is the one that submits it to the network and handles validation of transactions? If so, 50% of the time would we be vulnerable to this flaw with BIP16?

In other words, do we require 100% of P2Pool users to upgrade their bitcoin clients to be BIP16 compliant to totally avoid this issue?

And if the answer to the above is yes, that's a huge vulnerability for P2Pool (because someone could maliciously join the pool and mine using an old client, to invalidate a percentage of blocks mined by the miners on P2Pool).

All P2Pool users will definitely need to upgrade bitcoind before April 1st because of this issue. The question is of how to prevent people from not upgrading, which can be done by changing the rules of the P2Pool protocol.

This could be as simple as a new version of P2Pool that checks bitcoind's version and refuses to work with older versions, combined with a protocol change on April 1st that requires miners to use the new client. Of course, this is vulnerable to people patching out the version check, but P2Pool (along with all other pools) is already vulnerable to malicious block invalidating attacks, so that's not a problem.

Hmmm - so 3 weeks for the bitcoin developers to ensure that rc2 isn't like rc1 ... and then force everyone to use it under the name of 0.6.0?

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: stevegee58 on March 08, 2012, 03:42:32 PM

I suppose a closed p2p pool could be established where each node is authenticated to be there. Of course then you'd have to have someone administrating it, granting and revoking access, etc.

So all the disadvantages of both a centralized pool AND a decentralized one?

stevegee58

legendary

Activity: 916

Merit: 1003

I suppose a closed p2p pool could be established where each node is authenticated to be there. Of course then you'd have to have someone administrating it, granting and revoking access, etc.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: stevegee58 on March 08, 2012, 03:33:08 PM

"...some men aren't looking for anything logical, like money. They can't be bought, bullied, reasoned, or negotiated with. Some men just want to watch the world burn."

True. non-economical attacks are always possible but I would point out they can happen on any pool. The only way to be "safe" would be solo mining. p2pool through the combination of PPLNS and finders fee is less vulnerable to non-economic block withholding attack.

The most vulnerable would be PPS pools.

stevegee58

legendary

Activity: 916

Merit: 1003

Quote from: DeathAndTaxes on March 08, 2012, 03:15:23 PM

it generally doesn't make any economical sense because it reduces attacker's revenue also and in case of p2pool they also lose finder's reward.

"...some men aren't looking for anything logical, like money. They can't be bought, bullied, reasoned, or negotiated with. Some men just want to watch the world burn."

There are people who would do this just for the sport.

Cool

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: Glasswalker on March 08, 2012, 01:07:08 PM

In other words, do we require 100% of P2Pool users to upgrade their bitcoin clients to be BIP16 compliant to totally avoid this issue?

And if the answer to the above is yes, that's a huge vulnerability for P2Pool (because someone could maliciously join the pool and mine using an old client, to invalidate a percentage of blocks mined by the miners on P2Pool).

Can someone with more technical knowledge of exactly how P2Pool works dive into this a bit deeper please? Preferably BEFORE the launch of BIP16 (potentially 1st of April at this point).

IF 51% of Bitcoin network accepts BIP16 then p2pool does need to also. A miner producing non-compliant hashes will eventually produce a non-compliant block. The % would be relative to the % of hashing power they have.

A couple ways to deal with it.
The simplest way would be to do version checking in p2pool. Make new version of p2pool which will not work under any version of bitcoind that isn't BIP16 compliant. It will simple fail to run with an error. If someone updates their p2pool but not bitcoind they can't mine. The new version would also reject 100% of shares from old versions. Thus if someone doesn't update p2pool or bitcoind they can mine (because their software isn't aware of the issue) but they will see 100% reject rate. Compensation won't go down because they will never earn anything for this "bad" shares to match the expected value of their "bad" blocks.

Summary:
new p2pool & new bitcoind (BIP16 compliant) = good (no problems)
new p2pool & old bitcoind = won't start
old p2pool & old bitcoind = 100% reject rate from new p2pool version nodes.

That deals with a "ignorant user". It prevents them from accidentally hurting the network. A malicious user could intentionally modify bitcoind and p2pool code to produce non-compliant blocks. This is no different than any other block withholding attack it generally doesn't make any economical sense because it reduces attacker's revenue also and in case of p2pool they also lose finder's reward.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

This is coming from bitcoind.
"WARNING: Displayed transactions may not be correct! You may need to upgrade, or other nod
es may need to upgrade."

You running 0.6.0 RC1? If so you need to go to RC2 or go back to 0.5.2

Frizz23

hero member

Activity: 1162

Merit: 500

I just checked my p2pool cruncher because of unusually low payouts.

Besides heaps of orphans in the log there are lots of lines like this here:

Code:

2012-03-08 20:57:32.886000 Error when requesting noncached value:
2012-03-08 20:57:32.887000 > Traceback (most recent call last):
2012-03-08 20:57:32.888000 >   File "twisted\internet\defer.pyc", line 388, in errback
2012-03-08 20:57:32.889000 >
2012-03-08 20:57:32.891000 >   File "twisted\internet\defer.pyc", line 455, in _startRunCallbacks
2012-03-08 20:57:32.892000 >
2012-03-08 20:57:32.893000 >   File "twisted\internet\defer.pyc", line 542, in _runCallbacks
2012-03-08 20:57:32.894000 >
2012-03-08 20:57:32.895000 >   File "twisted\internet\defer.pyc", line 1076, in gotResult
2012-03-08 20:57:32.896000 >
2012-03-08 20:57:32.897000 > ---  ---
2012-03-08 20:57:32.897000 >   File "twisted\internet\defer.pyc", line 1018, in _inlineCallbacks
2012-03-08 20:57:32.898000 >
2012-03-08 20:57:32.899000 >   File "twisted\python\failure.pyc", line 350, in throwExceptionIntoGenerator
2012-03-08 20:57:32.901000 >
2012-03-08 20:57:32.903000 >   File "p2pool\main.pyc", line 171, in 
2012-03-08 20:57:32.904000 >
2012-03-08 20:57:32.905000 >   File "twisted\internet\defer.pyc", line 1018, in _inlineCallbacks
2012-03-08 20:57:32.906000 >
2012-03-08 20:57:32.907000 >   File "twisted\python\failure.pyc", line 350, in throwExceptionIntoGenerator
2012-03-08 20:57:32.908000 >
2012-03-08 20:57:32.909000 >   File "p2pool\util\jsonrpc.pyc", line 67, in callRemote
2012-03-08 20:57:32.910000 >
2012-03-08 20:57:32.912000 > p2pool.util.jsonrpc.Error: -2 Safe mode: WARNING: Displayed transactions may not be correct!  You may need to upgrade, or other nod
es may need to upgrade.
2012-03-08 20:57:32.914000
2012-03-08 20:57:32.918000

What's going on? I updated p2pool last week! So do I really need to update again?

forrestv

hero member

Activity: 516

Merit: 643

Quote from: Glasswalker on March 08, 2012, 01:07:08 PM

Since P2Pool is Peer to Peer, if say half the miners have updated clients, and half are using older clients. I assume that the client who ultimately finds the block is the one that submits it to the network and handles validation of transactions? If so, 50% of the time would we be vulnerable to this flaw with BIP16?

In other words, do we require 100% of P2Pool users to upgrade their bitcoin clients to be BIP16 compliant to totally avoid this issue?

And if the answer to the above is yes, that's a huge vulnerability for P2Pool (because someone could maliciously join the pool and mine using an old client, to invalidate a percentage of blocks mined by the miners on P2Pool).

All P2Pool users will definitely need to upgrade bitcoind before April 1st because of this issue. The question is of how to prevent people from not upgrading, which can be done by changing the rules of the P2Pool protocol.

This could be as simple as a new version of P2Pool that checks bitcoind's version and refuses to work with older versions, combined with a protocol change on April 1st that requires miners to use the new client. Of course, this is vulnerable to people patching out the version check, but P2Pool (along with all other pools) is already vulnerable to malicious block invalidating attacks, so that's not a problem.

Glasswalker

sr. member

Activity: 407

Merit: 250

Hey, I recently joined P2Pool with the mining cluster of the Bitcoin Syndicate (currently 6GHash, soon to jump to 12GHash.)

I have a question that came up in relation to BIP16 and how it affects P2Pool (brought it up on this thread: https://bitcointalksearch.org/topic/bip-16-switchover-date-pushed-to-april-1-66514)

The question is basically:

BIP16 has a vulnerability, if miners use old bitcoin clients that don't properly handle it, someone could submit a "poisoned" tx into the network that is invalid under bip16 but is valid on older clients. In this case the miner using the old client would add the tx to a block thinking it's valid, but the rest of the network on newer clients would reject the block (Eventually outpacing it's fork and invalidating the miners income). If the transactions are injected regularly, this would amount to a DOS for any miner using older clients.

My question as it relates to P2Pool is:

Since P2Pool is Peer to Peer, if say half the miners have updated clients, and half are using older clients. I assume that the client who ultimately finds the block is the one that submits it to the network and handles validation of transactions? If so, 50% of the time would we be vulnerable to this flaw with BIP16?

In other words, do we require 100% of P2Pool users to upgrade their bitcoin clients to be BIP16 compliant to totally avoid this issue?

And if the answer to the above is yes, that's a huge vulnerability for P2Pool (because someone could maliciously join the pool and mine using an old client, to invalidate a percentage of blocks mined by the miners on P2Pool).

Can someone with more technical knowledge of exactly how P2Pool works dive into this a bit deeper please? Preferably BEFORE the launch of BIP16 (potentially 1st of April at this point).

Thanks!

broken

newbie

Activity: 55

Merit: 0

Quote from: cabin on March 08, 2012, 09:15:17 AM

Quote

I think 0.6.0rc1 broke my blk0001.dat, blkindex.dat or something else not located in .bitcoin/ (is there something else?)
When I get home I will also delete these files. (I have a 170190+ blockchain here that I will try first, before downloading the whole thing again)

I thought this too.. but mine did recover after ~5 min after installing rc2.

I gave it another hour, but it didn't recover. I copied the blockchain files from another machine and now it works.

broken

newbie

Activity: 55

Merit: 0

Quote from: Frizz23 on March 08, 2012, 09:44:54 AM

How come our "reference" address http://blockexplorer.com/address/1Kz5QaUPDtKrj5SqW5tFkn7WZh8LmQaQi4 gets almost constant bounty per block (always ~0.16 per block) - while mine varies so much (0.02 - 0.17) http://blockexplorer.com/address/1EZMh5fH33TFWLh6enwL86gam5LnEE2o4v ?

I had my machine running 24 hours the lase couple of days.

Isn't 1Kz5QaUPDtKrj5SqW5tFkn7WZh8LmQaQi4 forrestv's author donation address, which always gets 0,5% of 50BTC for each block. Some people disabled donation so its a bit less, but pretty stable.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: Frizz23 on March 08, 2012, 09:44:54 AM

How come our "reference" address http://blockexplorer.com/address/1Kz5QaUPDtKrj5SqW5tFkn7WZh8LmQaQi4 gets almost constant bounty per block (always ~0.16 per block) - while mine varies so much (0.02 - 0.17) http://blockexplorer.com/address/1EZMh5fH33TFWLh6enwL86gam5LnEE2o4v ?

I had my machine running 24 hours the lase couple of days.

Variance.

If donation is a small % of a large amount of GH/s then the payment will be small but constant.

0.16 per block would be roughly 100% of 1.15 GH/s. However the donation is most likely the default for most users that donate. So it isn't 100% of 1.15 GH/s. It is 0.5% of ~200 GH/s. If you had 200 GH/s your payout per block would be very constant too.

Frizz23

hero member

Activity: 1162

Merit: 500

How come our "reference" address http://blockexplorer.com/address/1Kz5QaUPDtKrj5SqW5tFkn7WZh8LmQaQi4 gets almost constant bounty per block (always ~0.16 per block) - while mine varies so much (0.02 - 0.17) http://blockexplorer.com/address/1EZMh5fH33TFWLh6enwL86gam5LnEE2o4v ?

I had my machine running 24 hours the lase couple of days.

cabin

sr. member

Activity: 604

Merit: 250

Quote

I think 0.6.0rc1 broke my blk0001.dat, blkindex.dat or something else not located in .bitcoin/ (is there something else?)
When I get home I will also delete these files. (I have a 170190+ blockchain here that I will try first, before downloading the whole thing again)

I thought this too.. but mine did recover after ~5 min after installing rc2. Also for those of you wondering about the bitcoind response time, I believe these lines of code will print out when there is trouble in main.py arond line 152:

def set_real_work1():
my_time = time.time()
work = yield getwork(bitcoind)
my_time2 = time.time() - my_time
if (my_time2 > 0.2):
print "slow bitcoind: %.02f" % (my_time2,)

Mine are usually under 0.2 seconds, but on occasion take up to 2 seconds, which is interesting.

broken

newbie

Activity: 55

Merit: 0

Quote from: DeathAndTaxes on March 08, 2012, 08:21:51 AM

Quote from: broken on March 08, 2012, 06:33:21 AM

I'm pretty sure I'm running bitcoin 0.6.0rc2. But i guess rc1 broke my bitcoin db somehow.
Im currently testing on another machine, where I switched directly from 0.5.2 to 0.6.0rc2 at block 167000. But still have to download 1000 blocks. If this works ill just copy the database to the other machine.

1) You can use 0.5 bitcoind.

2) If you used the windows installer you almost certainly are not running 0.6.0 rc2. It will say it installed but it doesn't overwrite everything from 0.6.0 rc1.

3) For p2pool I recommend using a bitcoind instance w/ a "blank wallet" and manually setting the payment address. That way a bad wallet simply means delete wallet.dat and relaunch bitcoind to create a new one.

4) For custom windows installs the zip file is preferable. You can drop it in a custom folder, delete the GUI bitcoin, and set data directory to the same folder. Upgrading or replacing simple means deleting the folder.

I'm using linux and I'm pretty sure I'm running the correct binary as you can see in my earlier post:

Quote from: broken on March 08, 2012, 03:53:27 AM

broken@rig02:~/bitcoin$ ps -ef | grep coin
broken 2165 1 0 Feb14 ? 02:40:53 ./namecoind -daemon
broken 15663 1 10 09:45 ? 00:00:12 ./bitcoind -daemon

broken@rig02:~/bitcoin$ readlink -f /proc/15663/exe
/home/broken/bitcoin/bitcoin-0.6.0rc2-linux/bin/64/bitcoind

You are correct, it is best to use a empty wallet on that machine and that is what I do.
I tried to delete everything except the blockchain, but still the same problem.
I also tried to run 0.5.2, but its stuck at 170059, too.

broken@rig02:~/bitcoin/bitcoin-0.5.2-linux/bin/64$ ./bitcoind getinfo
{
   "version" : 50200,
   "balance" : 0.00000000,
   "blocks" : 170059,
   "connections" : 8,
   "proxy" : "",
   "generate" : false,
   "genproclimit" : -1,
   "difficulty" : 1496978.59502557,
   "hashespersec" : 0,
   "testnet" : false,
   "keypoololdest" : 1331211591,
   "keypoolsize" : 101,
   "paytxfee" : 0.00000000,
   "errors" : "WARNING: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade."
}

I think 0.6.0rc1 broke my blk0001.dat, blkindex.dat or something else not located in .bitcoin/ (is there something else?)
When I get home I will also delete these files. (I have a 170190+ blockchain here that I will try first, before downloading the whole thing again)

ChanceCoats123

hero member

Activity: 682

Merit: 500

Quote from: c_k on March 08, 2012, 02:33:36 AM

Bad idea unlocking core imo

Why would that be a bad idea? From my experience with unlocking Amd chips, it either works and it's 100% stable, or it doesn't load into Windows/Linux/Whatever-the-hell. So there is no possible damage to be done by trying to unlock. My miner runs on a Gigabyte UD5P with a 555 unlocked to 4x and it works just fine.

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