Topic: Join me in the biggest mining pool boycott Bitcoin has ever seen (Read 13204 times)

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.

No it hasn't. The full tx set is not required for shares which don't solve the block.  Sure a miner could make up a bogus tx set and submit shares but the miner doesn't save any work and doesn't benefit the miner in anyway.  To avoid getting caught the miner would need to never submit any shares which produce a block.  In essence this is just a more complicated form of block witholding.  In the miner wants to withhold blocks it is far easier to just do that.

The pool needs to verify the coinbase is part of the tx set otherwise the miner could submit non-pool work but this doesn't require the full tx set.  That is the whole point of using merkle trees.  How would I be financial ruined by only performing the "a" & "b" validations below.  How would I incur losses which are greater than an attacker just withholding blocks?  Please be specific.


For non-block shares only two things need to be verified
a) the blockheader = no different than stratum or getwork
b) the coinbase to verify it is part of the merkle set = only the merkle branch is needed.

Any pool is already doing "a",  if the miner supplies the tx set the only additional verification needed would be "b", and that doesn't require the full tx set, it doesn't require the computation of the full merkle tree and you still haven't explained why it would be this massive overhead.  I would point out this isn't something I came up with.  The use of a merkle branch to validate a specific tx without the full tx set is already used in merged mining, p2pool, and SPV clients.

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.

Well actually Meni did.   I am glad you agree that GBT is not worse security-wise.   I don't see how it is significantly worse performance wise.  The full tx set is not necessary for non-block shares.  The pool can ensure the miner isn't not working for himself using the merkle branch and the blockheader.  Please describe why it is significantly worse performance wise.  There is some overhead but that overhead can be offset by the pool just requiring higher difficulty shares when the miner selects the tx set and in return the risk of centralization is significantly reduced.

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.

Right and my point is that today every single pool in existence is subject to a much easier withholding attack called "don't submit any hashes which solve the block" and not a single pool in existence provides any enhanced payout based on the tx value of the block so there is absolutely no additional revenue for such an attack.

So I don't really see using GBT as being ANY WORSE that what pools are doing right now.  The major difference becomes that the miners are in control of tx selection.

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.

That was my point.

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

The pool can verify the coinbase tx is part of the merkle tree by the merkle branch without need for the full tree.  Sure the miner could select a set of txs with low or no txs fees but compared to the ability for a miner to simply withold all blocks it is a negligible threat.  

Today without using GBT block withholding is a significant risk.  The risk isn't increased by using GBT.  

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.

It is still the same sha256(sha256(header)).  The only additional step is verifying the coinbase tx is part of the merkle tree.  If that is what you mean by "full validation" then ok but it isn't a significant overhead and the pool could simply require higher difficulty shares to compensate.

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...

As opposed to any other share?

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

Thanks for the correction.  Why would it be expensive in terms of bandwidth?  For shares which don't solve a block the tx set isn't needed.  The merkle root, and merkle branch is sufficient to verify the attempted share has the correct coinbase tx.   Shares that do solve a block are rare enough to be a rounding error on bandwidth requirements.

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.

In theory yes but it requires
a) The pool support a mechanism where the miner not the pool handles tx selection (getblocktemplate is one possible solution but others could be defined).
b) The miner has a local bitcoind running to independently select transactions.
c) The mining software supports the system.

If you mean as of right now? The answer is no.  GHASH (and AFAIK all other major pools except Eligius) support no mechanism where the miner can independently select the tx set for the next block.

from one of the comments:



is this possible? That would be interesting. that way i can benefit from all the features of Ghash without giving them my power to vote/doublespend. In fact, everyone should do this, so they can vote individually and prevent doublespending, while still enjoying the benefits of your favorite pool.

Hi Technomage,

I am a BitCoin novice user and only started micro mining a couple of weeks ago. But what you say is very sound. Facts and the true are always clear but some people try to hide from the majority or obfuscate them for their own selfish ends.

The bottom line is that if there are only a few large mining pools, these operators can hold us to blackmail and as you say, make the decisions on the development of the BitCoin protocol to suit their own ends.
Thank you for raising awareness on this vital issue. I think the long there danger of creating a few big mining pools doesn't ever appear on most small time miner's radars. They go with what is easy and what their friends have done. It's not feasible for me to implement P2SH mining at this time as I have under 10 GH/s processing power. I think I read the minimum recommended hashing power for implementing P2SH is 40 GH/s

Keep up the good work!

Best wishes,
Zephyr