First, it is unlikely that SHA-256 will be seriously broken in the next year or decade. In several decades computer power may increase so far that 128 bit security offered by SHA-256 and secp256k no longer feels secure, though. Also Bitcoin uses double sha-256 which means that even if sha-256 is partly broken it cannot be easily applied to Bitcoin.
Basically a hash can be broken in two ways:
- preimage attack: find a new clear text message for some fixed hash
- collision attack: find two clear texts messages that have the same hash.
The second attack is much simpler. The first would take 2^256 steps with brute-force, the second "only" 2^128 steps.
1) Attacker may be able to defeat OP_CHECKSIG, which hashes transactions before signing. I can't understand what means "defeat OP_CHECKSIG".
Suppose there is a collision attack. An evil attacker may trick you into signing your part of a harmless looking multi-sig transaction that returns most of the money back to your own address but the same signature can then be used for another transaction that sends the money to the attacker.
I try to figure out what kind of attack would be related to this: user A sends transaction T to user B. User C intercepts T1 before spreading to the network and if we could crack che second preimage resistance of sha we could find another tx T2 that has the same hash of T1 (this preserve the integrity of the sign for T2).
possible but unlikely. You have to be fast, since after a few seconds the transaction has propagated through the network and your fake transaction is a double spent. Also it requires a preimage attack.
In particular if he could find a transaction T2 that is different from T1 only for the destination address (address X instead B address) (and T1 and T2 have the same hash) he could modify the destination address and so send T2 to the network (and delete T1). With this operation A's bitcoin will be delivered to some "x" address instead of B. The problem of the attacker is now to obtain a private key of that address x to try to spend it (ECDSA probem)
In a preimage or collision attacks you usually can fix most parts of the transactions and only change an unimportant part (e.g. using an OP_RETURN output, or an output with small value, where you choose a random public key).
2) Attacker may be able to create blocks very quickly. I think this is related to the first preimage resistance: if I could break this properties of sha I could fix a hash value less than the target and I could obtain the header of the block that generates this hash. Even I could be able to do this I will also have a problem. What I obtain from this "reverse" operation has to have a reasonable meaning in bitcoin protocol, I mean that the bit string of a valid header has a structure and I can't use some random bit as an header block because it depends on what transaction the block contains.
There are some random bits: the nonce (and you can misuse some bits of the time-stamp). What you need is a preimage attack that tells you if there is a valid nonce faster than trying all 2^32 possible values for the nonce. You may also try to preimage a merkle-tree hash that would produce a valid block-header hash and then preimage the merkle-tree hash a few times and in the end find a valid coinbase transaction. However, this sounds much harder.
3? double spend?) ...
I don't think what you described is what happens. I think there were transactions with the same hash (if the coinbase doesn't contain a unique identifier it happens automatically; now all coinbases contain the block depth for that reason). The Bitcoin full node should not get confused by transactions with the same hash. Worst case is that some transactions cannot be spent.
Of course, if you can drive attack 2) you easily have 51% and can rewrite history to double-spend your own transactions after they were confirmed.