Advanced Transactions and Scripting

This chapter covers advanced transactions and scripting. Here, we will learn about different transaction types and the scripts that create them. You'll use concepts like pay-to-script-hash and multi-sig in almost any Bitcoin development project.

Transaction locktime limitations

nLocktime has the limitation that while it makes it possible to spend some outputs in the future, it does not make it impossible to spend them until that time. Let's explain that with the following example.

Alice signs a transaction spending one of her outputs to Bob's address, and sets the transaction nLocktime to 3 months in the future. Alice sends that transaction to Bob to hold. With this transaction Alice and Bob know that:

  • Bob cannot transmit the transaction to redeem the funds until 3 months have elapsed.
  • Bob may transmit the transaction after 3 months.

However:

  • Alice can create another transaction, double-spending the same inputs without a locktime. Thus, Alice can spend the same UTXO before the 3 months have elapsed.
  • Bob has no guarantee that Alice won't do that.

It is important to understand the limitations of transaction nLocktime. The only guarantee is that Bob will not be able to redeem it before 3 months have elapsed. There is no guarantee that Bob will get the funds. To achieve such a guarantee, the timelock restriction must be placed on the UTXO itself and be part of the locking script, rather than on the transaction. This is achieved by the next form of timelock, called Check Lock Time Verify.