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)

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.

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?

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.

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.

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.