Bitcoin Forum
May 08, 2024, 03:29:25 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Soft-fork Proposal: allow nLockTime specify an UPPER limit instead of lower lim.  (Read 1234 times)
Sergio_Demian_Lerner (OP)
Hero Member
*****
expert
Offline Offline

Activity: 552
Merit: 629


View Profile WWW
October 09, 2013, 11:01:10 PM
 #1

In the thread https://bitcointalk.org/index.php?topic=307211.0 I propose a method to protect users money from attackers by creating 2-step transactions, so users can roll-back if an attacker attempts to do step 1. The first step can be reverted using cold storage keys. I called it the "Tick method".

I realized that the same method could be implemented much more easily if transactions could specify a time/block number after they are unable to be accepted in the block chain.

Currently nLockTime has a threshold:

int LOCKTIME_THRESHOLD = 500000000; // Tue Nov  5 00:53:20 1985 UTC

Values lower than LOCKTIME_THRESHOLD are considered block numbers and values higher than LOCKTIME_THRESHOLD they are considered unix timestamps.
Since Bitcoin didn't existed from 1985 to 2009, I propose a soft-fork where nLockTime in ranges:

nLockTime in (LOCKTIME_THRESHOLD to 510000000): Valid before block (nLockTime- LOCKTIME_THRESHOLD+262634) (190 years avail, upto 2203)
nLockTime in (510000000 to 1230000000): Valid before time (nLockTime-510000000+1230000000): 22.8 years avail (up to 2036)

