Print Page - Soft-fork Proposal: allow nLockTime specify an UPPER limit instead of lower lim.

Title: Soft-fork Proposal: allow nLockTime specify an UPPER limit instead of lower lim.
Post by: Sergio_Demian_Lerner on October 09, 2013, 11:01:10 PM

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.

Title: Re: Soft-fork Proposal: allow nLockTime specify an UPPER limit instead of lower lim.
Post by: theymos on October 10, 2013, 06:20:22 AM

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.

Title: Re: Soft-fork Proposal: allow nLockTime specify an UPPER limit instead of lower lim.
Post by: Mike Hearn on October 10, 2013, 08:33:16 AM

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

Title: Re: Soft-fork Proposal: allow nLockTime specify an UPPER limit instead of lower lim.
Post by: ripper234 on October 10, 2013, 10:27:42 PM

Quote from: theymos on October 10, 2013, 06:20:22 AM

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?

Title: Re: Soft-fork Proposal: allow nLockTime specify an UPPER limit instead of lower lim.
Post by: malevolent on October 10, 2013, 11:22:12 PM

Quote from: ripper234 on October 10, 2013, 10:27:42 PM

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.

Title: Re: Soft-fork Proposal: allow nLockTime specify an UPPER limit instead of lower lim.
Post by: theymos on October 10, 2013, 11:25:59 PM

Quote from: ripper234 on October 10, 2013, 10:27:42 PM

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.

Title: Re: Soft-fork Proposal: allow nLockTime specify an UPPER limit instead of lower lim.
Post by: ripper234 on October 10, 2013, 11:45:05 PM

Quote from: theymos on October 10, 2013, 11:25:59 PM

Quote from: ripper234 on October 10, 2013, 10:27:42 PM

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?

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

Bitcoin Forum

Bitcoin => Development & Technical Discussion => Topic started by: Sergio_Demian_Lerner on October 09, 2013, 11:01:10 PM