Re: [1400GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

Quote from: gyverlb on July 25, 2013, 11:35:12 PM

Quote from: kano on July 25, 2013, 11:15:58 PM

...
... anyone care to explain that before I switch over to some other pool ... it really does look like it's p2pool itself that decided to produce that crap block ... unless I've misunderstood somewhere ... or are there hidden options in p2pool that I need to fix and the default settings suck?

Just after a block is broadcasted on the bitcoin network there is less juicy txs on the network to include: if a block is found just after another one it may not have much tx fees.

... the previous block was 86 seconds before it ...

Code:

2013-07-25 16:24:17 CTxMemPool::accept() : accepted 529cf3fc055a54a2c73dd04c9fddd948c92e955ebd4383faf3d71562a5164d18 (poolsz 1860)
2013-07-25 16:24:17 received block 000000000000006de7e7d91c59bbcbd7578b09a81a2241192c8accd98d076f6e
2013-07-25 16:24:17 Committing 2522 changed transactions to coin database...
2013-07-25 16:24:18 SetBestChain: new best=000000000000006de7e7d91c59bbcbd7578b09a81a2241192c8accd98d076f6e height=248393 log2_work=70.874776 tx=21101455 date=2013-07-25 16:23:19 progress=0.999996
2013-07-25 16:24:18 ProcessBlock: ACCEPTED
.
.
2013-07-25 16:24:18 CTxMemPool::accept() : accepted e2d20ab0608ec065214f8c24ff2505ac4d6a2cd1a5e3904d61aff1bc80e2f39a (poolsz 1776)

Quote

Another rare cause for low income blocks : pools (not only p2pool) use a trick to avoid miners working on stale coinbases: when they detect a new block they immediately ask for (or maybe compute themselves) an empty coinbase which is really fast to compute and makes it possible for miners to do useful work as soon as possible. Then they ask for a "normal" coinbase which is slower.

It's not empty, so got nothing to do with it ... as you can easily have seen by looking at the 3 blocks mined in the last 24 hours without having to guess which is the block I found ... even though my block is listed there in my post Tongue

Quote

You can check what your bitcoind includes in its coinbase with

Code:

bitcoind getmininginfo

: currentblocktx is the number of tx in the coinbase and is obviously lower than pooledtx (the number in your memory pool).

Code:

# ./bitcoind getmininginfo
{
   "blocks" : 248451,
   "currentblocksize" : 77889,
   "currentblocktx" : 133,
   "difficulty" : 31256960.72776893,
   "errors" : "",
   "generate" : false,
   "genproclimit" : -1,
   "hashespersec" : 0,
   "pooledtx" : 1759,
   "testnet" : false
}
#

Well that says something evil about bitcoind ...

Quote

paytxfee only affects what your node includes in its own transactions.

Yes I know

Quote

To make juicier blocks (to maximize profit and speed up transaction confirmations everyone on p2pool should probably use this if they don't have any out-of-the-ordinary setup):

Code:

mintxfee=0.00001
minrelaytxfee=0.00001
blockmaxsize=1000000

The defaults (which are my settings since I haven't changed them - I only upgraded from 0.7.0 to 0.8.3 on Jul-8 Tongue

) are:
mintxfee=10000 = 0.00010000
minrelaytxfee=10000 = 0.00010000
blockmaxsize=250000

... looks like I need to decrease those 2 'min' values to at least stop bitcoind from screwing over the BTC network ...
Imagine how bad it must be to the BTC network for people who INCREASE those values ...

Someone else I was discussing this with suggested that p2pool decides to drops transactions itself based on performance, it wont use all the txns given to it by bitcoind ... is that correct?
Interestingly related to that is that python sucks badly.
On my Quad core Q9300 2.5GH/s with 8GB of RAM, that is running p2pool, it sometimes hits 9x% CPU ... ouch ... but will never go beyond that since it is single threaded ... so a low power CPU will indeed suck badly in p2pool CPU performance during e.g. block changes