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)
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.
