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 after a given blockheight.
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), ...
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 ...
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 ...
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, ...
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)
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.
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
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. ...
If the nLockTime is less than or equal to the next block height, it can be included in the next block.
To explicitly answer your questions:
The CLTV op restricts the nLockTime field of the spending transaction, therefore if it is set in the past the condition is already fulfilled.
If the nLockTime field of a transaction is set to 500 000 it is valid to be ...
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 ...
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, ...
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.
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 ...
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.
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))
The best strategy really depends on the user. You distinguish tradeoffs in all these solutions:
Open a new channel each time
This one does not make sense.
Open 10 channel for 0.01 BTC
More exposure to DOS (and onchain fees), but less exposure to censorship.
Probably the solution which makes the most of sense (or 5 channels for 2mBTC) since MPP.
Open 1 ...
I'm unable to find the bitcointalk thread/github issue discussing this, but a block index opcode was considered and rejected.
The reason (IIRC) is that it's important that if a transaction does not get into a block, it can still be included in another block. It would be very surprising if a transaction was reversed because the block it was in became extinct,...