I agree this is a great idea. People can always spam the network with invalid transactions with or without this, but they shouldn't be propagated, and the sender should be disconnected when this happens.
I don't think we need "valid_from" for this, just transaction expiration. After funding the multisig, the parties just need to keep updating signed settling transactions shared between them. If the previous settling transaction is about to expire and you don't have a new one yet, broadcast the last one.
Micropayment channels like this are also perfect for mesh networking.
The client will fund a multisig balance, so if the server disappears that money will stay in limbo.
To prevent this the server needs to sign a transaction that sends 100% of the funds back to the client.
Suppose that the valid_from field is not in the transaction.
Then the client will always have a signed transaction from the server that refunds 100% to him.
If i were the client, i will use the service sending signed transactions when the server requires me and after some time i will broadcast the first transaction letting the server with 0 and me with 100%.
This behavior is the one that is prevented by the "valid_from" field.
How will you handle this case without "valid_from"?
With transaction expiration. Ideally, both parties should first sign a transaction distributing the funds back to the client expiring in say a minute, then with that in hand, the client funds the multisig. After 30 seconds (and every minute thereafter), the settling transaction is updated. If one party fails to update, the other settles by broadcasting the last settling transaction before it expires.
The update frequency can increase and decrease depending on value of payments and trust between parties. The initial settling transaction could also include a connect fee to the server to prevent theft of the first 30 seconds service.