No, there is no way to get the block number in a script. People keep asking for it, but it wasn't left out by accident, it is missing for a reason. (Please think about how the network handles block reorgs for a while before you ask...)
Pardon my ignorance, but all I know about reorgs is that the block that loses the race gets ignored. Its transactions are not valid anymore and must be included in another block.
Why does that makes it impossible to get the block number, or other block header data, in a script? I mean, I understand it might be complicated and perhaps not worthwhile doing. But it's not impossible, is it?
We put a lot of effort into avoiding the possibility of invalidating a chain of transactions. Newly mined coins aren't valid until 100 blocks have passed (120 in practice, but the hard requirement is only 100). If not for that requirement, a miner could create some coins, spend them, the recipient could spend them, etc, and then a shallow reorg would invalidate the coinbase, and break the whole chain. People
should wait for sufficient confirmations to avoid the problem, but they don't, so the network makes it impossible.
Now, what happens when scripts can be either valid or invalid depending on which block they are in? The same whole mess that we were trying to avoid. The invalidated transactions
might not be valid for inclusion in the next block, and the transactions that spent them are also possibly invalid.
And yes, I know that we could maybe come up with yet another special case in the script system so that the block height can only be checked with a greater than operation, but ugh. Also, you end up with a race if the reorg goes back to before the script would have become valid, which might only be two or three blocks, which happen on a regular basis already when there is no practical way to profit from them.
You create a transaction that will not be valid for a month (whatever) and broadcast it. Then an attacker gets in and steals the private key for that address. They can create a new transaction that sends the money to their own address. Honest nodes will consider that a double spend and refuse to relay it.
No... honest nodes should consider the legit owner is cancelling the transaction.
nLockTime shouldn't be used to protect against private key loss. Since you'll have to secure the target key of the transaction anyway, why don't you secure the current key the same way?
I might be remembering it wrong, it's been a while since I looked into nLockTime. Either way, we both come to the same conclusion: timelocking can't work.
