I was pondering about a thing the other day. Wouldn't it be possible to implement a rebate/coupon system for merchants? Actually, it could be made very useful by just adding a single instruction to set of existing instructions in the Bitcoin scripting language.
Suppose a merchant wants to issue targeted rebate coupons (essentially free money), but they should only be allowed to be used for purchasing items in the merchants store. You'll get quite close by allowing multiple signatures, i.e. the transaction is considered valid if the merchant and the (targeted) customer signatures are both valid. In some sense, the merchant is issuing money a targeted customer, which the customer only can spend it if the merchant itself signs it as well.
However, there's just one more thing you would like to do. You want that offer to be limited in time.
Now, unfortunately, there's no Bitcoin scripting instruction that captures the current time (say as a 32-bit word representing UTC). If that would have existed it would be relatively straight forward to create a coupon transaction, let's say:
OP_PUSHDATA4
OP_NOW <-- this instruction currently does not exist
OP_LESSTHAN
OP_IF
OP_2
OP_CHECKMULTISIGVERIFY
OP_ELSE
OP_RETURN
OP_ENDIF
Now, there would be two signatures required to spend this; the targeted customer and the merchant itself.
This would basically mean that the targeted customer can only spend it at the merchants store (as it requires the signature from the merchant itself).
However, the time constraint tells when this transaction is valid. If no transaction has taken place and the time expires, then the transaction, although still in blockchain, would never become spendable. Therefore, the merchant can reissue new coupons to new customers without loosing money on those that never got redeemed.
Anyway, I would say that this coupon idea would still be possible without adding the "OP_NOW" instruction, because you could design an instruction sequence with a majority rule, which means that 2 of 3 signatures would suffice to invalidate the transaction, and then the targeted customer only have one signature. If the merchant + customer keys are used to sign, then the coupon is used, if two merchant keys are signed, then the coupon is withdrawn. Then after expiration date is reached, the merchant can just issue "coupon cancel requests" to the blockchain. But this would create more work, and is also more complicated (which requires a server that constantly withdraws certain coupons at specific dates).
Just adding OP_NOW would seem simpler to me.
This is just a thought, what do you think?