Pay
A destination for payments. This includes all the information needed to send and spend from this destination. It is often assumed that Bitcoin addresses are payment destinations, but this is not true. You really need an output script, and also (if P2SH) a redeem script. The reason why P2PKH addresses "work" as payment destinations is because they imply a specific script. But "baking in" this assumption will make the wallet a lot less flexible.
A note on terminology:
For legacy and terminology compatibility with other chains "Locking" and "Unlocking" scripts will refer to the entire output and input "scripts" in the transaction. So in nexa they are not really scripts (even though they are serialized in the same format), they really a pile of data items.
The "template script" is the main script that controls spending, created by the covenant author or the holder (if not covenanted). The "constraint script" is additional constraining arguments that the owner is allowed to apply to the template. The "satisfier script" is the final args that "satisfy" (by correct execution) the template/constraint script combo.
So the locking script contains the group info, the hash of the template script, the hash of the hidden constraint script (actually args), and additional visible constraint script (actually args). On the spending side, the "unlocking script" contains the actual template script, the actual constraint script, and the satisfier script.
Inheritors
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
What type of destination is this?
Functions
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)
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
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.
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.
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.
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. Many scripts require signatures. This API provides the data needed for this class to craft signatures, and provides additional derived-class defined params.