The current specification defines reissuance in the following way:
Since the total supply of an asset is hard-coded into the contract itself, there's no way to change it at a later time. The only way to issue more token, thus inflating the supply, is by doing what's called a "re-issuance", which basically means issuing another contract of type 0x03 (reissuance) linked to the previous one by committing it to reissuance_utxo. This feature can be disable by setting reissuance_enabled to 0.
From the description it follows that re-issuing contracts must be committed to the transaction spending some given UTXO. However, with depreciating OP_RETURN commitments for contract deployments (see #107) a better scheme can be designed, in which the re-issuance contract has to be committed to the transaction spending original contract commitment UTXO. The advantages of this approach is that (a) it is simpler, and (b) there is no burden of remembering that some external UTXO must not be spend in order to prevent locking of the asset re-issuance; it will be better to link this process to the UTXO that already contains tweaked key, which can't be spent in an un-aware way
The current specification defines reissuance in the following way:
From the description it follows that re-issuing contracts must be committed to the transaction spending some given UTXO. However, with depreciating OP_RETURN commitments for contract deployments (see #107) a better scheme can be designed, in which the re-issuance contract has to be committed to the transaction spending original contract commitment UTXO. The advantages of this approach is that (a) it is simpler, and (b) there is no burden of remembering that some external UTXO must not be spend in order to prevent locking of the asset re-issuance; it will be better to link this process to the UTXO that already contains tweaked key, which can't be spent in an un-aware way