Pool Double-Spend Solution

[Raystonn]

Getblocktemplate gives miners knowledge of the transactions they are mining.  That means mining apps can check the public blockchain to see if they are mining a double-spend for coins already spent.  It would be a waste of money to continue mining a double-spend block, as the miner would ultimately get no reward from hashing on that block.  So now miners will have a financial incentive to avoid processing double-spends.  In addition to getblocktemplate, we need a standard way for mining apps to query if a block is a double-spend from the Bitcoin network.  This needs to be queried not from the pool (obviously) but from a Bitcoin client.  We need to make this easy for mining apps to implement so they pick up this functionality quickly.

With this solution in place, pools will no longer be a threat when they exceed 50%.  A single person/group owning more than 50% of the hashrate could still be a problem, as they could choose to disable the double-spend checking on their own hardware.  But this should fix the hashrate coming from hardware distributed around the planet.

[DannyHamilton]

we need a standard way for mining apps to query if a block is a double-spend from the Bitcoin network.  This needs to be queried not from the pool (obviously) but from a Bitcoin client.  We need to make this easy for mining apps to implement so they pick up this functionality quickly.

Since the pool creates the block, and doesn't broadcast it until AFTER it is solved, it is impossible to determine if the block that the miner is working on contains a double spend unless you get the information from the pool.

[Raystonn]

we need a standard way for mining apps to query if a block is a double-spend from the Bitcoin network.  This needs to be queried not from the pool (obviously) but from a Bitcoin client.  We need to make this easy for mining apps to implement so they pick up this functionality quickly.

Since the pool creates the block, and doesn't broadcast it until AFTER it is solved, it is impossible to determine if the block that the miner is working on contains a double spend unless you get the information from the pool.

No, that's the old getwork mining protocol.  What we're discussing here is the newer getblocktemplate protocol.  Please read more about it here: https://en.bitcoin.it/wiki/Getblocktemplate.  What we need in addition to this is a way for mining apps to check the blockchain and compare against the current block.

[DannyHamilton]

I dont understand what problem you're trying to solve. Either the pool supplies the merkle root (and not any information about the transactions) in which case it isn't possible to know if there is a double spend,  or the pool provides transaction information (or allows you to build your own transaction list) in which case you have the information needed to determine if there is a double spend.

[Raystonn]

It's the latter.  But the mining app still needs a standard way to compare against the data in the blockchain.  We want this to work the same on all Bitcoin clients.  Then the miner simply runs a Bitcoin client, the mining app, and points the app to the pool and client.  And voila, no more double spends being hashed by miners connecting to a pool.  This protects against a pool operator directing his pool of miners to hash his double spend attempts.

[kingscrown]

The idea is not bad but im not sure if we are ready technically to implement it

[Raystonn]

The idea is not bad but im not sure if we are ready technically to implement it

The new mining protocol is already implemented.  We need to design the client interface that mining apps will use.

[Raystonn]

The idea is not bad but im not sure if we are ready technically to implement it

What would be the next step here?  What is the process for getting this idea before those who design standardized client functionality?

[Tzupy]

Good idea OP, if it's possible to implement. But asking here is not going to help, I suggest you contact a Bitcoin core developer about it.

[conroe64]

Couldn't the client just check whether the current block given by the pool for it to work on is chained from the latest block on the publicly available block chain? This would prevent the double spend scenario as well as prevent a pool owner from attempting to revert a transaction that was already added to the block chain. It would also seem easier then trying to search through the block chain for double spends.

[Raystonn]

The mining app should give whatever data is available through getblocktemplate to a Bitcoin client.  That client should check it and tell the mining app if the block looks acceptable for mining.  Each client can implement the check however it sees fit.  But the interface offered by the client to mining apps should be standardized.

[erono]

good idea. It is not possible to determine where a block came from. The statistics currently only work because pool operators allow their blocks to be easily identified as "mined by xyz", they could just as well begin mining anonymous blocks.

[Raystonn]

good idea. It is not possible to determine where a block came from. The statistics currently only work because pool operators allow their blocks to be easily identified as "mined by xyz", they could just as well begin mining anonymous blocks.

