Here is the idea (vision):

On my address 1AbCdEfGhjKLmNpQrStUvW (or probably another address, not starting with "1", but anyway…), I have 1 bitcoin (or whatever). It is time locked until 17 Apr 2022, as everybody can readily see from the blockchain.

Some thief tries to steal my Bitcoin ($5 wrench attack). I say "I cannot send you the bitcoin, even if I wanted to! It is cryptographically time locked till 17 Apr 2022". The thief looks at the blockchain and sees that I am right. So he says "ok, then you give me the private key". So I give him the private key.

Now, fortunately, one day later or so, after the thief has left, I can unlock the bitcoin sitting in "1AbCdEfGhjKLmNpQrStUvW" already TODAY (year 2018), because(!) the transaction that sent the 1 bitcoin to "1AbCdEfGhjKLmNpQrStUvW" was a script specifying TWO conditions, only ONE of which needs to be fulfilled to spend the coin! Condition 1 is the default condition which is:

• I must have the secret key of "1AbCdEfGhjKLmNpQrStUvW" AND the date must be 17 Apr 2022 or later

Condition 2 is:

• I must own the secret key of "qwertyuiopasdfghj"! Here, no time lock applies.

The thing is, that acc. to this yet-to-be-defined BIP, this second condition is always present in this kind of "BIP y.t.b.d." transaction, also if it is not actively used! This is why it is plausible deniable! If the $5 wrench attacker asks me to give him the secret key of "qwertyuiopasdfghj", I can plausibly say "this does not exist. There only exists a secret key for "1AbCdEfGhjKLmNpQrStUvW". The point is that the person who sent me (i.e. to "1AbCdEfGhjKLmNpQrStUvW") the 1 bitcoin specified the lock time, but that person not necessarily specified the "early realease" hash of the private key (here "qwertyuiopasdfghj"), as this is just OPTIONAL by the protocol. If the sender does not specify that second "early release" hash, a random hash will be generated by the protocol as disguise, a hash for which no secret key exists at all.

So the attacker (or blockchain analyst) has no way to tell if that second condition (the "qwertyuiopasdfghj" hash) was set on purpose by the sender of that 1 bitcoin, or if it was set automatically as the standard default way.

So with this feature (BIP), we'd have a plausible deniable theft protection mechanism against the $5 wrench attack.

Another way of putting it: We need a multisig "1 of 2" script, for which ONE of the 2 is time-locked, the other is not.

Or is this possible already with today's protocol? If yes, we have the feature already, and I'd like to request to develop wallets that make use of this as GUI feature "send to yourself with time lock and plausible deniability of early spending".