Quote from: iddo on May 31, 2014, 01:36:48 AM

Quote from: Meni Rosenfeld on May 28, 2014, 09:36:22 AM

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.

Actually, there isn't supposed to be anything secret in the data that the node prepared, right? So in the rare occasion that the miner solves the block, he can broadcast it immediately to the network, and then he (or other members of the pool) can collect the transactions that the node used to create the block, and send all these txns to Bitcoin peers so that the solved block would be valid? In fact, the users who created those txns (and other Bitcoin nodes who just wish to see smooth continuation of the blockchain) have an interest to also pitch in and help with making the solved block valid? The only way to avoid this freeloading issue is if the node that created the block will incorporate a "dummy" txn that has never been broadcasted to the network? That might be messy because of the headers-first sync optimization that Bitcoin clients will probably have by default, i.e. while the broadcasted solved block is considered to be a valid candidate by the network, the miner could say to the node that he agrees to pay only half the fee in exchange for releasing the dummy transaction, or other such forms of abusive behavior?

Edit2: Actually I was very much confused, the data is indeed not secret, but I missed the point that the miner only has one branch of the Merkle tree, therefore it should be infeasible to try different permutations with unconfirmed txns, especially if the volume of unconfirmed txns is high (which is one reason why we need multi-PPS in the first place).

Right, as I was reading your comment, my first thought was that even if the miner knows which txs went into the block, there are still 2^n possibly orderings which only the node knows.

Quote from: iddo on May 31, 2014, 01:36:48 AM

The extra round-trips of communication between the node and the miner imply that the current form of centralized pools will have an advantage over multi-PPS, especially if the average blocktime is less than 10 minutes as with Litecoin etc., right? Wouldn't this advantage override the benefits of multi-PPS, meaning that miners will prefer not to use multi-PPS because of this?

I don't think it's a significant overhead, because the data that needs to be communicated is small, and because there will likely be nodes in physical proximity to the miner, so latency shouldn't be high.

Furthermore, the advantage of Multi-PPS is significant, commensurable with several percent of the revenue. For example, if miner-node latency is 0.1s, and time between blocks is 600 s, the lost revenue is 0.017% while the gain is 3%.

This does indeed worsen with faster block times, however this might be solvable with new block graph structures.