• Public
  • Public/Protected
  • All

Interface AuthenticationTemplateScenarioInput

An example input used to define a scenario for an authentication template.


  • AuthenticationTemplateScenarioInput



Optional outpointIndex

outpointIndex: undefined | number

The index of the output in the transaction from which this input is spent.

If undefined, this defaults to 0.

Optional outpointTransactionHash

outpointTransactionHash: undefined | string

A 32-byte, hexadecimal-encoded hash of the transaction from which this input is spent in big-endian byte order. This is the byte order typically seen in block explorers and user interfaces (as opposed to little-endian byte order, which is used in standard P2P network messages).

If undefined, this defaults to the "empty" hash: 0000000000000000000000000000000000000000000000000000000000000000

A.K.A. Outpoint Transaction ID

Optional sequenceNumber

sequenceNumber: undefined | number

The positive, 32-bit unsigned integer used as the "sequence number" for this input.

If undefined, this defaults to 0.


A sequence number is a complex bitfield which can encode several properties about an input:

  • sequence age support – whether or not the input can use OP_CHECKSEQUENCEVERIFY, and the minimum number of blocks or length of time which has passed since this input's source transaction was mined (up to approximately 1 year).
  • locktime support – whether or not the input can use OP_CHECKLOCKTIMEVERIFY

Sequence Age Support

Sequence number age is enforced by mining consensus – a transaction is invalid until it has "aged" such that all outputs referenced by its age-enabled inputs are at least as old as claimed by their respective sequence numbers.

This allows sequence numbers to function as a "relative locktime" for each input: a lockingBytecode can use the OP_CHECKSEQUENCEVERIFY operation to verify that the funds being spent have been "locked" for a minimum required amount of time (or block count). This can be used in protocols which require a reliable "proof-of-publication", like escrow, time-delayed withdrawals, and various payment channel protocols.

Sequence age support is enabled unless the "disable bit" – the most significant bit – is set (i.e. the sequence number is less than (1 << 31) >>> 0/0b10000000000000000000000000000000/2147483648).

If sequence age is enabled, the "type bit" – the most significant bit in the second-most significant byte (1 << 22/0b1000000000000000000000/2097152) – indicates the unit type of the specified age:

  • if set, the age is in units of 512 seconds (using Median Time-Past)
  • if not set, the age is a number of blocks

The least significant 16 bits specify the age (i.e. age = sequenceNumber & 0x0000ffff). This makes the maximum age either 65535 blocks (about 1.25 years) or 33553920 seconds (about 1.06 years).

Locktime Support

Locktime support is disabled for an input if the sequence number is exactly 0xffffffff (4294967295). Because this value requires the "disable bit" to be set, disabling locktime support also disables sequence age support.

With locktime support disabled, if either OP_CHECKLOCKTIMEVERIFY or OP_CHECKSEQUENCEVERIFY are encountered during the validation of unlockingBytecode, an error is produced, and the transaction is invalid.

The term "sequence number" was the name given to this field in the Satoshi implementation of the bitcoin transaction format. The field was originally intended for use in a multi-party signing protocol where parties updated the "sequence number" to indicate to miners that this input should replace a previously-signed input in an existing, not-yet-mined transaction. The original use-case was not completed and relied on behavior which can not be enforced by mining consensus, so the field was mostly-unused until it was repurposed by BIP68 in block 419328. See BIP68, BIP112, and BIP113 for details.

Optional unlockingBytecode

unlockingBytecode: null | string

The unlockingBytecode value of this input for this scenario. This must be either a null value – indicating that this input contains the unlockingBytecode under test by the scenario – or a hexadecimal-encoded bytecode value.

Defaults to an empty string (''). For a scenario to be valid, unlockingBytecode must be null for exactly one input in the scenario.


While the outpointIndex, outpointTransactionHash, and sequenceNumber of every input is part of a transaction's signing serialization, as of 2020, no virtual machine currently requires access to the unlockingBytecode of sibling inputs during the evaluation of an input's unlockingBytecode. However, for completeness (and to allow for testing of virtual machines with this requirement), scenarios may also specify an unlockingBytecode value for each input not under test.

Generated using TypeDoc