<p>All mining pools are currently publishing the block of transactions they are currently working on, <em>but</em> 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, <strong>there are no mining pools that publish which transactions</strong> they are working on.</p>

<p>That said, I hope mining pools start doing this.  If some mining pool admin or miner knows of one, please prove me wrong.</p>

<p>Then if you could <em>summarize</em> 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.</p>

<p>It is still recommended you wait for a few confirmations before accepting a transaction.</p>

CC BY-SA 3.0
2014-03-10T19:42:53.427Z
Miners in a normal pool don't get the block and don't know the transactions in it. They just get the much smaller block header (and possibly, Merkle branch of the generation transaction).
Meni Rosenfeld
CC BY-SA 3.0
2014-03-11T00:37:30.853Z
You are right Meni.  I should revise my answer.
Scott
CC BY-SA 3.0
2014-03-11T03:19:38.023Z
Thanks, Meni. I've always wondered why your hashrate when mining with a pool doesn't change depending on the number of transactions in the block.
Tony
CC BY-SA 3.0
2014-03-11T04:23:29.190Z
This is what I suspected and all I could personally come up with. Barring any answers with mining pools that have a published list of pending transactions I will award this question approved and the pending rep.
placeybordeaux
CC BY-SA 3.0
2014-03-11T04:26:48.420Z
On a sidenote your answer pre-suposes that the published list of the pools will not change if a higher fee double spend attempt occures.
placeybordeaux
CC BY-SA 3.0
2014-03-10T13:55:49.367Z
2014-03-11T00:51:24.703Z
2014-03-11T00:51:24.703Z
Scott
<p>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.</p>

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

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

<p>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 <a href="https://bitcoin.stackexchange.com/a/23471/14410">warning answer</a>. I'm not currently aware of a way of protecting against an attacker other than waiting for confirmations.</p>

CC BY-SA 3.0
2014-03-14T20:00:34.717Z
2014-03-14T20:00:34.717Z
2017-04-13T12:47:34.187Z
trichoplax is on Codidact now
<h1>Knowing won't help</h1>
<p>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).</p>
<p>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.</p>
<p>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.</p>
<h1>The sender can still attack</h1>
<p>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).</p>
<p>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.</p>
<h1>Miners are free to change their mind</h1>
<p>As <a href="https://bitcoin.stackexchange.com/users/2630/peter-micheal-lacey-bordeaux">Peter Michael Lacey-Bordeaux</a> points out in the comments to <a href="https://bitcoin.stackexchange.com/a/23322/14410">Scott</a>'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. <em>This means the sender can attempt a double spend without any mining resources at all</em>. This is no threat to people who wait for a few confirmations, but should be considered by people who wish to accept unconfirmed transactions.</p>
<p>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 <a href="http://en.wikipedia.org/wiki/Exponential_distribution" rel="nofollow noreferrer">exponential distribution</a> which makes it <a href="http://en.wikipedia.org/wiki/Memoryless" rel="nofollow noreferrer">memoryless</a>. 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.</p>
<p>In summary, even if mining pools did announce transactions to be included, I would definitely not rely on that information.</p>

CC BY-SA 3.0
2014-03-14T18:10:33.020Z
I am going to accept this answer, althought you and I are in disagreement with how much this knowledge could help. I think the help would be more than zero.
placeybordeaux
CC BY-SA 3.0
2014-03-14T18:30:46.030Z
Thanks @PeterMichealLacey-Bordeaux. Although I think I've demonstrated that some of the apparent ways it would help don't apply, there is always the possibility there are completely unrelated benefits that I can't see. I'd love to have demonstrable examples from anyone who comes up with any in future.
trichoplax is on Codidact now
CC BY-SA 3.0
2014-03-13T15:35:11.757Z
2014-03-13T16:22:04.733Z
2020-06-16T11:10:03.350Z
trichoplax is on Codidact now
<p>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.</p>

<p>Has there been any thought on this that I could read up on?</p>

