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

ripper234

legendary

Activity: 1358

Merit: 1003

Ron Gross

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

Quote from: ripper234 on October 10, 2013, 05: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.

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

theymos

administrator

Activity: 5222

Merit: 13032

Quote from: ripper234 on October 10, 2013, 05: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.

malevolent

legendary

Activity: 3472

Merit: 1722

Quote from: ripper234 on October 10, 2013, 05: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.

ripper234

legendary

Activity: 1358

Merit: 1003

Ron Gross

Quote from: theymos on October 10, 2013, 01: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.

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?

Mike Hearn

legendary

Activity: 1526

Merit: 1134

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

theymos

administrator

Activity: 5222

Merit: 13032

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.

Sergio_Demian_Lerner

hero member

Activity: 555

Merit: 654

In the thread https://bitcointalksearch.org/topic/making-hot-wallets-impossible-to-steal-now-with-5-btc-bounty-307211 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.

Topic: Soft-fork Proposal: allow nLockTime specify an UPPER limit instead of lower lim. (Read 1255 times)