If you folks like this idea, can we get it pushed through to a core dev.

[gmaxwell]

If you folks like this idea, can we get it pushed through to a core dev.

I believe there is nothing to implement in bitcoin core here.

It's already possible to query a local node for such status— e.g. the gettxout rpc exists right alongside getblocktemplate.

But, it's likely meaningless to do so— blocks cannot contain double spends relative to their _own_ chain, so including one would be more or less harmless to the network (it would just result in the miner producing an invalid block the network ignores). Rather the case that you need to worry about is when the block and the local node are on separate forks, in that case some different spends between them are expected and— importantly— can be triggered at any time by people relaying different data to different parts of the network.  Inconsistency does not show misbehavior and, in fact, cannot be avoided otherwise— eliminating inconsistency is why we have mining.

The better thing to do is to simply have a local node provide the chain and transactions while the pool provides only the coinbase. This is pretty much facilitated with GBT already at a protocol level, then the pool centralizes the miners payments but not the state of the network rendering it harmless to anyone except the miners (the pool could still rob the miners blind, as they currently can).

But, not surprisingly none of the miner software implements this and none of the pools care to do so... P2Pool already accomplishes this PLUS preventing the miners from being robbed by pool operators. Those who care are already using P2Pool and everyone else is happy with what they have already.

[Willisius]

If you folks like this idea, can we get it pushed through to a core dev.

I believe there is nothing to implement in bitcoin core here.

It's already possible to query a local node for such status— e.g. the gettxout rpc exists right alongside getblocktemplate.

But, it's likely meaningless to do so— blocks cannot contain double spends relative to their _own_ chain, so including one would be more or less harmless to the network (it would just result in the miner producing an invalid block the network ignores). Rather the case that you need to worry about is when the block and the local node are on separate forks, in that case some different spends between them are expected and— importantly— can be triggered at any time by people relaying different data to different parts of the network.  Inconsistency does not show misbehavior and, in fact, cannot be avoided otherwise— eliminating inconsistency is why we have mining.

The better thing to do is to simply have a local node provide the chain and transactions while the pool provides only the coinbase. This is pretty much facilitated with GBT already at a protocol level, then the pool centralizes the miners payments but not the state of the network rendering it harmless to anyone except the miners (the pool could still rob the miners blind, as they currently can).

But, not surprisingly none of the miner software implements this and none of the pools care to do so... P2Pool already accomplishes this PLUS preventing the miners from being robbed by pool operators. Those who care are already using P2Pool and everyone else is happy with what they have already.

I can feel the disappointment in that last paragraph.

[DeathAndTaxes]

I can feel the disappointment in that last paragraph.

The disappointment is in the human failing.  The problem isn't a technical one, it is a human one.  There ALREADY is a robust solution to centralization.  However individuals have decided it is easier to hand over their independent mining to centralized elders.   In the last two weeks we have seen a flurry of dubious and poorly thought out "solutions" which are inferior to systems like p2pool or GBT which have existed for years.  

Miners simply don't care.   Even if one came up with a new solution which was superior to p2pool or GBT, the evidence to date would indicate that miners would not adopt it to any higher degree than p2pool or GBT.  I mean just as an example, Bitfury has over 1 PH/s of hashing power yet they mined on the largest pool, contributing to the centralization of the network.  A friggin petahash, they could simply solo mine with a negligible difference in monthly variance, or they could have supported p2pool, or split their hashrate among five smaller pools.  Of all the possible choices, they picked the one that was the laziest and more ignorant.  This is an organization with resources and knowledge to know better.   Even once they saw GHASH's portion of the hashrate growing from 30% to 35% to 40% to 45% they did nothing.   The "51% scare" probably would not have occured if they simply moved before it got that high.  Instead the once again took the laziest and more ignorant option available, remaining on the largest pool until it went over 51% of the hashrate.   Of course they then with great fanfare left as if the community should have cheered their courageous decision.  If miners don't care to protect the network better through their actions, well coming up with better technical solutions for them to ignore due to laziness or ignorance isn't likely to change much.  Is it?