5
1
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?
3
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.
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 – 2014-03-14T18:10:33.020
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 – 2014-03-14T18:30:46.030
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.
3Miners 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 – 2014-03-10T19:42:53.427
You are right Meni. I should revise my answer. – Scott – 2014-03-11T00:37:30.853
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 – 2014-03-11T03:19:38.023
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 – 2014-03-11T04:23:29.190
1On 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 – 2014-03-11T04:26:48.420
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. I'm not currently aware of a way of protecting against an attacker other than waiting for confirmations.
1This would not help protect against a Finley attack, which is generally seen as the most credible double spend threat. – Nate Eldredge – 2014-03-11T04:33:13.963
@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 – 2014-03-13T15:37:13.207
1I don't see how. Could you explain? – Nate Eldredge – 2014-03-13T15:40:34.310
@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. 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 – 2014-03-13T16:13:13.8701@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 – 2014-03-13T16:21:35.887
@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 – 2014-03-13T16:26:05.063
Incidentally, I apologize to Hal Finney for misspelling his name, but I can no longer edit. – Nate Eldredge – 2014-03-13T16:28:40.413
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 – 2014-03-13T17:29:51.493