Bitcoin Forum
December 05, 2016, 02:46:21 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: OP_TIMESTAMP in script  (Read 2054 times)
genjix
Legendary
*
expert
Offline Offline

Activity: 1232


View Profile
April 24, 2011, 06:30:58 PM
 #1

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).
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480949181
Hero Member
*
Offline Offline

Posts: 1480949181

View Profile Personal Message (Offline)

Ignore
1480949181
Reply with quote  #2

1480949181
Report to moderator
Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
April 24, 2011, 06:47:38 PM
 #2

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.

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
April 24, 2011, 09:11:54 PM
 #3

That's been rejected by Satoshi:
http://bitcointalk.org/index.php?topic=1786.msg22119#msg22119

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
April 24, 2011, 09:28:49 PM
 #4

That's been rejected by Satoshi:

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
Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
April 24, 2011, 09:33:38 PM
 #5

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?
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. 

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
genjix
Legendary
*
expert
Offline Offline

Activity: 1232


View Profile
April 24, 2011, 09:35:02 PM
 #6

How does this apply to OP_TIMESTAMP? The time is always the same on all systems.
Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
April 24, 2011, 09:35:56 PM
 #7

How does this apply to OP_TIMESTAMP? The time is always the same on all systems.
Yes, but the time changes if the transaction has to be moved to a newer block after a reorg.

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
April 24, 2011, 09:37:55 PM
 #8

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.
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
April 24, 2011, 09:56:34 PM
 #9

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?

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
April 24, 2011, 10:01:43 PM
 #10

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.
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. 

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
April 24, 2011, 10:07:50 PM
 #11

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.
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.

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.
To completely avoid this unlikely circumstance you should be careful to spend the coins some time before expiry.

Allowing transactions to become invalid greatly increases the risk that random transactions with 6+ confirmations will become invalid, without much benefit.
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
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
April 24, 2011, 10:12:04 PM
 #12

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.

Quote
If the script language is not stateless, if it has access to any outside information that changes or varies between nodes, attackers can use it to fork the chain.  The only exception is if it is always false before a certain time and permanently true after, which is implemented with nLockTime.

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.
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
April 24, 2011, 10:16:55 PM
 #13

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.  

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

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
April 24, 2011, 10:21:38 PM
 #14

Most/all of that stuff can be done with nLockTime.
Sorry, didn't think that one all the way through, you are right.  I take back my comment.

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
April 26, 2011, 05:03:41 PM
 #15

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.  

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

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
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
April 26, 2011, 05:47:35 PM
 #16

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

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!