TL;DR: The aim is to discourage reorganizations and increase privacy.
In wallet.cpp, just above where nLockTime gets set, it says:
// Discourage fee sniping.
// For a large miner the value of the transactions in the best block and
// the mempool can exceed the cost of deliberately attempting to mine two
// blocks to orphan the current best block. By ...
A specified locktime indicates that the transaction is only valid at the given blockheight or later.
Since the locktime field indicated is 419382 and currently the latest blockheight as of 12th July 2016 1108 (AEST) is 420352 the transaction is now valid and can be included in a block by any miner that chooses to do so.
I believe you are correct, both about the fact that height-based logic came first and time was added later, and the fact that this is a hard-forking change. A transaction with a locktime > 500000000 would not have been acceptable before the change, but possibly valid after.
Of course, given that no such transactions occurred (to the best of my knowledge), ...
No, there isn't currently any way to do what you describe without using a third-party oracle.
Yes, you may be able to do this relatively soon. A soft fork has been proposed to introduce a OP_CHECKLOCKTIMEVERIFY op code` (CLTV), and what what I can tell it has strong support from the core dev team (but note that soft forks require miner support for ...
Yes, there is tx.nLockTime. A transaction mined before its nLockTime is invalid, so you can send your funds to yourself on some newly created address, then send it back with a locktime and destroy the private key for the newly created address. Transactions with nLockTime can be amended, but since you destroyed the private key, you actually can't, thus ...
This is because CSV and CLTV are NOP opcodes that were redefined in a softfork.
As a softfork can only change the validity of transactions from valid to invalid, the only effect this redefinition was allowed to have is making the script abort in some conditions, and keep acting like NOP otherwise.
NOP does not pop anything off the stack, and as a result, ...
No. In the reference client, main.cpp runs this check during "AcceptBlock":
// Check that all transactions are finalized
BOOST_FOREACH(const CTransaction& tx, block.vtx)
if (!IsFinalTx(tx, nHeight, block.GetBlockTime()))
return state.DoS(10, error("AcceptBlock() : contains a non-final transaction"),
If you're creating a version 2 transaction with the disable flag not set, then by definition the whole nSequence value will be less than 0xFFFFFFFE (because it will be at most 0x7FFFFFFF).
This implies that a transaction with an active relative locktime will always be replacable according to BIP125.
This is intentional. Nonreplacable transactions attempt ...
In order to use a relative time lock, you need to provide the requirements in the scriptPubKey to which the Bitcoin is sent.
scriptPubKey for escrow with 30 day timeout:
2 <Alice's pubkey> <Bob's pubkey> <Escrow's pubkey> 3 CHECKMULTISIG
"30d" CHECKSEQUENCEVERIFY DROP
<Alice's pubkey> CHECKSIG
Yes, you can use OP_CHECKLOCKTIMEVERIFY opcode in the locking script of the output. This opcode takes either blocks or Unix Epoch Time (seconds since 1-Jan-1970) as the parameter to lock. If the parameter is non-zero and below 500 million, it is interpreted as a block height, if it is greater than or equal to 500 million, it is interpreted as a Unix Epoch ...
The locktime value is deliberately set to discourage a subtle attack known as "Fee sniping" and randomly set to an earlier block height to improve privacy (eg for CoinJoin users that need more setup time).
This is also done in Bitcoin Core with the nLockTime.
The Wiki was incorrect (I wrote the original text and I apologize). As indicated in the question, the ordering on the Wiki was backwards. However, upon investigating, I don't believe it was a hard fork. In the original Bitcoin 0.1 code, we find the following function:
bool IsFinal() const
if (nLockTime == 0 || nLockTime < nBestHeight)
It stand for a number, it is commonly used in programming to designate a variable that gonna hold an amount of something see: https://en.bitcoin.it/wiki/NLockTime and https://en.bitcoinwiki.org/wiki/NSequence
It's checked in the IsFinal() method of CTransaction. A non-final transaction cannot be included in blocks.
A transaction is final if either:
The lock time is in the past.
All of the inputs have sequence numbers equal to UINT_MAX.
The second one is probably what confused you.
Since one of the inputs of the nLockTime transaction has been spent already, the nLockTime transaction becomes invalid, as not all referenced inputs are available for spending.
This is described in the Bitcoin developers guide explicitly as a way to cancel a locktime transaction:
If any of the signers change their mind, they can create a new non-...
The UTXO is referenced as an outpoint(TXID, Index) in the input of your time-locked spending transaction.
So, when creating your time-locked transaction, you need to know the TXID of the (unconfirmed) transaction you are spending.
Simply double+sha256 and swap endianness of the over-the-wire transaction serialisation to get the TXID you wish to reference. ...
Lock Time refers to at which block height the transaction can be included by a miner. In this case 419382 has well passed, so it can be included in any block at this point. Your transaction is currently not confirmed since you have 5 inputs, and it was sent with zero fee. It may take a little while. Not sure where you are coming up with the 1 week part, ...
This can be accomplished with a simple smart contract between you and the recipient using a transaction's locktime. Here are the steps:
Create a transaction to the recipient's address spending UTXO's (unspent transaction outputs) that you own, and setting the locktime to the start date of your grace period.
Create a second transaction spending the exact ...
nLocktime has always been standard and is used to prevent fee sniping.
OP_CHECKLOCKTIMEVERIFY is currently not implemented and is not enforced.
A non-standard transaction can be mined by a miner, but will not relay around the normal peer to peer network. A transaction who has a nLockTime which has not been passed is invalid, and won't be relayed or ...
Say that currently, the block height is 377199. If I wanted to send money to someone, but only have them receive it at some time in the future, then I could make a transaction to their address, set the locktime to 400000 and set all sequence numbers in the transaction to 0xffffffff. This transaction will get mined into block 377200 or maybe 377201.
Blocks have timestamps, transactions don't. The time of a block creation is known, the time of the transaction can only be guessed. Most clients use the block's time for transactions, and if they're still in the transaction mempool (not in a block) they use the time the transaction was first seen by the client.
The release notes for Bitcoin Core (Satoshi client) version 0.9.0 states
Accept nLockTime transactions that finalize in the next block
So it will just discard other nLockTime transactions. Since most miners run bitcoind or some fork of bitcoind, it is unlikely that an nLockTime transaction will persist for a long time.
When using a multisig Green Address wallet your funds are locked in a 2-of-2 multisig account, i.e. if you want to spend money from that account you need both your signature and Green Address' signature. This is done so that Green Address can guarantee that you will not try to double spend money from that account. This allows Green Address to grant you ...
I am leaving out a few details here, but this will get you thinking on the right path...
Alice and Bob have accounts on both the Bitcoin and Litecoin networks. Bob has Bitcoin, but wants Litecoin. Alice has Litecoin and wants Bitcoin. They do not trust each other.
Both agree to trade Bob's 1 Bitcoin for 2.5 of Alice's Litecoin.
Alice starts the ...
The guarantee comes from the consensus rule that a block's timestamp must be greater than the median timestamp of the last 11 blocks. This median timestamp is known as the median time of the block. Because the median is used, and because timestamps of each block must be greater than their median time, the median time will always increase from block to block. ...
Worth keeping in mind: Unless all inputs to the original transaction are segwit and at least one is sighash all, the original transaction will be vulnerable to third party malleability so your second spend could get invalidated.
If you look at git blame of BOLT 03 you can track the sentence regarding the locktime down to this commit: https://github.com/lightningnetwork/lightning-rfc/commit/f1eaa2544665c9b85a2fd95be9c83dad45888982
luckily the author gave a good explanation in the commitment message in git of why the 0x20 was introduced for the upper 8 bits in the locktime field (I ...
A transaction becomes valid when the chaintip reaches the height specified in the locktime, and may be included in any block with a height greater than nLockTime.
if ((int64_t)tx.nLockTime < ((int64_t)tx.nLockTime < LOCKTIME_THRESHOLD ? (int64_t)nBlockHeight : nBlockTime))
From the wiki it basically states that you can make a transaction to another bitcoin address and add nlocktime. The way that this would work in real life would be if you get paid on salary and are paid bi-weekly, the bitcoins will be on the network but won't reach you until the nlocktime is up
Edit: read example 1 from https://en.bitcoin.it/wiki/Contracts