Validate lock times in the transaction verifier

[teor2345]

Motivation

Zebra's transaction verifier needs to check the Transaction lock_time field.

Specifications

The lock_time (or nLockTime) and tx_in.sequence fields are defined in the transaction encoding specification.

https://zips.z.cash/protocol/protocol.pdf#consensusfrombitcoin

The transaction must be finalized: either its locktime must be in the past (or less than or equal to the current block height), or all of its sequence numbers must be 0xffffffff.

https://developer.bitcoin.org/devguide/transactions.html#non-standard-transactions

Zcash-specific clarification:

Lock times are only enabled if there is at least one sequence number that is not u32::MAX. So transactions with no transparent inputs are always accepted, regardless of the value of the lock time field.

zcash/zips#539

Interaction with Input Sequence Numbers

[There] are four-byte sequence numbers in every input. Sequence numbers were meant to allow multiple signers to agree to update a transaction; when they finished updating the transaction, they could agree to set every input’s sequence number to the four-byte unsigned maximum (0xffffffff), allowing the transaction to be added to a block even if its time lock had not expired.

Even today, setting all sequence numbers to 0xffffffff (the default in Bitcoin Core) can still disable the time lock, so if you want to use locktime, at least one input must have a sequence number below the maximum. Since sequence numbers are not used by the network for any other purpose, setting any sequence number to zero is sufficient to enable locktime.

Locktime itself is an unsigned 4-byte integer which can be parsed two ways:

If less than 500 million, locktime is parsed as a block height. The transaction can be added to any block which has this height or higher.

If greater than or equal to 500 million, locktime is parsed using the Unix epoch time format (the number of seconds elapsed since 1970-01-01T00:00 UTC—currently over 1.395 billion). The transaction can be added to any block whose block time is greater than the locktime.

https://developer.bitcoin.org/devguide/transactions.html#locktime-and-sequence-number

Clarification:

Coinbase inputs have a sequence number, and coinbase transaction lock times are checked just like any other transaction.

zcash/zips#539

Interaction with Expiry Height

This rule is in ZIP 203, but we don't think it was ever implemented in zcashd:
If used in combination with nLockTime, both nLockTime and nExpiryHeight must be block heights.

Designs

Zebra already parses the lock time:

zebra/zebra-chain/src/transaction.rs

Lines 173 to 174 in 22f2f06

	/// Get this transaction's lock time.
	pub fn lock_time(&self) -> LockTime {

zebra/zebra-chain/src/transaction/lock_time.rs

Lines 21 to 26 in 22f2f06

	pub enum LockTime {
	/// Unlock at a particular block height.
	Height(block::Height),
	/// Unlock at a particular time.
	Time(DateTime<Utc>),
	}

And input sequence numbers:

zebra/zebra-chain/src/transparent.rs

Lines 73 to 92 in 22f2f06

	pub enum Input {
	/// A reference to an output of a previous transaction.
	PrevOut {
	/// The previous output transaction reference.
	outpoint: OutPoint,
	/// The script that authorizes spending `outpoint`.
	unlock_script: Script,
	/// The sequence number for the output.
	sequence: u32,
	},
	/// New coins created by the block reward.
	Coinbase {
	/// The height of this block.
	height: block::Height,
	/// Free data inserted by miners after the block height.
	data: CoinbaseData,
	/// The sequence number for the output.
	sequence: u32,
	},
	}

But lock_time returns zero lock times as Height(0), rather than None.

Similarly, Zebra does not check sequence numbers. If there are no sequence numbers, or they are all u32::MAX, lock_time should return None.

Missing Information in Transaction Verifier Request

The block time is not currently sent as part of the transaction verifier request.