It is only meaningful to get a list of the transactions in the mempool of each mining pool, after all the blocks they produce contain the transactions you are concerned with and these are published as part of the protocol.
If you could get a list of mempool transactions for each mining pool, you could build a lookup table for each unconfirmed transaction which contains the percentage of hashing power which is aware of each transaction.
edit: but this is no guarantee, the best you can hope for is a 'probability of block inclusion' indicator.
Topic: Open list of transaction as mitigation 0-conf tx problem (Read 1067 times)
And last one bump. 
Any thoughts?
A 'Gentlemen Statement' or agreement is against the nature of what Block chain technology is supposed to achieve.
You know, when pools reach 50% of the network hashrate miners leave them and switch to another one. The same behaviour is expected here.
In general, (as far as im aware) 0-Conf Tx's should only be used for micro or small transactions, ideally in cases like merchant point of sale. With smaller transactions amounts, the level of value-risk is low enough to be mitigated if a double spend were to occur (Losing 25$ isn't the biggest deal to a merchant, and surely a double spend will happen less often than charge backs!). Of course, one could exploit multiple small transactions at once and commit a series of double spends in one block to try to gain the largest amount possible before the attack is noticed. Though it should be assumed anyone offering services orientated around or involving features utilizing 0conf tx's in any significant want would also monitor the network for abnormal activity of this sort.
As you said above there already are pools which choose more profitable txs if they have double-spends. If such pools get big share of the network double-spend attacks will be very cheap, you needn't to have anything for it:1) Create tx with standard fee
2) Service accepts it
3) Create double spend tx with double fee(its still very small)
4) If M% of network hashrate belong to pools which substitute doublespend txs you get M% chance to successfully attack service
5) If you didn't success in attack you didn't lose anything.
What if a dishonest pool is cooperating with the thief?
What if a pool IS the thief?
With any normal transaction that has been relayed throughout the network and includes a reasonable transaction fee, it is already safe to assume that any honest pool will eventually confirm it (as long as a dishonest pool doesn't confirm a competing transaction first). Therefore, it is generally safe in many situations to accept 0-confirmation transactions for small values.
With larger transactions (or high transaction volumes) you can significantly reduce your risk by waiting for a single confirmation.
What if a pool IS the thief?
With any normal transaction that has been relayed throughout the network and includes a reasonable transaction fee, it is already safe to assume that any honest pool will eventually confirm it (as long as a dishonest pool doesn't confirm a competing transaction first). Therefore, it is generally safe in many situations to accept 0-confirmation transactions for small values.
With larger transactions (or high transaction volumes) you can significantly reduce your risk by waiting for a single confirmation.
I wrote plan above to get profit from all 0-conf services if there are honest but "greedy" pools in the network. So attacker needn't dishonest pool at all to make attack.
If pool will provide unfair information about txs in the block he could be easily caught. I think that reputation loss is much higher then profit.
But as I understand currently pools don't reconstruct blocks when get double-spend tx. Is it true?
Probably if some pools release gentleman's statement not to accept double-spend txs they will get more attention from miners?(yes, i understand that its less profitable, but from other hand all profit which could be gained by including double-spend transactions is much less then loss from double-spends)
Probably if some pools release gentleman's statement not to accept double-spend txs they will get more attention from miners?(yes, i understand that its less profitable, but from other hand all profit which could be gained by including double-spend transactions is much less then loss from double-spends)
As far as I am aware (and I say that, because I say the following without 100% certainty):
Standard software will not accept the double spend, and do not support replacements in that manner(other than using nLocktime), but not everyone is using standard software. There are for example, forks of the reference client that do support it (https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.0rc4). I do not know of any major pools running this patch, although I know some such as Eligius run Child-pays-for-Parent style patches that have some similar implications.
Peter Todd has also created a tool for replacing transactions running the above patch: https://github.com/petertodd/replace-by-fee-tools
It even has an example of performing a double spend utilizing this. As Peter notes in this, there are other additional methods to increase the likelihood of success in the attempted double spend. "In addition you can optionally specify that the first transaction additional OP-RETURN, multisig, and "blacklisted" address outputs. Some miners won't accept transactions with these output types; those miners will accept the second double-spend transaction, helping you achieve a succesful double-spend.", for example.
A 'Gentlemen Statement' or agreement is against the nature of what Block chain technology is supposed to achieve. Parties cannot be trusted and the overlaying design has to enforce that they are assumed to not be. Unless the amount to gain is very large anyway, typically pools have the financial incentive to uphold the network rules and sanity, rather than damage their reputation for one time small gain. Beyond that, nobody wants to be cheated, even if they would like to cheat; developers, industry vendors, pool operators all have incentive to consider these things and work together to ensure the network and protocol operate with the safest approach.
In general, (as far as im aware) 0-Conf Tx's should only be used for micro or small transactions, ideally in cases like merchant point of sale. With smaller transactions amounts, the level of value-risk is low enough to be mitigated if a double spend were to occur (Losing 25$ isn't the biggest deal to a merchant, and surely a double spend will happen less often than charge backs!). Of course, one could exploit multiple small transactions at once and commit a series of double spends in one block to try to gain the largest amount possible before the attack is noticed. Though it should be assumed anyone offering services orientated around or involving features utilizing 0conf tx's in any significant want would also monitor the network for abnormal activity of this sort.
The exception would be replacing transactions via submitting the TX utilizing nLocktime. As far as im aware, If a tx has a future nLocktime it will not propagate to other nodes or be included in a block until that time is reached, so an attacker would have to manually submit it to enough large nodes that 0conf tools would detect it as reasonably confirmed, service confirm it or whatever the case, then them send an updated req to the nodes spending the money with no or a sooner nLocktime. This would be prevented (and likely already is) by services utilizing 0conf ignoring tx's with a future nLocktime.
Lets assume that majority of pools will have API which allow one to get list of all transactions which included in currently mined block every second. In this case any service for merchants could check how which part of network mined 0-conf transaction which should be confirmed. It allows for services rate txs and most of them could be securely accepted in a few seconds.
The only problem which i could see is that:
1) Attacker send txA
2) Its got accepted by majority of the pools
3) Service confirm txA
4) Attacker send txB which double spend coins from txA with higher fee
5) Pools reconstruct currently mined block to include more profitable txB
But as I understand currently pools don't reconstruct blocks when get double-spend tx. Is it true?
Probably if some pools release gentleman's statement not to accept double-spend txs they will get more attention from miners?(yes, i understand that its less profitable, but from other hand all profit which could be gained by including double-spend transactions is much less then loss from double-spends)
The only problem which i could see is that:
1) Attacker send txA
2) Its got accepted by majority of the pools
3) Service confirm txA
4) Attacker send txB which double spend coins from txA with higher fee
5) Pools reconstruct currently mined block to include more profitable txB
But as I understand currently pools don't reconstruct blocks when get double-spend tx. Is it true?
Probably if some pools release gentleman's statement not to accept double-spend txs they will get more attention from miners?(yes, i understand that its less profitable, but from other hand all profit which could be gained by including double-spend transactions is much less then loss from double-spends)
Jump to: