Time
Pay-to-Template destination for a single time lock vault.
Script-level half of the time lock vault: given a chain, an owner secret, an unlock value (a block height, or a Unix timestamp at/above the BIP-65 500,000,000 split), and a BIP-44 leaf index, this object produces the locking script, the nexa: address, and — at spend time — the satisfier that authorises moving the coins out.
The on-chain layout is a standard Nexa P2T output:
[ tag 0014 ][ templateHash (constant) ][ constraintHash ][ unlockValue, hdIndex ]templateis the same script for every vault on the network: pop the index (and ignore it), enforceCHECKLOCKTIMEVERIFYon the unlock value, thenCHECKSIGVERIFYagainst the pubkey.constraintis one push of the 33-byte compressed pubkey derived from secret; its hash160 is what the address commits to.visibleConstraintpushes the cleartext(unlockValue, hdIndex)— visible because the template reads them viaFROMALTSTACK, and also load-bearing for wallet rediscovery after a seed restore.
The vault address is a pure function of (chain, pubkey, unlockValue, hdIndex). Identical inputs produce identical addresses; differing inputs produce differing addresses. The destination does not store the address — any party with the four inputs can recompute it.
Persistence is restricted to SerializationType.DISK so the in-process secret cannot accidentally serialise onto the wire. Only the primary inputs are written; derived scripts are rebuilt from them on load.
atomicSpending is true: the satisfier is produced inline by unlockingScript without going through a multi-party signing protocol.
See docs/time-lock-vault.md for the architectural overview and compatibility invariants.
Constructors
Deserialization constructor. Supplies placeholder primary-ctor args (unlockValue=1, EmptySecret, hdIndex=0) that pass init's range checks, then calls BCHdeserialize to overwrite secret/unlockValue/ hdIndex with the real values from the stream.
Properties
Get the %budoc/glossary/P2SH or %budoc/glossary/P2PKH address associated with this destination Note that only a subset of PayDestinations have addresses. A PayAddress will only exist if this destination constrains spending to require a signature (in the P2PKH case) or a script (P2SH case)
All derived classes that require the execution of a potentially interactive protocol to spend should set this to false and implement member fns
Return a set of bytes that can be put into a bloom filter to select any transaction that contains this destination
Name of the WalletContract this destination belongs to, or null if not contract-attributed.
What type of destination is this?
Exact satisfier size for a time lock spend.
Functions
Rehydrates this destination from the bytes produced by serializeDerived.
If atomicSpending is false, this is how you initiate whatever protocol is needed to sign this transaction. This should only be called if this is your own spending proposal (it is expected that the user has already agreed to this spend)
Two TimeLockVaultDestinations are equal iff they would produce the same on-chain locking script — i.e., the same vault address. That's fully determined by (chainSelector, pubkey, unlockValue, hdIndex):
Get the output script needed to send tokens to this group destination. This script will contain spend constraints in the non-P2SH case, or in the P2SH case this script only constrains spending to execution of the redeemScript and any additional constraints are located in the redeemScript
Standard polynomial-accumulation hash over the same fields equals() compares. The multiplier 31 is the Java/Kotlin convention: it's an odd prime (good bit distribution, no bit loss as values accumulate) and the JVM optimizes 31 * x to (x << 5) - x. Folds each field into a different bit range, so similar destinations (e.g. sequential hdIndex) don't cluster in adjacent HashMap buckets.
Get the locking script needed to send coins to this destination. This script will contain spend constraints in the non-template case, or in the template/P2SH case this script contains the hash of the template/redeem script.
Writes the time-lock-specific fields in disk format. These bytes get appended after PayDestination.serializeTypeAndDerived has written the shared index: i64 framing every destination starts with — that framing runs unconditionally and is independent of this method.
serialize any derived class & the type indicator
Get the template script needed to spend this destination. This script is committed to in the locking script via hash, and must be provided in full in the unlocking script. For P2SH blockchains, this will return the redeemScript since templates are a generalization of P2SH.
Builds the time lock constraint script for a given owner pubkey.
Builds the time lock template (redeem) script.
Get the output script needed to send native coins to this destination. This script will contain spend constraints in the non-P2SH case, or in the P2SH case this script only constrains spending to execution of the redeemScript and any additional constraints are located in the redeemScript
Create a spend (input) script that will satisfy the constraints specified by the lockingScript and the templateScript (if applicable). This script will contain the redeemScript in the P2SH case.
Build the unlocking ("satisfier") script that authorises spending a UTXO locked to this destination.
Encodes per-vault parameters as the script-pushable opcodes that go into a time lock vault's locking script.