Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
I guess my first question is can anyone tell me why something like this would not work?
Not sure how micropayments are connected to the core problems of P2Pool being the performance/scalability and the relativity of higher hashrate to larger share diffs.Unless it's in reference to what was said before, the ability to "credit" smaller miners for work they have completed which may have fallen off the chain because there's been no block in more than 3 days.
P2pool already does effectively do micropayments, though there is an issue with that already in that a small miner will get lots of tiny payouts that will then require more in transaction fee to spend them than the amount of the payouts ...
As for falling off the end of the chain, well that's a two fold issue.
Firstly, if you want to have a higher % of paid shares, you simply increase the size of the chain.
However, at the moment, the % of paid shares is already so high, I'd not understand why anyone would want to increase that ... due to the problem of:
The larger the chain, the larger the block coinbase transaction will be and the smaller the average size of the 'micropayments'
Edit: and just to throw an issue into the basket that same may not notice (but I consider obvious
)The bitcoin developers are effectively against p2pool since they are against micropayments.
They make comments about small transactions and large fees compared to those small transactions and how small transaction are SPAM (yeah there's a very vocal moron on the subject of SPAM)
If you watch the bitcoin debug.log of the standard bitcoind (not the abortion that moron hides changes in) you will see it spitting out comments about dust transactions and ignoring them all the time ...
Any design of p2pool that supports smaller miners or smaller payouts is directly in contrast with that unless there is some separate store of the smaller shares/payouts to be 'banked' and then paid out once they exceed some consensual limit.
The 'banking' is the issue, since the current design uses the coinbase txn as the distributed bank proof - but you can't go throwing the unpaid part of the bank in there ...
Edit2: and then to add in some possibly useful information
If you look at how a normal pool works, you see related hints on how to solve some of the problems.
An example would be large vs small miners.
A normal (good) pool adjusts the share rate to be X shares per minute based on the miner rate.
Maybe p2pool could consider some (more complex) version of that in the share chain to force miners to use a diff related to their hash rate and thus allow smaller miners to reduce their variance.
Of course it has the problem of abuse by larger miners splitting up their 'farm' to multiple addresses and thus acting like multiple smaller miners - so that would have to be resolved some way I've got no idea how