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

I'm not sure how this part works as I'm not familiar with how a block template can be manipulated. I assume that getblocktemplate is called to get the transactions to confirm in the block and the reward transaction (the one distributing the reward to p2pool miners) is added.


With 0 transactions in the block, yes.
In fact when I was worried about getblocktemplate latencies I asked if such a mechanism (using an empty block built on top of the just found new block until getblocktemplate returned a result) would make sense and explored alternatives like workarounds/hacks in bitcoind's getblocktemplate. The reply from more knowledgeable people including Bitcoin devs was that there was no need for workarounds as pools were expected to implement this for ages to avoid producing orphans and forrestv confirmed that p2pool was using this technique too.

What is the punish feature?

I think you're the one that doesn't understand, lol.

Maybe you should look at the specifics presented.

Listen, there's a reason why so many shares  get 'punished'.  

ed:  since I've disabled the 'punish' feature you'll be able to see all the orphans.  most of the time it's just one, the person unfortunate enough to have the share right before the new block, but just wait for a block where you have 2 or 3 orphans coming off of it,  some will have a received time after the new block, but still be working on old block.

I assume getblocktemplate is used to build up the actual block transactions?  So, there is a window where p2pool miners mine against a block that only contains coinbase?

Share is every 30 seconds, block in network every 10 minutes.
Even if ALL of your shares will be DOA for share chain only 1 per 20 will be DOA for network block.
So if you will be REALLY lucky, you can find VALID block 20 times from DOA share ;]

Bullshit.

After heaps of messages on this subject on this very thread (last was mine a few messages ago) you still don't understand that p2pool doesn't rely on getblocktemplate result being available to build the coinbase miners are working on.
p2pool is connected to the bitcoin P2P network and detects blocks before a getblocktemplate result is available for the new block and present a valid coinbase to miners ASAP. So there's absolutely no reason a "stale p2pool share" block would have more chance of being orphaned than any other block.

except sometimes those stales that solve blocks... are, well, a stale right after a block was found.  re the shenanigans that go on when switching from one block to another

not sure if p2pool would proceed along it's own chain or not?  either way, it's a block that'll most likely be orphaned.  that's when the slow getblocktemplate matters

holy crap:
https://blockchain.info/tx/270d0e76ac7bbe95720b95651a427bb75112005c4be8e57e3be14dadffc6ea9d

what are the chances of that!?  

This is perfectly the example of how p2pool doesn't waste more work than solo mining! This counted as a p2pool "reject" but it still paid out!

I will admit that my math was wrong, it's > 0.1% of blocks. It should be ~ the DOA/stale rate, which is pretty high actually. See your stats:
"Note that blocks may have been orphaned from the P2Pool chain and so not be here."

Ironically this just happened to me on the last block.

Well, it depends on what you mean by "override."

