Topic: OP_TIMESTAMP in script (Read 2356 times)

The sender could leave the transaction open until confirming that the recipient is OK, and then replace it with a closed transaction. Or the recipient could send BTC to some trusted person and then cancel it with a transaction to self (a dead man's switch).

It can't protect against double-spending.

I must admit that I don't know anything significant about nLockTime. I will make a point of learning when it gets implemented or enabled.
In my advocacy for OP_BLOCKNUMBER I wanted to enable the recovery of bitcoins for which the private key had been lost. Suppose for example that you've sent payment to a merchant and their hard disk dies and renders their wallet unreadable. If you had engineered your transaction using OP_BLOCKNUMBER such that, if the payment is not spent within a month then the coins revert back then you have only lost the coins for one month. 

Can this be done with nLockTime while remaining secure for sender and recipient?

ByteCoin

Sorry, didn't think that one all the way through, you are right.  I take back my comment.

Most/all of that stuff can be done with nLockTime.

So, my comment about scripts having to be stateless was not really from me but rather paraphrased from a conversation I had with Satoshi a week or so ago, on this very topic.


He is right. It's not just about making block chain splits more common. It's about the fundamental security of the system. If there is an OP_TIMESTAMP then I can write a script that becomes invalid after a day, broadcast it, then do a spend I want to reverse after it becomes incorporated into a block. I then work on blocks that build on the block before the one with the OP_TIMESTAMP script that contain a double spend of my transaction, so when it becomes invalid I can present a new chain on which everyone will build, thus reclaiming my coins.

nLockTime does not have this problem.

It's true that you get occasional orphan blocks (not "all the time") but transactions in the orphan block chain are mostly just incorporated into the same block number on the longer chain.  

For the purposes of discussion, I suggest that we define a blockchain reorg as one in which previously confirmed transactions become unconfirmed. This requires a longer blockchain to have replaced the current blockchain at a depth of several blocks. This has never happened (unless forced by a software change in response to a bug) nor is it likely to happen. If it did happen, as I mention in the other thread, bitcoin already has potentially bigger problems with normal transactions.

The situation which Satoshi outlines, in which OP_BLOCKNUMBER transaction causes problems is very unlikely. You have to have an OP_BLOCKNUMBER transaction which is very close to expiry and a block chain reorg which occurs in the vicinity of that critical period.

To completely avoid this unlikely circumstance you should be careful to spend the coins some time before expiry.

I don't understand how this could be possible. Please explain.

The reason why OP_BLOCKNUMBER is superior to OP_TIMESTAMP is that bitcoin functions without all the clients agreeing about exact times and engineering agreement seems hard. OP_BLOCKNUMBER is a proxy for time that everyone can agree on.


ByteCoin

I agree that there are too many problems, though I disagree that there isn't much benifit.  There are many situation where it might be useful to have a time in scripts.  Escrow, to begin with, becomes doable in bitcoin, not to mention many other really cool features. 

Satoshi knows more about Bitcoin than anyone else, so his opinion carries a lot of weight. In any case, I'm convinced that he is correct here. Allowing transactions to become invalid greatly increases the risk that random transactions with 6+ confirmations will become invalid, without much benefit.

No, scripts have to be stateless. If there was a way to get the time I could make a transaction that stops being valid after a certain time and thus forks the chain. I could use that to reverse transactions at will.

Yes, but the time changes if the transaction has to be moved to a newer block after a reorg.

How does this apply to OP_TIMESTAMP? The time is always the same on all systems.

Yes but he brings up a valid point (which you don't really answer in your responses).  Even if its not the work of an attacker, blockchain reorgs happen all the time.  As satoshi points out, if you wait until the last second to spend the coins, you could very well be locked out because of a reorg (whether its by one block or by many).  The same applies to a OP_TIMESTAMP except even worse. 

I explain in the thread why I think Satoshi's objection to OP_BLOCKNUMBER is unjustified. Of all the features
that  make Bitcoin a promising system, I think the scripting is the most powerful and OP_BLOCKNUMBER would facilitate many types of transactions which users would find very useful.

Although we're grateful to Satoshi for creating Bitcoin, should the fact that Satoshi has "rejected" an idea be sufficient grounds for not implementing it?

ByteCoin

That's been rejected by Satoshi:
https://bitcointalksearch.org/topic/m.22119

Could be very useful in some situations.  Has to be 64-bit, but I think its a cool idea.  Though all the other scripting stuff still needs dealt with.

Wouldn't it be cool to have OP_TIMESTAMP in script to get the current time in POSIX (or something else that lasts beyond 2038).