Join me in the biggest mining pool boycott Bitcoin has ever seen

[DeathAndTaxes]

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.

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.

[-ck]

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.

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.

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.

[DeathAndTaxes]

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.

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.

[slush]

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

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

[DeathAndTaxes]

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

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

As opposed to any other share?

[slush]

As opposed to any other 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...

[DeathAndTaxes]

As opposed to any other 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...

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.

[Meni Rosenfeld]

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

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

As opposed to any other share?

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.