Bitcoin Forum
December 17, 2017, 05:27:16 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Soft-fork Proposal: allow nLockTime specify an UPPER limit instead of lower lim.  (Read 1140 times)
Sergio_Demian_Lerner
Hero Member
*****
expert
Offline Offline

Activity: 539


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.
1513488436
Hero Member
*
Offline Offline

Posts: 1513488436

View Profile Personal Message (Offline)

Ignore
1513488436
Reply with quote  #2

1513488436
Report to moderator
1513488436
Hero Member
*
Offline Offline

Posts: 1513488436

View Profile Personal Message (Offline)

Ignore
1513488436
Reply with quote  #2

1513488436
Report to moderator
1513488436
Hero Member
*
Offline Offline

Posts: 1513488436

View Profile Personal Message (Offline)

Ignore
1513488436
Reply with quote  #2

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

Posts: 1513488436

View Profile Personal Message (Offline)

Ignore
1513488436
Reply with quote  #2

1513488436
Report to moderator
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2870


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


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: 1260


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
Staff
Legendary
*
Offline Offline

Activity: 1876



View Profile
October 10, 2013, 11:22:12 PM
 #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.
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2870


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: 1260


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:  

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!