Bitcoin Stack Exchange is a question and answer site for Bitcoin crypto-currency enthusiasts. It only takes a minute to sign up.
Sign up to join this community
If some large number of the mining pools started publishing what transactions they are planning on including the danger of accepting a zero confirmation transaction would be reduced dramatically.
Has there been any thought on this that I could read up on?
You are effectively looking for a centralised entity to provide you with a prediction of the future behaviour of a decentralised entity (asking a mining pool to predict the blockchain).
Even if one or more mining pools share this information, I do not believe it will provide you with a significant risk reduction in accepting transactions with zero confirmations.
Knowing that the transaction has been accepted by a mining pool simply means that it is a valid transaction with a sufficient fee for that pool. This gives no guarantee that it will not be orphaned by a rival block or rejected from another pool in favour of another transaction which double spends the same input(s) with a larger fee. These things may not have a high probability but if you're going to assume they won't happen then you are accepting a small risk of the transaction failing. This risk is there regardless of whether the pool has announced it is including the transaction.
The transaction still has zero confirmations and it is only in the case that the transaction sender is not an attacker that you could trust that the transaction will eventually be confirmed. If you are trusting the sender not to be an attacker then you do not need an announcement from a pool. It is unlikely the sender would accidentally send an invalid transaction or one without sufficient fees. If you do not trust the sender then you should wait for an appropriate number of confirmations (depending on the level of risk you wish to accept and the resources you estimate the sender has).
For amounts you are prepared to risk losing, you are of course free to accept payments with zero confirmations. My point is that the risk involved with accepting unconfirmed payments is much the same regardless of whether a mining pool has stated that they will include a transaction.
As Peter Michael Lacey-Bordeaux points out in the comments to Scott's answer, there is nothing to stop a mining pool changing which transactions it includes at any time. The calculation of which transactions to include is short, whereas the search for a valid block hash is long. Given that no hash has yet been found, there is no disadvantage in abandoning a given block of transactions in favour of a slightly different block which includes some higher fees. This means the sender can attempt a double spend without any mining resources at all. This is no threat to people who wait for a few confirmations, but should be considered by people who wish to accept unconfirmed transactions.
The expected time until a valid hash is found (by someone, somewhere) is approximately 10 minutes (depending on how recently the difficulty has been updated). If 7 minutes have already elapsed, the expected remaining time is not 3 minutes. It is still 10 minutes, because the process is an exponential distribution which makes it memoryless. So starting afresh with a new block of transactions doesn't have any effect on the expected time to find a valid hash, but it may increase the total fees. There is therefore an incentive for a miner to keep restarting the search with a more up to date transaction block, and the same incentive will apply to any pool equipped to do so.
In summary, even if mining pools did announce transactions to be included, I would definitely not rely on that information.
All mining pools are currently publishing the block of transactions they are currently working on, but it's likely encoded into a smaller block header. As a miner, you are asking the pool for a small amount of work that you can accomplish and share your results. As far as I know, there are no mining pools that publish which transactions they are working on.
That said, I hope mining pools start doing this. If some mining pool admin or miner knows of one, please prove me wrong.
Then if you could summarize what all the pools are working on currently, and if a majority of the network is working on the same block of transactions than it is likely that 1 confirmation will occur on that block. Basically a look ahead to see what might be confirmed. This only reduces the risk by 1 confirmation and even so, that is not fool proof since someone outside of the major pools could confirm an alternative block of transactions.
It is still recommended you wait for a few confirmations before accepting a transaction.
In the absence of a mining pool that publishes a list of transactions pending inclusion, a good estimate of that list can be obtained using freely available mining software. If you run the bitcoind or Bitcoin-Qt client it will compose a list of valid transactions with sufficient fee and then try to find a valid hash. Finding a valid hash is no longer realistic due to the high difficulty, but finding a list of valid transactions can be done on any average computer with an internet connection.
In order to produce the same list of transactions that the mining pool produces, you will need to use the same settings, so that you exclude low fee transactions at the same cut off point as the pool. For a mining pool that uses the default fee requirements this requires no action. I don't see any reason that a mining pool would not be open about its fee requirements, but even if they are not published you can simply look up which blocks that pool has produced recently and estimate from that.
Modifying the bitcoin client to output the pending transaction list without trying to find a hash for it should be straightforward as it involves no additional work - simply cancelling part of the work. If you don't wish to make the changes yourself you could post a bounty in a bitcoin forum asking for such software. The small amount of work required should bring a response with very little bounty.
This provides a method of obtaining a good estimate of which transactions will make it into the next block (forming separate estimates for different pools if necessary), but I do not believe it will protect you from a deliberate attacker, which is why I posted my warning answer. I'm not currently aware of a way of protecting against an attacker other than waiting for confirmations.
