At some point, the local Geth node reported tx 2e7a57c55a7cb28d0e233d7745210dba93c09f14c5df4e879db1a530a79a842a in the block 1369316 on testnet. It then disappeared from the chain at some point during the next 1-12 blocks.

The local geth node shows the transaction data relative to its current copy of the block chain; even if the transaction with the respective hash is present in the copy it does not mean that it has been confirmed by the network (it must first be relayed and mined. Only then is it added to the block chain).

That same tx reappeared after 90 blocks on the block 1369406 and now is part of the blockchain.

A transaction cannot "(re)appear" in a sense that only a single transaction may exist in the block chain with a transaction hash in order for the block chain to be valid.

If it "disappeared" then one of the following scenarios is likely:

• the transaction was "intentionally" tampered with by one or more nodes (through bit manipulation) and relayed to the network. The rest of the network marked it as invalid and thus not added to the block chain (by block chain I mean the entire block chain the network agrees on)
• the transaction still existed in the block chain copies of nodes that have validated and synced with nodes that earlier marked it as invalid (luckily, current implementations of Ethereum penalize nodes relaying invalid transactions (and not the node that made the transaction))
• a 51% attack was made (though unlikely because of the cost and no monetary gain on the test net) and the attacker tampered with transaction ordering.
• Ethereum uses the GHOST protocol to incentivize mining for block chains (whose blocks are called uncles of the main, valid chain) that have invalid data but valid headers up to a certain height (the fees for mining uncle blocks is reduced exponentially per block). Your transaction may have landed in such a block and resynchronized later with the main block (since it was valid both header and data-wise)

We were in the understanding that waiting for 12 blocks would be sufficient.

You cannot really use an absolute value (of 12) blocks. The "sufficient" number of confirmations is dependent on the mining nodes and their advertised blocks. It is safe to say that the higher the number of confirmations the better (more nodes "have agreed" on the block chain).

Is this caused by a fork or a replay attack? If yes, how should this be handled?

It's highly unlikely to be caused by a fork as all miners would have to agree on mining on a new block chain starting from a given block.

Well, following the principle of the block chain that anybody can join and contribute with any mining power it cannot be mitigated (by the current implementations of Ethereum). A solution would be to use permissioned block chains (i.e. eris) that allow for ACLs on peers joining the network.

At some point, the local Geth node reported tx 2e7a57c55a7cb28d0e233d7745210dba93c09f14c5df4e879db1a530a79a842a in the block 1369316 on testnet. It then disappeared from the chain at some point during the next 1-12 blocks.

The local geth node shows the transaction data relative to its current copy of the block chain; even if the transaction with the respective hash is present in the copy it does not mean that it has been confirmed by the network (it must first be relayed and mined. Only then is it added to the block chain).

That same tx reappeared after 90 blocks on the block 1369406 and now is part of the blockchain.

A transaction cannot "(re)appear" in a sense that only a single transaction may exist in the block chain with a transaction hash in order for the block chain to be valid.

If it "disappeared" then one of the following scenarios is likely:

• the transaction was "intentionally" tampered with by one or more nodes (through bit manipulation) and relayed to the network. The rest of the network marked it as invalid and thus not added to the block chain (by block chain I mean the entire block chain the network agrees on)
• the transaction still existed in the block chain copies of nodes that have validated and synced with nodes that earlier marked it as invalid (luckily, current implementations of Ethereum penalize nodes relaying invalid transactions (and not the node that made the transaction))
• a 51% attack was made (though unlikely because of the cost and no monetary gain on the test net) and the attacker tampered with transaction ordering.
• Ethereum uses the GHOST protocol to incentivize mining for block chains (whose blocks are called uncles of the main, valid chain) that have invalid data but valid headers up to a certain height (the fees for mining uncle blocks is reduced exponentially per block). Your transaction may have landed in such a block and resynchronized later with the main block (since it was valid both header and data-wise)

We were in the understanding that waiting for 12 blocks would be sufficient.

You cannot really use an absolute value (of 12) blocks. The "sufficient" number of confirmations is dependent on the mining nodes and their advertised blocks. It is safe to say that the higher the number of confirmations the better (more nodes "have agreed" on the block chain).

Is this caused by a fork or a replay attack? If yes, how should this be handled?

It's highly unlikely to be caused by a fork as all miners would have to agree on mining on a new block chain starting from a given block.

Well, following the principle of the block chain that anybody can join and contribute with any mining power it cannot be mitigated (by the current implementations of Ethereum). A solution would be to use permissioned block chains (i.e. eris) that allow for ACLs on peers joining the network.