[invalid idea] SPV mining full blocks

[Explodicle]

EDIT: knightdk points out the obvious fatal flaw in this idea below. Leaving it up for reference only.

A couple months ago I talked to maaku about mining pool centralization and possible avenues to reduce it. Here's the problem:

Pools have an incentive to co-locate because it reduces the time to download blocks from each other, during which they need to SPV mine an empty block. Right now mining pools don't suffer a major penalty by not co-locating, but this penalty will increase as the subsidy shrinks and would get worse if the block size were to be increased.


Let's assume that SPV mining empty blocks is not a sufficient long-term solution. Full-block mining currently requires that miners download and verify the previous block, so they know which new transactions may be included.

BUT, what if we prohibit transactions which use outputs from the previous block? Miners would then be able to SPV mine a full block using only the header of the previous block, certain that it's valid.

Possible attack vectors: an evil miner could either

• Upload a header for an invalid block, or
• Upload a header but not upload the whole block

However, I'm not convinced that these would be cost-effective attacks. The invalid block would still need to reach the current difficulty just to forfeit its entire block reward, and not uploading the whole block would increase its risk of being orphaned. I think these attacks would be as expensive as a 51% attack; the miner is spending more than he costs others just to create a temporary disruption.

This unfortunately adds the annoyance of being unable to receive and spend your coins in adjacent blocks, but you could still do so within the same block. My hope is that coin control could make this limitation less of a problem until lightning channels do away with the issue entirely.

What are your thoughts, technically-minded bitcoiners? Could this work as-is to promote pool decentralization? Is there something you would change to make it better? Is it only worthwhile once low subsidy and/or block size make pool centralization a larger problem? Any input would be greatly appreciated.

[achow101]

How would you know whether a transaction has an output in the previous block if you don't know what transactions were in that block? Additionally how would you know whether an unconfirmed transaction which uses an older output was not confirmed in the last block?

[kano]

...
Pools have an incentive to co-locate because it reduces the time to download blocks from each other, during which they need to SPV mine an empty block.
...

1) The need for SPV mining is an urban legend
It is driven by an unsubstantiated excuse to very marginally reduce the average small amount of time necessarily spent mining on stale work
Empty blocks are a reward paid for doing no new transaction confirmation ... and interesting that I don't see the non-mining community getting up in arms about it even though it's been going on for quite a while ... ... ...

2) Some pools SPV mine empty blocks, other pools 'supposedly' verify the block before mining an empty block
e.g. Eligius say they don't SPV mine but still send out empty blocks due to crappy pool software - that I still to this day wonder why people mine there when they know they are getting paid well under the expected payments of low fee based pools
I've run comparisons between my pool, that never elects to ignore gbt transactions available, and eligius that mines empty blocks, and my pool work change time averages significantly faster.
... also so far my pool has never mined an empty block - it would only happen if there were no transactions supplied by the gbt call

3) The cause of SPV mining is Luke-Jr
On his pool he had a period of high orphans (that other pools DID NOT have at the time) and relegated the blame elsewhere rather than his pool code.
One of his solutions he implemented was to have his pool mine a maximum of 32 transactions per block for 5 months
He wrote the gbt code commit in bitcoin core.
He bypasses the gbt call on block changes due to his excuse that his gbt code in bitcoin is too slow
Other pools have copied this idea from him.
Other pools now use the extended version of this known as SPV where they don't fully check the block before generating a block header

Thus a little history about SPV

Since one important premise in your opening I quoted is incorrect, you may want to revise it all ...

[Explodicle]

How would you know whether a transaction has an output in the previous block if you don't know what transactions were in that block? Additionally how would you know whether an unconfirmed transaction which uses an older output was not confirmed in the last block?

EDIT: *slaps forehead* I don't know how I didn't think of this.

The need for SPV mining is an urban legend
It is driven by an unsubstantiated excuse to very marginally reduce the average small amount of time necessarily spent mining on stale work

Although this cost is very marginal now, it does still exist, right? The reason I'm asking is if we did want to increase block size so much that it took, say, 30 seconds to download and verify.

[kano]

How would you know whether a transaction has an output in the previous block if you don't know what transactions were in that block? Additionally how would you know whether an unconfirmed transaction which uses an older output was not confirmed in the last block?

EDIT: *slaps forehead* I don't know how I didn't think of this.

The need for SPV mining is an urban legend
It is driven by an unsubstantiated excuse to very marginally reduce the average small amount of time necessarily spent mining on stale work

Although this cost is very marginal now, it does still exist, right? The reason I'm asking is if we did want to increase block size so much that it took, say, 30 seconds to download and verify.

The issue with this, that no one ever bothers to deal with, is there's no verified data regarding the time and CPU power required to verify blocks, based on their size and complexity.
Yes you can already make a block that takes a long time to verify, but they are not your run of the mill blocks.
There may even be a reasonable solution to this of being able to calculate the complexity of a transaction and/or a whole block and reject it across the board and solve the problem that way. Who knows
The current transaction selection code in bitcoin (getblocktemplate) isn't written by the smartest guy around ... quite the opposite.
He bypasses using it himself ...