What is logic behind transactions?

Question

Can you please help us with this decoded transaction, there is permission granting inside vout 0, however we see transfers inside vout 1 and vout 2:

https://drive.google.com/open?id=0ByqYBT1du673QnhFS3ExbDJBMkE

Based on our research we separated transactions into 4 types:

- Nulldata , thats default transaction when block is cut, we say that it is this type when there are no assets inside vout and when vout 0 scriptpubkey.type = "nulldata"

- Issue (first/more of) , this type of transaction is when we issue an asset or we issue more of it, we know that by having decodedtransaction.issue object and we check vout 0 to see asset info

- Transfer , we know that transaction type is transfer when we have 2 vouts (n=0,n=1)  and 0 vout represents the income for the sender address and vout 1 represents the state of assets inside address that is given inside vout 1

- Permission , we know that transaction type is permission when vout 0 has values inside permission object

Can you please help us with those findings, we are trying to find some logic behind those json responses? Thank you in advance.

Answer 1

First, at least in principle, these categories are not mutually exclusive. For example using the raw transaction interface it would be possible to issue a new asset, transfer an old asset and set a permission in a single transaction. Or to transfer an asset, set a permission, and embed some arbitrary metadata - again, all in our transaction. So instead you should think about testing for each type of action independently:

You can test for an issuance or a transfer by looking at the type field in the assets field of any vout.

You can test for a permissions assignment by looking for a non-empty permissions item in any vout.

You can test for metadata in the data field, although if the transaction is performing an issuance (first or follow-on) that metadata is likely to be specified to that issuance.

Comments

Thank you for your answer. If i understand, you can include all of those transactions inside createrawtransaction parameter, however, if we use precise api calls to:
- Issue asset
- Give address a permission
- Send asset from addressA to addessB with x QTY

Can we be safe to say that those rules from my initial post are true? We are experimenting with those calls, and for now those rules seem to be correct all the time

---

If you use the high level APIs, then issuing an asset and granting a permission will never happen at the same time. However it is possible for either of these transactions to conduct an asset transfer (back to the same address as the sender) if the spent transaction output happened to contain the asset. You can decide whether to consider this a "transfer" or not, since the asset is not really changing hands.