Can I cancel an offline transaction with this approach? (opposite of nLocktime)

Question

I would like to cancel a transaction I sent offline, and am looking for ways to prevent it from being accepted by the network.

Will the Bitcoin client prohibit the entire Tx if there is even on input that is already spent?

If the answer to that question is "yes", then what if I created "control addresses as follows:

1. Generate 10,000 addresses and send each 0.0001 BTC
2. After N confirmations pass, create an offline transaction
3. Consume one of the balances in step 1 above in the offline Tx

I suspect either one of the two scenarios will occur:

1. User broadcasts offline Tx, and completes the Tx
2. I spend the balance of the "control address", and when the user tries to spend the offline tx, they are denied because one of the inputs it refers to has already been spent.
3. ???

Question

• Is this a correct approach to canceling offline transactions?

• What optimizations can be made? I dislike having the overhead of having to sign each control input with a new private key each time.

Answer 1

The approach is correct. You don't have to use different private keys, you can use the same private key and same address for each of the control outputs.