Post
Topic
Board Pools
Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
by
merelcoin
on 26/06/2017, 09:26:53 UTC
  • I set a 1% pool fee, meaning that if somebody on my node mined a block, i would get a 1% cut... Seems fair. But i've also seen a node setting a +90% fee, does this mean that he gets an equal cut when somebody on an other node finds a block, but when he finds a block he can keep +90% of the block reward?
It is only the percentage of the particular address's earnings, not the whole block reward.

  • i can setup my node so it doesn't broadcast new transactions. If i do this, can i put my own (secret) transactions in a block or do the other nodes also have to know my transactions? I know the chance of hitting a block by yourself are astronomically small, so it's just a theoretical question.
I think the short answer is, yes.

  • Can i prioritise my own transactions, so that if a block gets mined on my node, my own transactions have a better shot of being in this block?
How is this different than the last question?

  • If i find a share at a time when there is a dip in the p2pool network's hashrate (so the diff of the sharechain is lower), does this share have an equal value to a share that is found at a time of high hashrate (so high diff)?
Yes, p2pool is PPLNS regardless of the current difficulty. If the difficulty is high, you find less shares and vice versa.

  • I tried a setup where i merge mined several coins, the log didn't show any errors, but for some reason i didn't find a single share on the BTC sharechain anymore (at the time i should have found 6+ shares, but i didn't find a single one... This could be due to variance, but the odds of this should be small). Is there a potential pitfall i missed when setting up merged mining, or was i just very, very unlucky?
There is not enough information without your logs to answer this question.

Thank you very much for the answers, they were exactly what i needed.

Just to clarify, i tought there was a difference between creating a transaciton and not broadcasting it (so it would only exist in my own mempool) and creating a transaction, broadcasting it, but only prioritizing it on my own node (so it's in the pool's mempool, but it has a higher priority in mine).

About the logs for my merged-mining setup, i can probably re-setup the merged mining and re-run my experiment (i disabled the merged mining setup since i couldn't find any shares), but what basically happened is:

I setup my node, started my daemon, waited untill it synchronised
I setup the merged mining coins, let them synchronise (not at the same time as my main daemon, since the I/O was to high)
I started p2pool in this way:

Code:
python run_p2pool.py -f 1 \
--merged http://[redacted]:[redacted]@[ip]:[port] \
--merged http://[redacted]:[redacted]@[ip]:[port] \
--merged http://[redacted]:[redacted]@[ip]:[port]

Then i tail'ed the log, i saw following things:

Code:
Got new merged mining work!
Pool: [hashrate] Stale rate: [stalerate]% Expected time to block: [x] days
Local: [my own hashrate] in last 0.0 seconds Local dead on arrival: [DOA] Expected time to share: [time to next share in minutes]
Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: [expected payout]

When looking at the merge mined coin's debug log, i could got a line like this all the time:
Code:
CreateNewBlock(): total size [size]

Now, it looks like everything works 100% fine. My hashrate is registered, so i must be sending pseudo-shares. The merged mining also seems to work, since the merged mining daemon asks for a new block all the time... However, i kept running this setup for a couple of hours, and it should have generated 7 or 8 shares (on average) during this time, but it generated 0.
I then stopped p2pool started it without the --merged options, let it run for about the same timeframe and got 6 or 7 shares (can't remember exactly).

The odds of this happening witout any reason seem very small to me, so i must have messed something up...