Quote from: adam3us on May 05, 2013, 01:06:38 PM

In this way reward can not be reassigned, without redoing the work, and other than the pre-mining attack, you could basically operate with zero-trust (give out the ssh root private key to the serer without loss of security.)

The proof of contribution merkle tree could even be published to the full network, and included as part of the reward verification, then the pool wouldnt need to be trusted at all in terms of provable no skimming. Of course the pool is still trusted with validation (by those pool miners who dont build their own blocks nor independently validate the pool constructed blocks).

Actually I think something a bit more is needed or a dishonest pool could still skim by handing out different merkle trees to different miners. (Miner A would see his past contributions in the merkle tree path he receives, Miner B similarly, but A's contributions could be missing from B's tree path and vice-versa. The dishonest pool could then plausibly deny the tree path as a fabrication. Probably an ECDSA signature from the pool could fix that (from the reward private key, or separate "fairness" key pair). Miners can audit the blocks, and in the unlikely event of a pool skimming can prove it, which could create reputation problems for the pool. Or as before more directly publish the proof of skimming to be validated by the network with some outcome - eg block declared invalid, or pool fees reassigned to first skim prover (a kind of multisig). I think a signature is not quite as desirable as the verification is higher than for hashes, but I dont so far see a network efficient way to avoid it. Anyway the signature does not have to be published nor verified unless the pool cheats so that is probably acceptable. If the punishment for cheating is that the block gets invalidated, there is no reward possible from any form of hacking of the pool server including obtaining its fairness private key.

It would be possible to have a fair exchange protocol as part of the mining share submission (as the signed proof of past work is delayed until after the work is submitted, a dishonest pool could accept a mining share work proof, and then not respond, claiming network error). However fair exchange is a tricky somewhat computationally inefficient area of cryptography involving an arbitrator in event of dispute, and fair exchange doesnt seem that necessary - the pool doesnt want to lose miners, is probably deterrence enough.

Adam