@Elwar @CIYAM
I found nLockTime interesting but it has some issues. As far as I understand a tx with nLockTime may be lost (it's stored in mempool and not included in the blockchain) if mempools of nodes, my client broadcasted to, were wiped. So such method can't be used for long-term savings (I want to keep myself from spending some BTC for a long time).
While I haven't done any investigation, I am assuming that it is possible to export a signed raw transaction with the nLockTime setting encoded in it. I am also assuming that the signature covers nLockTime so that it cannot be manipulated. Otherwise, this wouldn't make sense:
It still has some value in that the tx could be manually sent to another person (thus acting like a last will) provided that they eventually broadcast in order to make sure the transfer actually happens.
Specifically because of this:
You are probably referring to nLockTime and yes the issue is that nLockTime txs whose time (or block) is in the future are not accepted by peers (so your client would have to re-broadcast the tx after that point in time).
In other words, assuming I'm right, once you generate and export a signed nLockTime transaction, it can be distributed to multiple parties, any one of whom can execute it after the time has expired. However, in the meantime, the funds would not really be locked. That is to say that if you wanted to cancel the scheduled transaction, you would only need to make a new transaction right now to move coins from the input that is scheduled to be used, however, it also means that if your private keys were hacked/stolen, the funds could still be stolen (ETA: immediately).
ETA: I know this still isn't what you want, but it isn't what you want because you want to lock yourself out, while you indicated it wasn't what you wanted because the transaction could be lost (presumably by the software closing).
