Vout hex decode

Question

Hi, we have tx example: https://explorer.xfccoin.io/api/getrawtransaction?txid=2c471ad416f3098edd2a3c259e87e165ed1420e7e16c93dc16b699aa4e47cf49&decrypt=1

Vout 0 hex 76a914c7e599002aa10db30323c355e019e18cea440ebc88ac1c73706b71...

What does this single byte between p2pkh script and metadata do? How to interpret it?

 

Vout 1 hex:

76a914a8d59dfa8a7478240aaaacb6f5bc4b46614a793688ac4d040373706b71...

Again what is this byte sequence for?

 

Additional question, if i have some assets: x(10) y(10) z(10) and I am sending one X asset to someone, this tx should ALWAYS contain change vout with x(9) y(10) z(10) and if I am creating tx from scratch (without multichaind) - I will have to create this change output by myself with all unspent assets I have?

Answer 1

The output scripting language uses bitcoin format. So both of these byte strings indicate the presence and length of the forthcoming block of data. You can find all the details here: https://en.bitcoin.it/wiki/Script

Additional question: Yes, if you are building the transaction yourself without multichaind, you would need to add the change output yourself, to make sure assets balance across inputs and outputs.

But if it's an option you may also want to look at MultiChain's raw transaction APIs, like createrawtransaction, appendrawchange, appendrawtransaction

Comments

Thanks for the answer. About length of the forthcoming block of data - in my example 4d0403 = in dec 197709 bytes length. But the actual forthcoming block has size of 776 bytes.

73706b7101ec1996a4895228162e1cf75eaab50ec0030000000000008cf83bfda3c01f4c7ff01bb6bc3700b1ee01000000000000a73048490a4f80f4bbfb9ecdb049640bac030000000000007bc59a1d2c4a28a0ca47175315a49f69cc0300000000000010f083556b09cc49337d2a88517708c1e5010000000000008ef845e05dddecbe9d1fdfc478105b03e003000000000000d8bd14c2a60875fc15c7d9624594ebc9c903000000000000600474768de697671dbe343f2e443a6ad80100000000000037d904bae407f2186876fe1e7df24206e203000000000000a376e4598062ae025d3b1f03a9f0968cdc03000000000000fe0cfbc4b5119987a445be259acd171bb2030000000000008c1a7cce7c1d4fd2391a93b87dc79f08d7030000000000004c337c12b27f25f25bdc2ed958c34133e301000000000000bb4652e18ea3efafeea9e3aa18c3561fb401000000000000e6de73e77761cc0af4af0e6c51f368f3eb010000000000004a59e55ed87d44c09460617abc0a497ad101000000000000e49b25b8dd58801c16698f93cb7662c2db030000000000008c728bc7fc817060a7437b9e2ad7d878e103000000000000e2dbb31a2e88cb79292f27153894d6c753010000000000002eb8cf8214936c43221eb47e1e0307f4e003000000000000832f89238288f30030aa87bbc52bdb01d103000000000000bf25121d4896ac48ead1eda6a03e6c3fe203000000000000212313be9d25e4cf942acb422d375c48d7030000000000006cf4d008efdb99fe4812a5441164feeee203000000000000dc5e22ec795ad5bbaf4d4671a39b177f79000000000000009cd69c7c5c73c1be41483db4807e4470db0000000000000074875e6975904d146225fd3226d1a780bc00000000000000855ec098b9da617556bb1e4b73f4fd9acf00000000000000823df4dd996e94cd649037e77489649de2000000000000001f78df3a980f07e3bcaa70bee9f41404ca010000000000005f4af1558a32db8f98cdb628e09948bfed01000000000000aeb938af44938c51aaf6c40fe84c120ad301000000000000

---

As explained in the script page whose link is above, 4d is the prefix saying that the next part is data with two length bytes. The indicated length is 0304 in hexadecimal (since the length bytes are in little endian order) which is the equivalent of 772 bytes.

---

Thanks a lot, understood.