8

the purpose of OP_CHECKLOCKTIMEVERIFY is kind of the opposite to the purpose of tx.nLockTime. tx.nLockTime prevents transactions with future dates from entering the blockchain, whereas OP_CHECKLOCKTIMEVERIFY enables someone to freeze funds so that they can only be spent after a given timestamp or block height. tx.nLockTime tx.nLockTime is validated by ...


6

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, ...


5

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 ...


5

Taking a stab at answering my own question. Both the transaction using OP_CHECKLOCKTIMEVERIFY in its output script and the one spending OP_CHECKLOCKTIMEVERIFY can be mined immediately in most cases. The output script will probably be used in a P2SH (pay to script hash) so no one will even know that CLTV is even used--only the hash will be visible. On to ...


5

From the bitcoin wiki: The stacks hold byte vectors. When used as numbers, byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer. Thus 0x81 represents -1. 0x80 is another representation of zero (so called negative 0). Positive 0 is represented by a null-length vector. Byte ...


5

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 ...


4

Bitcoin uses a stack based language due to which the logical condition that will execute the IF or ELSE statements comes prior to the operator IF or ELSE. Let's take both your cases one by one and see how it gets executed on the stack. Case 1: ScriptSig: 0 <Alice's signature> <Bob's signature> 0 The stack starts at 0 <Alice's signature> &...


4

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-...


3

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. ...


3

Maybe not with OP_CHECKLOCKTIMEVERIFY, as it is not possible to consume an external input with that particular operation. But you can write a third-party oracle that will release some secret (i.e. a hash) based on the set of potential use-cases you have suggested, so the beneficiary could redeem the funds promised on the fulfillments of the condition. A ...


3

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. ...


2

mulllhausen's answer is great, but here's a shorter example that illustrates why the vin seq number can't be final or maxed. Suppose I want to spend a CLTV output. I wait until the CLTV time has passed, and then create a transaction with nLockTime set to the current block time, and the sequence number set to something less than 2^32-1, say 0. Now that ...


2

From Bitcoin.org: Locktime allows signers to create time-locked transactions which will only become valid in the future, giving the signers a chance to change their minds. ... Previous versions of Bitcoin Core provided a feature which prevented transaction signers from using the method described above to cancel a time-locked transaction, but a ...


2

If at least two of the partners are cooperative with each other, they can move the funds at any time, even before the 30 days have elapsed. They can spend the output at any time using the second redeem path, with at least two signatures, for example: 0 <Mohammed's Sig> <Zaira's Sig> TRUE TRUE So to 'renew' the time, they just need to spend the ...


2

They 'reset' the clock by moving the funds to a new output before the period ends.


2

All fields in a Bitcoin transaction are little-endian encoded except for the signature fields and the public key fields which are both DER and big-endian encoded since they were originally produced by an external library that uses these encodings. Would it be prudent/responsible for the BIP 68 Standard to make it clear whether the bit-encoding is ...


2

It should be, since all changes to the Bitcoin protocol should be agreed on by the entire community. However, there is no way to guarantee a softfork can't be abused, or even necessarily invalidate such a transaction, and there has recently been hardfork efforts by incompetent people to promote breaking compatibility, so I would advise against relying on it ...


1

You're putting a script directly in the scriptPubKey. That's both discouraged, non-standard, and hard to use, as you've noticed there is no corresponding address. There are only three types of addresses defined (with common acceptance) in Bitcoin: base58-encoded P2PKH addresses (1...), base58-encoded P2SH addresses (3...), and bech32-encoded native segwit ...


1

When you lock coins in CLTV you still have to provide an address in the output. In that field, you can just include the address that your wallet controls. When you spend those coins, all you need to do is include the nlocktime which is higher than that specified when locking using the CLTV opcode. You need not do a second stage transaction to send the ...


1

Note: Although this answer is written for testnet, it is absolutely valid for the mainnet as well. The script will be similar, just the address encoding will be different (P2PKH start with 1 vs m for testnet as we use 0x00 as prefix in address base58check in mainnet). I tried to make transaction with Locktime on bitcoin testnet. I am not able to broadcast ...


1

Block timestamps are allowed be to slightly off (up to 2 hours). This poses an issue for locktime transactions, since a miner could claim the block timestamp to be up to two hours in the future, and thus include lock time transactions before they are actually supposed to be mined. By using the median time over the last 11 blocks, the miner's own choice of ...


1

Setting the nLockTime field of a transaction restricts confirmation of the current transaction until a certain block height. Using a CLTV op in the locking script of an output of the current transaction will restrict the confirmation of the next transaction (i.e. the one that spends this output), by forcing the next transaction's nLockTime to be equal to the ...


1

You might be able to combine a hash lock with a conditional payout. Here's a somewhat simplified example that shows how to make a payout depend on knowledge of a secret. Bob makes a bet with Alice that she can't guess Bob's secret before a deadline. Alice proves she knows the secret by publishing the preimage to its hash value, which Bob publishes. Alice ...


1

It's not that simple. Even after a new version is released, breaking backwards compatibility, it has to be adopted. It would have to be decided by the bitcoin community to go ahead and run the new version of the software. This happened with ethereum. An exploit occurred on a smart contract and a new version was released where the hacked funds couldn't be ...


1

Wallet Y won't receive payment until nLockTime condition passed and transaction included into a block. AFAIK most peers won't relay nlocktime with 1 month in the future. https://bitcoin.stackexchange.com/a/26983/12049 Once transaction gets included into the blockchain, it can't be undone. So the second transaction spending B is valid, and the first ...


Only top voted, non community-wiki answers of a minimum length are eligible