Using nLockTime, you can mark a #Bitcoin transaction as invalid before some block height.

Is there yet a feature that does the reverse? That is, mark a transaction as invalid to include in any block AFTER a particular block height? #asknostr

Reply to this note

Please Login to reply.

Discussion

To my knowledge, covenants would enable confirmed transactions to include “can’t spend” conditions on outputs (such as block height), but thats not quite what I’m after.

I want to sign a transaction sends to regular addresses, but includes a stipulation that the whole TX is only valid if included before some height.

I don't think this exists. The issue I am thinking is that even if you send a transaction today, it might get confirmed next week... Heck it might get confirmed in a couple of months.

I've not thought too hard about this, but that might be the reason why it isn't possible.

Agreed that the time-to-confirm is unbounded. Nevertheless, I believe it’s within the realm of possibility for there to be such a feature. I’m fairly certain such a feature does not yet exist (and I’m aware of no proposals).

The only thing that comes to mind is that you can make a bitcoin address with two spending paths, one of them is a "happy path" allowing the money to be spent the way you want, the other is an "unhappy path" that is only valid after the timelock expires. E.g. the "unhappy path" might let everyone involved have their money back. Or it might let anyone spend the money, which pretty much ensures it will all end up being sent to miners as fees.

The timelock on the "unhappy path" effectively puts a time *limit* on the "happy path." Either do as you're expected to do before the time runs out, or the unhappy path gets triggered and, well, you won't be happy.

That’s an interesting idea. I’ll think about it.