1
It seems like it would be useful to avoid replay attacks if your wallet could specify that a transaction must be confirmed before say the (current+100)th block before broadcasting it
I guess there could be a problem with this scheme if the tx was no longer able to be included into a block after a reorg (esp for dependent txs)
2
No, there isn't a way to make a transaction that has to be included before a certain block number.
And there's a good reason for this: such a transaction would not be what is known as reorg-safe. Generally, transactions should be able to be included in either side of a block chain fork. If you make a transaction that can only be included before a certain block number, and then a fork occurs that makes a chain that doesn't include it before the designated block number, then that transaction gets reversed and so do all transactions that depend on the base transaction.
I don't know of any way to accomplish that. Can you be more specific as to what kind of "replay attack" you are worried about? – Nate Eldredge – 2016-03-04T02:42:01.637
here is an example http://qntra.net/2016/03/a-miner-problem/
– djp – 2016-03-04T06:33:20.527This is not an attack. This is total misunderstaning how the Bitcoin network works. – amaclin – 2016-03-04T06:41:39.207
In a scenario of permanent backlog of transactions this scenario will need better strategies however – djp – 2016-03-06T22:05:16.963