Optional
ageOptional
estimate?: stringThe identifier of the scenario to use for this unlocking script when compiling an estimated transaction.
Using estimate scenarios, it's possible for wallet software to compute an "estimated transaction", an invalid transaction that is guaranteed to be the same byte length as the final transaction. This length can be used to calculate the required transaction fee and assign values to the transaction's change output(s). Because estimate scenarios provide "estimated" values for all variables, this estimation can be done by a single entity without input from other entities.
If not provided, the default scenario will be used for estimation. The
default scenario only provides values for each Key
and HdKey
variable,
so compilations requiring other variables will produce errors. See
WalletTemplateScenario.extends
for details.
Optional
fails?: string[]A list of the scenario identifiers that – when used to compile this unlocking script and the script it unlocks – result in bytecode that fails program verification.
These scenarios can be used to test this script in development and review.
Optional
invalid?: string[]A list of the scenario identifiers that – when used to compile this unlocking script and the script it unlocks – result in a compilation error.
These scenarios can be used to test this script in development and review.
Optional
passes?: string[]A list of the scenario identifiers that – when used to compile this unlocking script and the script it unlocks – result in bytecode that passes program verification.
These scenarios can be used to test this script in development and review.
Optional
timeThe expected type of time locks in this script.
Because OP_CHECKLOCKTIMEVERIFY
reads from a transaction's locktime
property, every input to a given transaction must share the same time lock
type. This differs from OP_CHECKSEQUENCEVERIFY
in that each input has its
own sequenceNumber
, so compatibility is not required.
If a transaction includes multiple inputs using scripts with timeLockType
defined, and the types are not compatible, generation should fail.
The timestamp
type indicates that the transaction's locktime is provided
as a UNIX timestamp (the locktime
value is greater than or equal to
500000000
).
The height
type indicates that the transaction's locktime is provided as
a block height (the locktime
value is less than 500000000
).
If timeLockType
is undefined, the script is assumed to have no reliance
on absolute time locks.
The identifier of the script that can be unlocked by this script.
The presence of the unlocks
property indicates that this script is an
unlocking script, and the script it unlocks must be a locking script.
Generated using TypeDoc
TODO: not yet implemented
The minimum input age required for this unlocking script to become valid.
This value is provided as a CashAssembly script that must compile to the least significant 3 bytes of the minimum sequence number required for this unlocking script to be valid (the "type bit" and the 2-byte "value" – see BIP68 for details). This script has access to all other template scripts and variables, but cyclical references will produce an error at compile time.
In supporting wallets, this value can be computed at address creation time, and the remaining time for which any UTXO remains "age-locked" can be displayed in user interfaces (by parsing the "type bit" and "value" as described in BIP68).
Note, because the precise value used by
OP_CHECKSEQUENCEVERIFY
can be provided in the unlocking script, it is trivial to create an unlocking script for which a proper value forageLock
is not possible to determine until the spending transaction is prepared. These cases are intentionally out-of-scope for this property. Instead,ageLock
should only be used for unlocking scripts where the expected value can be compiled at address creation time.