Correction, Eligius doesn't allow it either. NO pool supports that. Just because pools support GBT doesn't mean they're actively allowing miners to contribute their own transaction list. That would be ridiculously expensive in bandwidth.

...but it still needs to do full validation of that share.

If you mean Stratum shares, then the difference is that Stratum job is prepared by pool itself, so there's no need to validate everything for every share. Just sha256(sha256(header)) is enough. But things are different once every miner can pick completely different transactions to hash...

The pool knows that the miner did work, and that the work cannot reward anyone else. But without requesting the full tx set, it doesn't know there actually is a tx set which hashes to the given Merkle root. The miner could be making the whole thing up.

When tx fees are meaningful, this could be used for more than just a variant of block withholding. The miner can misreport the total tx fees in the block he offered, and obtain more payment than his work is actually worth.

This can be solved with SCIP.

Since smart miners are essential for Multi-PPS, I discussed it in that thread as well.

Block withholding has nothing to do with used protocol. Such attack can be used for getwork/GBT/Stratum.

No.

If there is a Merkle tree of valid txs, the Merkle branch proves that the tx at its leaf is a part of the tree.

It does not prove there even is a tree. At each depth of the branch, the miner can make up a completely random hash to concatenate with the deeper hash.

Like I said, block withholding is possible without this but it's difficult to make money from block withholding. With what we have here, the miner can solicit from the pool more payment than he's due (I'm assuming an evolved reward method), that is, an actually profitable attack.

Apples and oranges. Nobody said GBT is worse security-wise. Just performance-wise. There's big difference if the pool needs 10 servers or 100 servers around the world, because of change in share validation process.

Thanks god you're not running the pool. You would be financially ruined in few hours . Just kidding :-)).


It has been already answered by me and Meni. With Stratum, server choose set of transactions willing to include to block. Do full validation like finding outputs to spend, check limits of script and so on. Then it prepares merkle tree and everything stores *internally* to its memory, under so-called "job id". Then server broadcast merkle branch (part of merkle tree) to *all* connected miners, with proper job id. Once miner submits share with given job id, pool just takes precalculated and already verified data from its memory, do sha(sha(header)) and checks if the share is valid and/or winning.

When the pool offer miners to pick their own transactions, then the story is completely different. Pool still *must* check all shares like in Stratum, because it credits the miner by small portion of bitcoins (in PPS, for simplicity). But pool must do the same validation for every submitted share. The same work which is done once per 30 seconds for all connected miners in pool.

Of course there's some space for shortcuts, like validating proof of work for every share, but do the full validation only for few shares. I was not thinking about this too much, but I bet it will open Pandora box with some side channel attacks to the pool, like pool hopping in proportional pools.

Actually I think that ratio 1:10 for Stratum vs full share validation was rather conservative.

For the 3rd time, yes, block withholding is equally possible with classical pools and with unverified GBT. Block withholding is not the problem because it is difficult to monetize it, hence, few will attempt it. The first time I mentioned block withholding here, was in the sentence "this could be used for more than just a variant of block withholding".

The real problem - which is perhaps difficult to see now because it will fully manifest later on, when coinbase is negligible and tx fees (which are ever-changing) are significant, and reward methods will adapt accordingly - is faking the total tx fee. To prevent pool hopping, reward methods will be more similar to PPS, with the payment for each share depending on the total tx fee of the block it tries to become. If the pool doesn't verify the miner's tx set, the miner can report a higher total tx fee than there actually are in the block, tricking the pool into paying more than his work is worth. This attack is profitable, and hence, everyone will do it if the pool allows it.

And of course, to prevent this attack, GBT pools should verify the tx set, hence increasing bandwidth.

As mentioned, I think the problem should be solved with SCIP. I gave my own version of why GBT without verifying tx set is bad, if not now then in the future; slush should explain why he believes the whole tx set needs to be verified.

Again - it verifies that the tx exists in the Merkle tree with the given root, assuming the Merkle tree exists. It does not prove that a Merkle tree exists. This distinction is of no importance in some other use cases you mentioned, but it is important here.