Quote from: iddo on May 28, 2014, 04:19:13 AM

1) So far this proposal doesn't explicitly describe how to pay the nodes who construct a block that contains all the transactions minus the coinbase, for their service. If it should be some sort of a subscription service where the PoW miner pays in advance, then this adds to the overhead because the miner has to identify himself when requesting a new block, and there's room for abuse/freeloading i.e. one miner pays and then shares his account (login/password) with other miners, or shares the constructed block (minus the coinbase) with other miners. Another option is that it'd be some kind of an honor system, where miners donate some portion of their profits to the nodes who provide this service, but I'm not sure if that'd be sustainable.

I think it's solvable in the following way: The node will require that the miner pays him some fee in the generation transaction. When the miner finds a valid nonce, the node will only release the full block if the miner shows him that the nonce matches a generation transaction paying the required fee. This way the node guarantees a fair share of the revenue enabled by his contribution.

Quote from: iddo on May 28, 2014, 04:19:13 AM

2) In an old thread the issue of performance was discussed, slush's reply (link) is rather pessimistic. He considers the straightforward setting where the miner submits the entire block to the pool, unlike your followup post about quizzing or using SNARK/SCIP as an improvement. Though unlike the old thread, with multi-PPS there's the added complexity of interacting with separate nodes that construct blocks for the miners, and this should also be taken into account since the miner might request several such blocks during the average 10 minutes interval, as new transactions are being broadcasted over the network. I think that BIP0022 (which probably isn't being used by anyone yet?) was inspired in part by that old thread, so I'm not sure what should be the current assessment regarding the severity of the performance issues.

I think slush is simply wrong in that post (either that or remarkably forward-thinking), as he ignores the Merkle tree structure. For the foreseeable future, the mining revenue will consist primarily of newly minted coins - and in this case, protection against directly profitable attacks (though not against sabotage) is easy by sending Merkle branches, without quizzing or advanced methods.

And, statistical quizzing methods do exist, and by the time this is relevant I hope SCIP will be practical.

(Actually GBT and similar methods like Stratum are the norm currently, they're needed to deal with the rapid rate at which ASICs exhaust nonce ranges).