Can nTimeLock and multisig be used to create a 2 of 3 transaction where one of the sigs can't be used before block N?

This could be used to create a wallet payment service: 1 key held by wallet service, 1 key held by user, 1 key that can be used in 1000 blocks printed out and held by user for insurance in case wallet service disappears
But before this time is up the wallet payment service can be sure this account cannot be double spent, so its can be used to pay instantly for things like ATM withdrawal based on the reputation of the wallet payment service.

All wallets get kept on a server at your home that handles keys & generates transactions and communicates with your online server, ssh connection between home server and online server. The only bandwidth used is online server sending requests for new addresses for deposits and withdrawal requests, and home server sending back addresses and signed transactions for online server to publish (or denial of request). An average home connection should be able to handle this even for a massive amount of transactions, lets say you have a very low 100kb/s total bandwidth and each transaction is 1KB total both ways you could still handle 750 withdrawals a minute at peak without queuing.

Along with other checks, home server could also keep its own ledger of customer accounts to detect if online server gets compromised and fraudulent withdrawal requests are being sent. The only downside is possible extended downtime (just delayed withdrawals, site would still be operational) if your power/connection goes out, but I'm sure you would still be at like 99.9%

A system such that if a miner can include multiple transactions from the same address, with the same previous_output, that would overdraw the address, the entire balance of the address is set to zero and the coins are passed back out. Maybe something like 5% to the miner who finds it, then 1% to the next 95 blocks (make it less likely for coins to passed back to attacker).

For a transaction that is already in the block chain when an overdrawing transaction shows up, if it is less than n blocks old reverse the transaction, zero the address, pass back out. Merchants wait n blocks before confirmation. If n was 3 it would force an attacker to have a fork that is at least 3 high before the transactions are made public to have a profitable double spend, and anything less will result in the loss of coins.

Is there a way to make a transaction that has to occur in the next block or it becomes invalid? Would you need a new transaction script opcode that gives the previous block hash so you can compare it?

My idea is once this is available clients can keep their own list of trusted addresses and if they see a transaction sent from these addresses in a block they can use it to weight the blockheight count of different forks so they can pick a shorter more trusted branch over a longer untrusted branch, reducing a chance of a 51% attack. If certain transactions can be locked directly behind a specific block it keeps the attacker from including these transactions in their fork and using that transaction's trust.

Then trusted members of the community can make these transactions every few blocks and users can subscribe to them by adding their address to their trust list. You can have the weighting grow large depending how far back the last trusted transaction occurred starting with, for example (n is current block height):

1 block back = normal weight
2 blocks back = 2x weight, so now a new fork would require a chain of height  >n+1 to orphan this block
3 blocks back = 3x weight, fork requires height >n+2 to orphan this block

As long as the weights are not too high it still makes it possible for the client to eventually get back onto the full network in the case of a legitimate fork, but makes it impossible for an attacker to grow a large chain in private. Also by not worry about the weighting until there is a risk of orphaning more than one block, the client only begins using extra resources to check for trusted transactions in rare occasions.

Currently is there a way to force a transaction to occur only after a specific block, so if it is not included in the very next block it becomes invalid? Or will this require a new opcode in the transaction script that gives the hash of the previous block?