Code change should look something like: (note: I'm not taking into account txin.IsFinal(), this is just an example)

  
Code:
  
bool IsFinal(int nBlockHeight=0, int64 nBlockTime=0) const
    {
   ....
        if ((int64)nLockTime < LOCKTIME_THRESHOLD )        {
          if ((int64)nLockTime < (int64)nBlockHeight)
             return true;
        }
       else
       if  ( (int64)nLockTime <510000000)       {
          if ((int64)nLockTime- LOCKTIME_THRESHOLD+262634 >= (int64)nBlockHeight)
             return true;
       }
       else
       if  ( (int64)nLockTime <1230000000)       {
          if ((int64)nLockTime-510000000+1230000000 >= (int64)nBlockTime)
             return true;
       }
      else
      if ((int64)nLockTime > (int64)nBlockTime)
             return true;
  ...
}

There may be many more use case (Mike Hearn?)

Best regards,
 Sergio.
1715182165
Hero Member
*
Offline Offline

Posts: 1715182165

View Profile Personal Message (Offline)

Ignore
1715182165
Reply with quote  #2

1715182165
Report to moderator
1715182165
Hero Member
*
Offline Offline

Posts: 1715182165

View Profile Personal Message (Offline)

Ignore
1715182165
Reply with quote  #2

1715182165
Report to moderator
1715182165
Hero Member
*
Offline Offline

Posts: 1715182165

View Profile Personal Message (Offline)

Ignore
1715182165
Reply with quote  #2

1715182165
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715182165
Hero Member
*
Offline Offline

Posts: 1715182165

View Profile Personal Message (Offline)

Ignore
1715182165
Reply with quote  #2

1715182165
Report to moderator
1715182165
Hero Member
*
Offline Offline

Posts: 1715182165

View Profile Personal Message (Offline)

Ignore
1715182165
Reply with quote  #2

1715182165
Report to moderator
1715182165
Hero Member
*
Offline Offline

Posts: 1715182165

View Profile Personal Message (Offline)

Ignore
1715182165
Reply with quote  #2

1715182165
Report to moderator
theymos
Administrator
Legendary
*
Offline Offline

Activity: 5194
Merit: 12976


View Profile
October 10, 2013, 06:20:22 AM
 #2

That would reduce Bitcoin's security/robustness model. Currently, it isn't possible for a transaction to become invalid after a chain fork of less than 100 blocks unless double-spending is involved. With threshold transactions, a long fork (due to a netsplit, bug, etc.) can cause widespread havoc by invalidating tons of transactions dependent on a threshold transaction. Maybe it'd be OK if threshold transactions had the same 100-block spending limit as coinbase transactions, but this extra complexity isn't worthwhile IMO unless there's some amazing application for these transactions.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1129


View Profile
October 10, 2013, 08:33:16 AM
 #3

Agree with theymos. Please, let's just fix the original intended use cases of nLockTime before inventing new ones.
ripper234
Legendary
*
Offline Offline

Activity: 1358
Merit: 1003


Ron Gross


View Profile WWW
October 10, 2013, 10:27:42 PM
 #4

That would reduce Bitcoin's security/robustness model. Currently, it isn't possible for a transaction to become invalid after a chain fork of less than 100 blocks unless double-spending is involved. With threshold transactions, a long fork (due to a netsplit, bug, etc.) can cause widespread havoc by invalidating tons of transactions dependent on a threshold transaction. Maybe it'd be OK if threshold transactions had the same 100-block spending limit as coinbase transactions, but this extra complexity isn't worthwhile IMO unless there's some amazing application for these transactions.

Hmm, I wasn't aware of anything special happening at the 100 block mark.
Can you repeat your answer with a few more details and references, for poor ignorant souls such as myself?

Please do not pm me, use ron@bitcoin.org.il instead
Mastercoin Executive Director
Co-founder of the Israeli Bitcoin Association
malevolent
can into space
Legendary
*
Offline Offline

Activity: 3472
Merit: 1721



View Profile
October 10, 2013, 11:22:12 PM
Last edit: October 10, 2013, 11:36:43 PM by malevolent
 #5

Hmm, I wasn't aware of anything special happening at the 100 block mark.
Can you repeat your answer with a few more details and references, for poor ignorant souls such as myself?

I think he was referring to the 100 (network) or 120 (client) blocks one has to wait before the coins can be spent (COINBASE_MATURITY). After a reorg, transactions involving BTC from orphaned blocks become invalid.

Signature space available for rent.
theymos
Administrator
Legendary
*
Offline Offline

Activity: 5194
Merit: 12976


View Profile
October 10, 2013, 11:25:59 PM
 #6

Hmm, I wasn't aware of anything special happening at the 100 block mark.
Can you repeat your answer with a few more details and references, for poor ignorant souls such as myself?

Sometimes (though very rarely), there is a large chain fork. In a fork, the miners mining on what ends up being the wrong side of the fork lose their mining rewards when the chain merges again. Anyone who received those newly-mined coins (perhaps over many "generations" of transactions) will have those transactions permanently invalidated. This is very bad. To prevent this from happening, the Bitcoin network prohibits coinbase transactions (mining rewards) from being spent for 100 blocks. As a result, a fork must be longer than 100 blocks for any non-coinbase transactions to be invalidated unless there's double-spending involved. Any change to Bitcoin which would allow a valid transaction to later become invalid would break Bitcoin's robustness in this area unless such transactions had similar 100-block spending restrictions.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
ripper234
Legendary
*
Offline Offline

Activity: 1358
Merit: 1003


Ron Gross


View Profile WWW
October 10, 2013, 11:45:05 PM
 #7

Hmm, I wasn't aware of anything special happening at the 100 block mark.
Can you repeat your answer with a few more details and references, for poor ignorant souls such as myself?

Sometimes (though very rarely), there is a large chain fork. In a fork, the miners mining on what ends up being the wrong side of the fork lose their mining rewards when the chain merges again. Anyone who received those newly-mined coins (perhaps over many "generations" of transactions) will have those transactions permanently invalidated. This is very bad. To prevent this from happening, the Bitcoin network prohibits coinbase transactions (mining rewards) from being spent for 100 blocks. As a result, a fork must be longer than 100 blocks for any non-coinbase transactions to be invalidated unless there's double-spending involved. Any change to Bitcoin which would allow a valid transaction to later become invalid would break Bitcoin's robustness in this area unless such transactions had similar 100-block spending restrictions.

Thanks, it's clearer now ... I wasn't aware you're talking about coinbase transactions.

Please do not pm me, use ron@bitcoin.org.il instead
Mastercoin Executive Director
Co-founder of the Israeli Bitcoin Association
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!