Topic: A guide for mining efficiently on P2Pool, includes FUD repellent and FAQ - page 4. (Read 174901 times)

Thanks! That's it...actually now seeing it I remember where it was...man im loosing it lately...too much stuff going on..lack of sleep
At least now it's documented

I think this is what you are looking for around line 53-55:

main.cpp:
/** Fees smaller than this (in satoshi) are considered zero fee (for transaction creation) */
int64_t CTransaction::nMinTxFee = 10000;  // Override with -mintxfee
/** Fees smaller than this (in satoshi) are considered zero fee (for relaying) */
int64_t CTransaction::nMinRelayTxFee = 1000;



:-)

where in the coin source (ex: https://github.com/bitcoin/bitcoin/tree/master/src). Different coins prob. have different default minimums.

The p2pool-vtc repo already has my patch applied.

The subtly hidden readme.  ;-)  Usually they just say "see docs".  lol.

edit:  that did it.  Thanks for the pointer.  I'll check out your mod for it next.  ;-)

Check the README file for instructions on installing the vertcoin_scrypt module.

vertcoind is running fine, and I was going to try running p2pool on VTC to try out your mod, but am getting an error:

exceptions.ImportError: No module named vtc_scrypt

Any suggestions one what dependencies on Ubuntu 13 are needed for p2pool?  I am using the donSchoe / p2pool-vtc fork from github.

:-)

You could change networks.py to try and have a lower share difficulty but it'll go back up once more hash power joins the network. The way p2pool is designed, there is always going to be some level of hash power that is so small the variance is too high for people to stomach. For them it's probably better to use a proxypool like doge.st is designing.

so in the end there is no hope for small cpu miners using p2pool?
if your hack is not enough for them to get accepted shares, would a fork like the vertcoin one be?

http://www.reddit.com/r/vertcoin/comments/1xlp8i/attn_all_p2pool_operators_p2pool_update/

The issue is that bigger miners are given higher share targets so they don't use up too much of the share chain themselves. p2pool is designed around the idea that each miner is running their own node. So a node = a miner. Thus, a node scales the difficulty for the workers connected to that node (all of your mining gear) to a higher level if you have a high combined speed.

This causes an issue for a public node with lots of small miners that the target share difficulty is being set to the combined total speed, not each miner's speed. So 100 people at 5GH will each be given a target share difficulty for a 500 GH miner. The same difficulty a 500 GH miner would have on his own private node. If these miners ran their own private node with just 5GH of speed, they'd have lower targets. So that is what my patch did, lower the target share difficulty for an address based only on the addresses' speed, not the node's total combined speed. This is also why the patch does nothing for a miner running his own private node, you already have a target based on your personal speed.

My patch changes the vardiff algorithm as above. If you set a target yourself with /DIFF, then the vardiff isn't used and my patch does nothing. /DIFF also overrides the dust prevention so you'll get the smallest shares you can no matter how little they pay. This can result in tx fees that cost more to spend the shares than they are worth. I don't think people should do that if they are mining long-term, but it's the easiest way to try and make "Why am I not getting paid" complaints go away.

No matter what vardiff does or what /DIFF you set, you will never get a share difficulty target below the minimum share difficulty for the network.

But if small mining rigs run their own node, it still seems impossible to get rewarded (my p2pool environment shows enough hashrate to at least find a block several times a day). If I understand it correctly you are forcing the node (not the pool) to give you a small share difficulty, but if you run your own node it will be using standard difficulties anyway?

roy7 you have my deepest respect for your efforts to make p2pool useable for small miners. However I still cannot follow how this can be achieved, I'm talking cpu-mining for scrypt coins. My current try is to setup a node on each cpu-machine and connect to their localhost using your hack /0.0001. Is this overkill?

BTW: I'm not aiming for botnets, they may be better off with centralized pools anyway, but for a build-in mining functionality in a coin wallet.

Probably in  ~/.bitcoin/bitcoin.conf

e.g.

mintxfee=0.0001
minrelaytxfee=0.0001
blockprioritysize=8000
blockminsize=10000

Then your bitcoind will use those to construct the block.

In most alts it is in the same spot, with a different name.

Assuming I understood what you were asking.   :-)

Anyone know where (in the coin source) the default mins can be found? Searched but could not find it. Trying to see what would be good values for some altcoins.

My patch has no effect on running your own node. It's purpose is to let each miner on a public node get the share difficulty target they would get as if they were running their own node.

To control your miner's difficulty target put /DIFF after your username you are using to connect to your node with. If you use a tiny one it'll make sure you always find the smaller shares possible (whatever the pool's minimum share difficulty is for that time).

someone mentioned here https://bitcointalksearch.org/topic/m.5030281
that a possible solution to run p2pool with a low hashpower would be to mine to ADDR/0.0001

my question is: how do i add this running my own p2pool node using run_p2pool ?

Ok, thanks. It was late and I read the comment differently. It is slightly ambiguous especially right before bed 

It's the *default* maximum, they can't change the protocol maximum without invalidating some previous blocks which would break the current blockchain.

Was looking into using blockmaxsize=1000000 and started digging into the source code for bitcoin to confirm it's benefits.

Found that in 0.9.0rc1 it is increasing the default -blockmaxsize to 750K and that it is the MAXIMUM size for mined blocks.

/** Default for -blockmaxsize, maximum size for mined blocks **/
static const unsigned int DEFAULT_BLOCK_MAX_SIZE = 750000;

The old version was:
-/** The maximum size for mined blocks */
-static const unsigned int MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/2;   (500K)

Unless I'm missing something does this show that setting blockmaxsize=1000000 has no effect on mined blocks?

Source:
https://github.com/bitcoin/bitcoin/commit/ad898b40aaf06c1cc7ac12e953805720fc9217c0

Actually with hindsight the "Avoton" maybe a better choice than the "Rangeley" - http://www.ebay.com/itm/Supermicro-SuperServer-SYS-5018A-TN4-Intel-Atom-C2750-200W-1U-Rackmount-Server-/321240339066

He probably would be better off installing ESXi like I have on my IBM System x3400 M3.