A winning bitcoin block is sent to the bitcoin network and to the p2pool network. Bitcoin will payout the reward normally for the found block (including the finder's share). However, if the winning block isn't on the longest chain of the p2pool sharechain, it will get orphaned by the p2pool network.

In that case, the winning block is paid out and the solver will get credit for it for the current block (in addition to the 0.5% bonus for finding it), but the person that solved it won't get a credit for the share it for future blocks on the p2pool chain. This is fair because everyone has the same chance of it happening, and it does not mathematically affect expected payout for anyone. Additionally, this is extremely rare (<0.1% of blocks found will have this).

Doesn't a winning (bitcoin) block not override the share chain?  Otherwise, that block couldn't actually be paid (by the share-chain)

no problem, they are good questions - some are answered in other places but it can be hard to find.

Yes, p2pool's internal share chain has lots of stales. But the p2pool network DOES NOT produce more bitcoin chain orphans (and thus wasted work) than solo mining.

Work is not lost using p2pool, those stale p2pool shares can still solve a block and still be submitted to the bitcoin network for reward. The time and work invested in them is not lost. Those shares just don't show up in the p2pool sharechain, but will show up in the bitcoin blockchain. The rewards for those blocks are paid out normally to p2pool users and are not wasted.

Theoretically, a 100% efficient p2pool miner that has ~5-10% stale/DOA rate will have the exact same expected value as a solominer with the < 0.5% orphan rate.

I believe this is what happens already.

In fact if I understood a recent exchange here correctly p2pool doesn't use the getblocktemplate result as-is but builds a new template itself and then use this kind of optimization.

A potential solution here would be to mine empty blocks.  When there is a new block, your miners immediately switches to a coinbase only block.  Once getblocktemplate returns a block, p2pool can switch over to that.

Yes.


The "coinbase" transaction is just like any other transaction, except it has no inputs.  There is no problem with it have 1000 outputs, as long as the block is less than 1MB total.


It is a random process.  Failed hashes aren't saved up or something.

The last 10 seconds was used to try to find the block, so it wasn't wasted.  Ofc, only 1 miner actually found one.

it is in main.cpp

int64 CTransaction::nMinTxFee = 50000;  // Override with -mintxfee
int64 CTransaction::nMinRelayTxFee = 50000;

(i think the following one just applies to your own created transactions)
int64 nTransactionFee = 50000;        

you'd also have to change the fee after the default 27000 priority transaction is full

the nMinFee = xxxx.

otherwise after 27000, it'll accept priority transactions at the .0001 rate, while using .0005 for the rest

mine has only accepted 0.0005 for a while now

Thanks for the answers!

If i understand it correctly a real bitcoin block that was found by a p2pool miner cant be stolen by him because this block already includes all the reward transactions to those miners that mined on that block. So a miner has to decide upfront if he wants to mine p2pool or solo. Deciding to change this wont work after a block was found.

That means the reward 25BTC + fees is created and in the same time these newly mined bitcoins are broken apart? I didnt think this can work because the actual block only brought this coins into existence but at the same time is splitting it. But it seems to work then.

What i meant regarding the reward. The split of the reward among all miners means that the newly mined block is not having the newest data. Up to the last 10 seconds of mining of others can be lost because not already included. 10 seconds are a good choice then to minimize this i think.

I tried to install the groupcoin wallet because at the moment i mine at bitparking.com and need an address. I dont get how its done. And there is no exchange for groupcoins to get an address from there. So maybe in the p2pool community there is a way to circumvent this by someone providing an address where i could send my rewards to and later sell it at Open Transaction? So that not everyone has to create his own wallet? Is there such thing already?

I have read its possible to mine litecoins too. Would it be possible to hire a coder that creates me a script so that i could mine any other 256 Coin with p2pool too? I have read i even could merge mine this way. Is this possible in p2pool?

The amount of lost shares in p2pool are normal. And every p2pool miner has the same. So its fair among the p2pool users.
Theory: But that means that a certain amount of hashpower is lost compared to solo mining. The shares maybe were good but they are lost and so is the amount of time invested in them.
Solution?: Am i right that this is no disadvantage to solo mining because the real bitcoin block that is found in p2pool is directly put into the network via solomining? So the lost shares does not affect in the end because for the real found block those lost shares dont exist. Correct? Then p2pool would be even better than normal pools because they have to receive the found share first and from there propagate it.

Sorry for the many questions...

This is a bit more complicated, in short in most cases this is only included if the coinbase isn't already full with more profitable transactions.


getblocktemplate latency isn't noticeable unless the CPU usage generated when it is called is enough to slow your p2pool node.

In short, unless your efficiency suffers (measured over hundreds of shares), it's fine to allow these transactions in.

This transaction:
https://blockchain.info/tx/6dad36cbfca544df4b2608dd38df0e9a91061075c780cf10acdc74e6d7f00504

added 0.3seconds to  GetBlockTemplate latency. It is 87k in size with 588 inputs and fee of 0.0093.

This is included if you have mintxfee=0.0001 as fee is over 0.0001*87=0.0087.

However we are never going to earn a lot of fees if we include TX's like this as each block could only hold 11 of them for total fees of 0.1BTC! And have latency of 3.3 seconds.


Does anyone know where in the code this is? Seems odd that it takes so long. It does not have to check sigs or anything like that.

Running Bitforce-SC 60Ghash for last few days and working perfectly.
Have 73 shares (4 Orphan, 4 dead) 104.6% (93-111%) efficiency. And I have had some issues with my ADSL line so a few could be due to that.


Below is all taken from https://bitcointalksearch.org/topic/a-guide-for-mining-efficiently-on-p2pool-includes-fud-repellent-and-faq-153232
Post is just to say it is good advice.

Setup is:
p2pool and bitcoin client running on Win7-64bit i7 quad core with their data files on ssd disk. This is connected to internet via ADSL 7mbit down 1mbit upload (12ms ping time to www.google.com). Enabled QoS on 2 ports (no idea if this helped!).

Running p2pool (13.4) with these switches:
--max-conns 16 --outgoing-conns 8
Have 8 outgoing and 1 incoming - never seen above 4.

Running bitcoin (0.8.3) with:
blockmaxsize=1000000
mintxfee=0.0001
minrelaytxfee=0.0001
maxconnections=15
This gives me a 0.2 second getblocktemplate latency. I did have mintxfee=0.00001 but then latency was 1-2s! Again no idea if this caused issues just did not feel good. I have 10-15 connections.


Miner is a VERY old laptop (8 years?) with WinXP and cgminer (3.3). Is connected to other machine with a pair of homeplugs (due to miner being so loud it is banned from house and in garden room!). Ping latency is 4ms is stable but very low bandwidth due to distance/mcb's.
Run miner with /+100 at end of user name so only report 100 diff shares. This is to reduce load on laptop and bandwidth used. Again do not know if this is helping.


Will experiment with different settings over next few weeks.

On another note - the web front end say "Expected after mining for 24 hours:".
But this is wrong - it should say at the moment "... after 35.4 hours" as the expected block time is 11.8 hours. Does everyone agree with me on this? Just that it is confusing for new users.
Also would be good if there was an "expected income per 24 hours" that just did the multiplication of this by the number of blocks expected each day (2.0339 at the moment). If all agree I am correct might submit a patch if I find the time!