CC BY-SA 3.0
2014-03-11T04:33:13.963Z
This would not help protect against a Finley attack, which is generally seen as the most credible double spend threat.
Nate Eldredge
CC BY-SA 3.0
2014-03-13T15:37:13.207Z
@NateEldredge No it does not, however with this information you can make a much more accurate estimation of the potential risk/reward of a finney attack.
placeybordeaux
CC BY-SA 3.0
2014-03-13T15:40:34.310Z
I don't see how. Could you explain?
Nate Eldredge
CC BY-SA 3.0
2014-03-13T16:13:13.870Z
@NateEldredge I suspect Peter is referring to assessing how many other merchants the sender has also sent to simultaneously (all with zero confirmations). This would allow you to calculate what amount the sender stands to gain on execution of a [Finney attack](http://bitcoin.stackexchange.com/a/4963/14410). If this is the case, I would disagree since such a sender could easily pay every merchant from a different bitcoin address, at no extra cost for the attack. This would make it impossible to guess how much the sender stands to gain.
trichoplax is on Codidact now
CC BY-SA 3.0
2014-03-13T16:21:35.887Z
@githubphagocyte: Furthermore, those transactions would already have appeared on the p2p network, so it's not clear that seeing them published by a pool gives you much additional information.
Nate Eldredge
CC BY-SA 3.0
2014-03-13T16:26:05.063Z
@NateEldredge I agree. If someone is diligent enough to check the whole transaction list for Finney attack incentives, then they are probably too diligent to rely on second hand information from a mining pool.
trichoplax is on Codidact now
CC BY-SA 3.0
2014-03-13T16:28:40.413Z
Incidentally, I apologize to Hal Finney for misspelling his name, but I can no longer edit.
Nate Eldredge
CC BY-SA 3.0
2014-03-13T17:29:51.493Z
It's not just that, but there is actually a higher chance that a finney attack can work in the case that their secretly mined block does not get accepted, but the first transaction to the merchant is not accepted by the competing block. I don't feel like doing the math here, but it is dependent on the amount of computation power the attacker has, so while this should be low it still factors into the cost benifit, ie attempting a finney attack on a transaction that isn't going to be included in the next block is safer.
placeybordeaux
<transactions><mining-pools><trust>
Are there any mining pools that publish what transactions they will include?
placeybordeaux
# Are there any mining pools that publish what transactions they will include?

(Asked by: username_0 on 2014-03-03)

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?

**Tags:** transactions, mining-pools, trust

> **Comments:**
> **username_1**: This would not help protect against a Finley attack, which is generally seen as the most credible double spend threat.  
> **username_0**: @username_1 No it does not, however with this information you can make a much more accurate estimation of the potential risk/reward of a finney attack.  
> **username_1**: I don't see how. Could you explain?  
> **username_2**: @username_1 I suspect Peter is referring to assessing how many other merchants the sender has also sent to simultaneously (all with zero confirmations). This would allow you to calculate what amount the sender stands to gain on execution of a [Finney attack](http://bitcoin.stackexchange.com/a/4963/14410). If this is the case, I would disagree since such a sender could easily pay every merchant from a different bitcoin address, at no extra cost for the attack. This would make it impossible to guess how much the sender stands to gain.  
> **username_1**: @githubphagocyte: Furthermore, those transactions would already have appeared on the p2p network, so it's not clear that seeing them published by a pool gives you much additional information.  
> **username_2**: @username_1 I agree. If someone is diligent enough to check the whole transaction list for Finney attack incentives, then they are probably too diligent to rely on second hand information from a mining pool.  
> **username_1**: Incidentally, I apologize to Hal Finney for misspelling his name, but I can no longer edit.  
> **username_0**: It's not just that, but there is actually a higher chance that a finney attack can work in the case that their secretly mined block does not get accepted, but the first transaction to the merchant is not accepted by the competing block. I don't feel like doing the math here, but it is dependent on the amount of computation power the attacker has, so while this should be low it still factors into the cost benifit, ie attempting a finney attack on a transaction that isn't going to be included in the next block is safer.  

---

## 3 answers

### Answer by username_2 on 2014-03-13. Score: 3 | Accepted answer

# Knowing won't help

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 sender can still attack

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.

# Miners are free to change their mind

As [Peter Michael Lacey-Bordeaux](https://bitcoin.stackexchange.com/users/2630/peter-micheal-lacey-bordeaux) points out in the comments to [username_3](https://bitcoin.stackexchange.com/a/23322/14410)'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](http://en.wikipedia.org/wiki/Exponential_distribution) which makes it [memoryless](http://en.wikipedia.org/wiki/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.

> **Comments:**
> **username_0**: I am going to accept this answer, althought you and I are in disagreement with how much this knowledge could help. I think the help would be more than zero.  
> **username_2**: Thanks @PeterMichealLacey-Bordeaux. Although I think I've demonstrated that some of the apparent ways it would help don't apply, there is always the possibility there are completely unrelated benefits that I can't see. I'd love to have demonstrable examples from anyone who comes up with any in future.  

---

### Answer by username_3 on 2014-03-10. Score: 2

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.

> **Comments:**
> **username_4**: Miners in a normal pool don't get the block and don't know the transactions in it. They just get the much smaller block header (and possibly, Merkle branch of the generation transaction).  
> **username_3**: You are right username_4.  I should revise my answer.  
> **username_5**: Thanks, username_4. I've always wondered why your hashrate when mining with a pool doesn't change depending on the number of transactions in the block.  
> **username_0**: This is what I suspected and all I could personally come up with. Barring any answers with mining pools that have a published list of pending transactions I will award this question approved and the pending rep.  
> **username_0**: On a sidenote your answer pre-suposes that the published list of the pools will not change if a higher fee double spend attempt occures.  

---

### Answer by username_2 on 2014-03-14. Score: 0

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](https://bitcoin.stackexchange.com/a/23471/14410). I'm not currently aware of a way of protecting against an attacker other than waiting for confirmations.


---

